Page 17 - [Everyone] Must read Security Notes

GET & POST reverse magic quotes:

To protect your includes from being accessed via the browser why not just put them in a .htaccess protected directory. that way the scripts can still include them and the browser can't see them.

I'm sure that was mentioned, but it's not an option for everyone. It's hard to require that if you're the designer of a program, too. Not everyone runs Apache, either. But yes, that is one good method.

---John Holmes...

Tip: use "mysql_real_escape_string()" for SQL statement and not "addslashes()".

Secure GET & POST values:


and then you dont have to worry about forgetting to do this.

Personal preference here, but I don't think applying functions blindly to the entire $_GET and $_POST arrays is good for efficiency and scalability.

IF I've already validated a string and I KNOW the value is going into a query, then I apply mysql_real_escape_string() to that value only.

Also, I only need to run stripslashes on a value if it's already validated to a string and I KNOW I'm going to turn around and use that value elsewhere.

---John Holmes...

I don't mind doing that with the entire array, if the majority of values are destined for the database. If only 2 or 3 values out of say 20 in a form are not destined for the db it seems to make sense to me to do that. Better to use the pre-written function for that than typing out 17 calls to mysql_real_escape_string, just because not all request varaibles (get or post) are meant for the database.

My db abstraction has it's own escaping method to use with db values and prepared statements, so for inserts and updates I rarely escape out side of the db abstraction, but I have the option to do so If need be.

Greetings,

Great information and and resources for the newbie PHP developer. I have noticed one security issue that has not been addressed. PHP Session Hijacking.

Session ID hijacking can be a problem with PHP Websites. The PHP session tracking component uses a unique ID for each user's session, but if this ID is known to another user, that person can hijack the user's session and see information that should be confidential. Session ID hijacking cannot completely be prevented; you should know the risks so you can mitigate them.

For instance, even after a user has been validated and assigned a session ID, you should revalidate that user when he or she performs any highly sensitive actions, such as resetting passwords. Never allow a session-validated user to enter a new password without also entering their old password, for example. You should also avoid displaying truly sensitive data, such as credit card numbers, to a user who has only been validated by session ID.

A user who creates a new session by logging in should be assigned a fresh session ID using the session_regenerate_id function. A hijacking user will try to set his session ID prior to login; this can be prevented if you regenerate the ID at login.

If your site is handling critical information such as credit card numbers, always use an SSL secured connection. This will help reduce session hijacking vulnerabilities since the session ID cannot be sniffed and easily hijacked.

If your site is run on a shared Web server, be aware that any session variables can easily be viewed by any other users on the same server. Mitigate this vulnerability by storing all sensitive data in a database record that's keyed to the session ID rather than as a session variable. If you must store a password in a session variable (and I stress again that it's best just to avoid this), do not store the password in clear text; use the sha1() (PHP 4.3+) or md5() function to store the hash of the password instead.



The above code is not secure, since the password is stored in plain text in a session variable. Instead, use code more like this:



The SHA-1 algorithm is not without its flaws, and further advances in computing power are making it possible to generate what are known as collisions (different strings with the same SHA-1 sum). Yet the above technique is still vastly superior to storing passwords in clear text. Use MD5 if you must -- since it's superior to a clear text-saved password -- but keep in mind that recent developments have made it possible to generate MD5 collisions in less than an hour on standard PC hardware. Ideally, one should use a function that implements SHA-256; such a function does not currently ship with PHP and must be found separately.

Another solution to help prevent Session Hijacking is to handle sessions with custom handlers. This allows you to store the session information in a database (encrypted form of course). A little trick to help validate sessions is to assign the user agent to the session entry in the database. When you verify a users session id, you should also compare the user agent.

In conclusion, you cannot prevent session hijacking completely, but you can take measure to minimize the damage and information that can be stolen.

Smart programming and proper security implementations.

Cheers!

I have some code I use as part of a session class to create / use 1 time session IDs that regenerate on each request. Here is the code put together into one easy to use function:

WTH would you go through all of that instead of just calling session_regenerate_id() by itself? Kind of seems like a waste. :shrug:

Well . . .

In my testing using php 4, session_regenerate_id() doesn't seem to remove old session data, it just starts a new session with a new id. This means that if someone were to capture my previous ID they could have access to my session data even though I was using a new copy. Who cares who is using which copy if my credit card or social security number is stored in there. The method I posted above explicitly clears my old session data assigned with my previous ID and moves it to my new session. For all intents and purposes, it creates a 1 time 1 use Session ID.

The manual for this function makes it seem as if all that is needed is session_regenerate_id(), but real life testing shows differently.

EDIT: Reading the manual now shows an optional argument for this function as of php 5.1 that seems to address the issue my function solves. So I guess if you have php < 5.1, My function would be a replacement.