Session fixation

Web applications use a mechanism called session management to maintain user’s web experience more smooth and easy. Web servers’ use unique identifier called Session ID to identify users separately. Each user is been granted with a unique session ID upon request to open a connection with a web service. Commonly session IDs are maintain by use of session IDs in a URL, session IDs in a hidden form field or store in cookies. These IDs are given a time to expire in some cases. Many of the cookies are not only identifiers but also act as an authenticator. This enable the interest to attackers, if they can grab the cookies and establish the session, they can take act as a legitimate user. This helps them to carry out unauthorized activities. This method is called session hijacking, where attacker takeover some legal users session and act as a legitimate user. Hence, it is necessary to provide web session security. Web session security is trying to prevent mainly three types of web attacks; those are interception, prediction and brute forcing. Session fixation attack is a three-step process

1. Session setup - The attacker sets up a "trap-session" for the target web site to extract the session's ID or select an arbitrary session ID for the attack. In some cases, the established trap session value must be maintained (kept alive) with repeated web site contact.

2. Session fixation - The attacker introduces the trap session value into the user's browser and fixes the user's session ID.

3. Session entrance - The attacker waits until the user logs into the target web site to fix the session ID value and take over the session by the attacker.

Below listed few ways in which the session fixation can be mitigated.

1. User built in session frameworks - most of the application framework comes in a session management scheme. These generate session IDs and manage them pretty well. These mechanisms are well tested by security professionals and fixed most of the vulnerabilities. Hence, these are much better than the homegrown session managements, due to above reasons.

2. Store session data on severs - any program language provide a way to store session data in objects. These session objects can be stored in servers to prevent attacks.

3. Be aware of the data in the session objects. - Programmers need to be aware of where and what data they store in session objects. These can be DBs, file systems, or RAM. There can be many standards violation (for instance, PCI-DSS, ISO 27001). You can consider encrypting data that is being stored in session objects.

4. Short session timeout sessions - session timeout interval is generally configured in servers. If the time that the session be active without activities can be reduce, where it can reduce the time that left for attackers to steal, copy, of hijack the session IDs.

5. User session ID with enough entropy and length - most built-in session ID frameworks use random session IDs that are difficult to predict due to the long length.

6. Invalidate session on the server - although users and applications clear cookies at their log out from sites, it does not necessarily kill the session on the server. Malicious attackers use session ID replay to gain access to that particular session. This can be avoided with implementation of Session.Abandon() (ASP,.Net), or session.invalidate (J2EE), which kill sessions on the server when users log out.

7. Regenerate session when privileges changes - when the privileges of user changes, sessions should be change. For instance, when a user log in his privileges changes and when users changes from http to https and vice versa.

8. Set flags on cookies such as secure and HTTPOnly - when the secure flag is set cookies will only sent via SSL/TLS (HTTPS connections). When HTTPOnly flag is set, it prevent client side scripting which access cookies and its values. This helps prevent cross-site scripting and stealing session token stored in cookies. Path and domain attribute also can set appropriately.

9. Never to reuse session IDs - session IDs should not be used as cryptographic keys or create unique file names with it. These are only random identifiers assigned by application servers only for a particular session.

Usage of valid SSL certificates - certificated used by application should be valid SSL/TLS certificates. When users are being get used to accept invalid certification, they do not know which is secure and which is not. Attackers can send malicious certificates, which can use this vulnerability. This can raise MITM attacks as well, thus accept only SSL/TLS certificates.