Another method is to attack the client. Microsoft Internet Explorer, for example, has had numerous flaws that allowed web sites to read cookies (often used to store the Session ID) to which they did not belong. Ideally, only the site that created the cookie should have access to it. Unfortunately, this is not always the case, and there are many instances of cookies being accessible to anyone. On top of this, a browser's cache is often accessible to anyone with access to that computer. It may be a hacker who has compromised the computer using some other attack, or a publicly accessible computer in an Internet café or kiosk. Either way, a cookie persistently stored in the browser cache is a tempting target.

Unencrypted transmissions are all too common and allow communication to be observed by an attacker. Unless the HTTPS protocol is used, a Session ID could be intercepted in transit and re-used. In fact, it is possible to mark cookies as 'secure' so they will only be transmitted over HTTPS. This is something I have rarely seen developers do. Such a simple thing can go such a long way.

Another way to that is used to compromise a Session ID is to attempt to predict it. Prediction occurs when an attacker realises that a pattern exists between session IDs. For example, some web based systems increment the session ID each time a user logs on. Knowing one session ID allows malicious users to identify the previous and next ones. Others use a brute force attack. This is a simple yet potentially effective method for determining a session identifier. A brute force attack occurs when a malicious user repeatedly tries numerous session identifiers until they happen upon a valid one. Although it is not complicated, it can be highly effective.

So what can you do to mitigate these attacks?


1. Always use strong encryption during transmission. Failure to encrypt the session identifier could render the online system insecure. In addition, for cookie based sessions, set the SSL-only attribute to "true" for a little added security. This will reduce the chance that an XSS attack could capture the session ID because the pages on the unencrypted section of the site will not be able to read the cookie.

2. Expire sessions quickly. Force the user to log out after a short period of inactivity. This way, an abandoned session will only be live for a short duration and thus will reduce the chance that an attacker could happen upon an active session. It is also wise to avoid persistent logins. Persistent logins typically leave a session identifier (or worse, login and password information) in a cookie that resides in the user's cache. This substantially increases the opportunity that an attacker has to get a valid SID.

3. Never make the Session ID viewable. This is a major problem with the GET method. GET variables are always present in the path string of the browser. Use the POST or cookie method instead or cycle the SID out with a new one frequently.