Difference between revisions of "CRV2 SessionHandling"

Revision as of 14:27, 21 May 2014

General Considerations

1. If the system is critical, Session IDs should be cryptographically secure (i.e non determinable)
2. In big systems, sessions should not be stored in files (default PHP behavior). They should be stored in memory or in databases, to prevent DOS attacks on new sessions.
3. As soon as a confidential or higher session is formed for a user, they should have all their traffic transmitted through SSL. SessionID is almost as important as passwords.
4. A policy should be defined and forced on an application, to define the number of sessions a user can have. (One, Many, etc.) If this is left vague, it usually leads to security flaws.
5. Sessions require a general timeout, which happens at a certain time after creation (usually a week), and an idle timeout, which happens after a certain time of the session being idle (usually 30 minutes).
6. The idle timeout can be changed depending on the nature of the application (smaller for banking applications, larger for email composing clients)
7. The idle timeout doesn't have to be precise. The application can check for it every 2 minutes, and flush all timed-out idle sessions.
8. Sessions should be rolled when they are elevated. Rolling means that the session-id should be changed, and the session information should be transferred to the new id.
9. Sessions need to be cleared out on logout. It is a good idea to dispose of the session-id on logout as well.

Session Attacks

Generally three sorts of session attacks are possible:

1. Session Hijacking: stealing someone's session-id, and using it to impersonate that user.
2. Session Fixation: setting someone's session-id to a predefined value, and impersonating them using that known value
3. Session Elevation: when the importance of a session is changed, but its ID is not.

Session Hijacking

1. Mostly done via XSS attacks, mostly can be prevented by HTTP-Only session cookies (unless Javascript code requires access to them).
2. (charly proposes to eliminate this...) It's generally a good idea for Javascript not to need access to session cookies, as preventing all flavors of XSS is usually the toughest part of hardening a system.
3. Session-ids should be placed inside cookies, and not in URLs. URL informations are stored in browser's history, and HTTP Referrers, and can be accessed by attackers.
4. (...and add this) As cookies can be accessed by default from javascript and preventing all flavors of XSS is usually the toughest part of hardening a system, there is an attribute called "HTTPOnly", that forbids this access. The session cookie should has this attribute set. Anyway, as there is no need to access a session cookie from the client, you should get suspicious about client side code that depends on this access.
5. Geographical location checking can help detect simple hijacking scenarios. Advanced hijackers use the same IP (or range) of the victim.
6. An active session should be warned when it is accessed from another location.
7. An active users should be warned when s/he has an active session somewhere else (if the policy allows multiple sessions for a single user).

Session Fixation

1. If the application sees a new session-id that is not present in the pool, it should be rejected and a new session-id should be advertised. This is the sole method to prevent fixation.
2. All the session-ids should be generated by the application, and then stored in a pool to be checked later for. Application is the sole authority for session generation.

Session Elevation

1. Whenever a session is elevated (login, logout, certain authorization), it should be rolled.
2. Many applications create sessions for visitors as well (and not just authenticated users). They should definitely roll the session on elevation, because the user expects the application to treat them securely after they login.
3. When a down-elevation occurs, the session information regarding the higher level should be flushed.