Validating PHP User Sessions
First of all, because of the public computer risk, your design should be such that the logout button is always visible when logged in, so that the user can easily log out at any time. Your PHP configuration options (or custom script) should be set so that sessions will ??timeout?? after approximately 20 minutes of inactivity. If you don??t have access to the PHP configuration options on shared hosting and it doesn??t timeout after 20 minutes or so, then you should store the ??last access time?? in the session itself and destroy the session if it is accessed after a time of inactivity. Also, if you manually set a cookie (using a custom script) you should set it so that it is destroyed when the browser window is closed not by an expiration date (PHP??s session_start() sets the cookie this way by default). If you do need to set an expiration date, such as for a ??remember me?? function, it should not be set by default, and should only be used when the user explicitly checks a box that says ??remember me?? since only the user will know whether or not they are on a public computer.
Secondly, in order to protect your session as much as possible, you need to find as many unique aspects of the user??s computer as you can find, and verify that they stay the same across all page requests. The most common security precaution here is to verify that the IP address stays the same. It is possible that a hacker could be at the same IP address as the valid user, or perhaps even IP spoof, but it is more unlikely. However, depending on your needs for security versus ease-of-use, and whether or not you need sessions to span hours or days (for ??remember me?? functions) you need to bring this into balance with the fact that a user??s IP address can potentially change throughout a session, particularly with large dial-up companies like AOL, etc. This means that the valid user may potentially get bumped. For this reason, applications like the open source phpbb bulletin board only verify the first 6 characters of the IP address by default, to make it less likely that a user will get bumped from an ISP generated IP change.
Now, it is important to know that even with all of the above, the site is still not ??safe??. For one, unless you are using SSL on the site, the session identifier, the IP address, and the user-agent are all being sent to the server in plain text. This means that a good hacker, listening to the server traffic, will still be able to hack into the system fairly easily. If the data you are protecting is important, then your best course of action is, on top of taking all the previously mentioned precautions, enabling SSL on the server so that all data exchange is encrypted.
On the next page, I have provided a simplified example of doing a manual timeout as well as verifying IP address and user-agent to validate a session. It is my recommendation that if the credentials don??t match, that you immediately destroy the session to ensure that the hacker can??t keep trying different things after finding a valid session identifier. This will log out the valid user, but is worthwhile to do so.