This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "OWASP Periodic Table of Vulnerabilities - Cookie Theft/Session Hijacking"
James Landis (talk | contribs) |
James Landis (talk | contribs) |
||
Line 30: | Line 30: | ||
* Provide the option to the user when logging in to pin the session to the originating IP. | * Provide the option to the user when logging in to pin the session to the originating IP. | ||
* Never includes session information as part of a URL in order to support "cookieless" sessions. Must rewrite URLs as form POSTs including the session identifier as a hidden field, instead. | * Never includes session information as part of a URL in order to support "cookieless" sessions. Must rewrite URLs as form POSTs including the session identifier as a hidden field, instead. | ||
+ | * Provide a configurable option for automatically changing the session identifier transparently during a session: never, after a set time period, or a set number of requests. | ||
=== Custom Framework Solution === | === Custom Framework Solution === |
Revision as of 19:55, 15 May 2013
Return to Periodic Table Working View
Cookie Theft/Session Hijacking
Root Cause Summary
It's possible for an attacker to steal and reuse session identifiers when they are stored or transmitted insecurely.
Browser / Standards Solution
Define a new standard for transmitting session identifiers and managing them within the browser, such as a new request/response header to be used instead of cookies.
Perimeter Solution
- Make sure that all session identifiers are transmitted over an encrypted protocol.
- Terminate/regenerate session if the session token is transmitted insecurely (either in clear text or as part of the URL), or signal to the application to do so.
- Enforce the Secure and HttpOnly flags on sensitive cookies using a Web Application Firewall.
Generic Framework Solution
The framework should provide a centralized cookie management API which prevents direct access to cookies. By default, cookies should be handled according to the following rules, which must be explicitly overridden if a developer has a specific need for a cookie with unsafe properties.
- Apply Secure and HttpOnly flags.
- Set the Domain and Path parameters for the cookie correctly.
- Automatically checks for cookie support and either instructs the user to enable cookies/upgrade the browser, or switches to a "cookieless" session scheme based on a configuration choice. Defaults to requiring cookies support.
- Expose simple administrative interface for setting P3P rules.
- Automatically validate and alert when the number of cookies in use or the size of cookie data exceeds common browser support.
- Prevent application code from overwriting or otherwise manipulating the session cookie.
The framework should provide a configurable session management scheme, which includes the following features:
- Alert user and deauthorize oldest session when multiple simultaneous logins are detected. Multiple simultaneous logins are prohibited by default, but may be enabled by changing a configuration setting.
- Terminate session and send security SNMP trap or other configurable message if User-Agent string or other client fingerprinting changes.
- Provide the option to the user when logging in to pin the session to the originating IP.
- Never includes session information as part of a URL in order to support "cookieless" sessions. Must rewrite URLs as form POSTs including the session identifier as a hidden field, instead.
- Provide a configurable option for automatically changing the session identifier transparently during a session: never, after a set time period, or a set number of requests.
Custom Framework Solution
None
Custom Code Solution
None