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).