Revision as of 11:52, 18 October 2013 by Abbas Naderi (initial contents for session handling, needs to add checklists for other two types of attacks)
- If the system is critical, Session IDs should be cryptographically secure (i.e non determinable)
- 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.
- 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.
- 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.
- 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).
- The idle timeout can be changed depending on the nature of the application (smaller for banking applications, larger for email composing clients)
- 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.
Generally three sorts of session attacks are possible:
- Session Hijacking: stealing someone's session-id, and using it to impersonate that user.
- Session Fixation: setting someone's session-id to a predefined value, and impersonating them using that known value
- Session Elevation: when the importance of a session is changed, but its ID is not.
- 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.
- Geographical location checking can help detect simple hijacking scenarios. Advanced hijackers use the same IP (or range) of the victim.
- An active session should be warned when it is accessed from another location.
- 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).