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 -- Alex ---- The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. ~Seymour Cray On Thu, May 19, 2011 at 8:18 PM, tedd <tedd.sperling@xxxxxxxxx> wrote: > At 2:29 PM -0400 5/19/11, Alex Nikitin wrote: > >> I will try to respond to the original question. >> >> Note: this is constructive criticism, so i wont do much in terms of >> praising >> the good parts >> >> It works, its very primitive, in some ways its pretty insecure, for >> example >> it provides no session hijacking protection, it's not written with the >> better of standards in mind, for one if you do store your password in >> code, >> you shouldn't store your password in clear text, that way if say i was >> able >> to bypass php execution and dumped that file out, i would still not have a >> useable password, so use a hash. There is no timing out or attempt >> management, for example i can write a 5 line-long brute script that will >> just pound your script with user ids and passwords, you should make it at >> least somewhat difficult for me to do that ;) >> > > I agree if I was creating a more secure script. > > I have scripts where the user enters a user id and password and the > password is immediately hashed and stored in a database. The next time in, > the user's input password is hashed again and compared with the stored > encrypted password. That way the raw password is never stored anywhere. I > even have people who ask me "Look at your records and tell me what's my > password?" and I say that I can't answer them because the data has been > one-way hashed. Instead, I have them use the "forgot password" routines. > > I also have a script that monitors how many times a user (via their IP) > tries to log on and restricts those attempts to a certain number of times > within a time limit. > > As for XXS, I'm not sure as to what the exposure is because I am not > putting questionable data into the HTML document. Rather, the questionable > data is compared to known data -- if there is a match then the user is > allowed to continue -- if not, it fails. I don't use the user's data for > anything other than that. > > If there is more to consider here, I would like to hear about it. > > In any event, for me to consider all those points and also make the demo > simple enough for a novice user would be very difficult. > > I would like to introduce to the novice a way to "protect" their pages. But > if I make it too complicated, then they simply won't understand. > > It is obvious that I should also tell the user that this is NOT the most > secure way to make things private and that there are other security > concerns. > > What say you? > > > Cheers, > > tedd > > > -- > ------- > http://sperling.com/ >
