Ok. I know this has been asked a MILLION times in one form or another but still I have a few holes in my understanding of how to write a secure app*.
What I'd like to do is gather enough info to be able to write a good, short (heck in can be long, I don't care) write up on what it takes to write a secure app and be able to post a link to said document any time someone asks a question security related. I know there are some good minds on this list when it comes to security so I'm hoping that these minds will contribute concise/verbose/detailed information. I've been thinking of writing a small app to test this out before I try to modify the 10,000+ lines of code I've got so far (not ALL code mind you) but before I do this I want to make sure I don't repeat the same mistakes. Here is a list of things that I think are Correct and Good(tm). The list that follows is meant to be added to and corrected in the hopes (like I stated earlier) that it can be put into an organized document for the unaware to learn from. So keep that in mind when writing your response. 1. Data that can be used to authenticate a user should never be stored on the clients machine even if it is obfuscated, and/or "encrypted" in some fashion. 2. The session id should not be stored on the client. 3. A unique identifier should be created for the user when the user logs in. This unique identifier should not be based on the user's name, password, id, or session id. This unique identifier should be changed each time the user successfully authenticates (logins) and can be stored in a cookie for later identifying of the user. 4. The unique identifier is a good thing to use when trying to implement a Remember Me function during the login process. i.e. A unique identifier is created when the user successfully authenticates. If the user chose to have the server remember their username a cookie will be placed on their system that stores this unique identifier. When the user comes back to your website the login page will first look for this cookie and a corresponding value. If it finds the cookie it will query the user table in the DB for this identifier (the identifier is stored in the users record each time they login, the new identifier replaces the old one) if found it will display the users name in the login box. 5. Passwords should not be stored in a database in clear text, instead passwords should be put through the md5() function at least once before INSERTing into the database. 6. The login page should be done over HTTPS. (Sounds like a good idea but is this necessary? Is this killing a mouse with a jackhammer?) 7. All input received via $_POST and/or $_GET should be thoroughly filtered before accepting, even if the value is from a <input type="hidden".../> (people may have a false sense of security about the hidden form variable, assuming since it's "hidden" no one will find it and mess with it's data). The best practice regarding filtering is to only allow what you want and reject the rest instead of the other way around (rejecting everything you don't want, accepting the rest). You're a lot less likely to allow malicious code through if you accept only what you want. Another tip in this regard is to use the ereg() function to create a regular expression that will make sure the data being received matches what you want. http://php.net/ereg 8. $_SESSION data is safe considering it can't be modified unless someone has access to your box which is an even bigger problem. This is not true in shared server situations, in which case you should ask your host to give you a private session directory (is this even possible?) to prevent someone from modifying your session data on the same server. 9. Use addslashes() on data that will be put through a SQL query to prevent SQL Injection attacks. http://php.net/addslashes 10. Use htmlentities() on data that will be put through a SQL query to prevent XSS attacks. http://php.net/htmlentities 11. Some good links to more information are... (add some links here, but let's not make this a link fest!) Hmmm... ok so that's all I can think of. I think it'd be a really great thing for the community if this list was corrected and added too in a detailed way (such as I've tried to do here). Looking forward to all the responses. Chris. * Suggesting an application is secure is like suggesting you're safe driving on the freeway. To a certain degree, yes, but are you really?????? -- Don't like reformatting your Outlook replies? Now there's relief! http://home.in.tum.de/~jain/software/outlook-quotefix/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
