CRV2 SessionHandling

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.

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. 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. Geographical location checking can help detect simple hijacking scenarios. Advanced hijackers use the same IP (or range) of the victim.
5. An active session should be warned when it is accessed from another location.
6. 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).