On Thu, May 19, 2011 at 8:51 PM, Alex Nikitin <niksoft@xxxxxxxxx> wrote: > Hey Adam :) > > I devoted entire 3 minutes to glimpsing over the code and showing simple > ways to fix them, you make excellent points, i simply didnt even look into > them. You are absolutely correct in saying that sha1 a weak way to do this > (though it is waaaay better then md5), ofcourse the propper way to go about > this is a sha256 hash with a solid salt, however if the salt is stored in > clear text in code, and it would have to be in this case, granted someone > gets the said code, the having used the salt adds no security to the hash. > The whole idea behind is to add a little bit more at each level, so for > example on your typical php/database setup, salt may be stored in code > while > the hash is stored in mysql, having the hash from the database and not > having the salt makes it nearly impossible to reverse the hash, but if you > could get both the salt and hash out of the database or in our case the > code, it is no more secure then a hash by itself. > > Hmm that is an interesting bit about php_self, while my implementations > (while still using php_self) are not exploitable in this fashion, its still > an interesting concept, no this has not been locked down, as far as i can > see from a couple of tests just did (briefly). Hmm, i have to reconsider > how > i approach PHP_SELF now, i will have to wrap it in htmlentities or > something, i'll ponder that for now... > > In the meanwhile, i think it would be interesting to bounce some of this > code to have someone else look at it, especially security-wise, it's been a > bit of a project of mine when i get a few mins, i had to do something about > it for our Amazon boxes that use rds, as you cant just use b64d, because > you > cant add any mysql modules, so i came up with this idea, but i'm not 100% > satisfied with it atm: http://pastebin.com/tK5tBuiU > > Yeah https was going to be my next suggestion, actually why i got back into > email before heading home and possibly forgetting, however you have to make > sure you set up the server to be decently secure with it too, disable weak > crypto there, fix tls renegotiation, etc. > > To be honest, at least with session fixation, i didnt look at the "secured > page" code at all, but yes, a very good suggestion, i usually make a point > of making it when someone asks me to glimpse at their code that uses > sessions too, bah, it's been a long day at work, lol. Also i figured that > Tedd would hopefully start by addressing the first set of things i threw at > him, and then we can progress into more and more secure solution :) > > Tedd, yes you do have to worry about xss, yes with unescaped PHP_SELF you > can inject code into the form here <form name="my_form" action="<?php > echo($self);?>" method="post" > > Also a bit of a pep talk. You can make your code a lot more secure with a > little bit more work. It would be wrong to stop and not worry about > security, simply because code splits into two categories, secure and owned, > there is no grey area, if someone can bypass your security, then no matter > how simple your code was, it did nothing to stop the attacker, and thus did > not fulfil its primary duty, in today's web world some security is not any > better then no security, protecting against regular users is pointless as > they are not the ones who will try to break your system ;) > Just my $.02 > All great points, Alex. In terms of your pastebin code, you have a succinct, clean coding style ("Strunk & White" would be proud.) If I have some free time this weekend, I'll try to take a look, for whatever little that's worth :P Pleasure, Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
