On Thu, May 19, 2011 at 8:51 PM, Alex Nikitin <niks...@gmail.com> 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



Nephtali:  A simple, flexible, fast, and security-focused PHP framework

Reply via email to