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"

From OWASP
Jump to: navigation, search
(Organized Generic Framework solutions under four categories)
Line 16: Line 16:
  
 
=== Generic Framework Solution ===
 
=== 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.
+
The framework should prevent leakage of session tokens as much as possible, using the following strategies:
* Set the Domain and Path parameters for the cookie correctly.
+
* 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.
* Automatically check for cookie support and either instruct the user to enable cookies/upgrade the browser, or switch to a "cookieless" session scheme based on a configuration choice. Default to requiring cookie support.
+
** Apply Secure and HttpOnly flags.
* Expose a simple administrative interface for setting P3P rules.
+
** Set the Domain and Path parameters for the cookie correctly.
* Automatically validate and signal when the number of cookies in use or the size of cookie data exceeds that which is commonly supported by browsers.
+
** Automatically check for cookie support and instruct the user how to enable cookies or upgrade the browser to a version that supports the required cookie features.
* Prevent application code from overwriting or otherwise manipulating the session cookie. Possibly prohibit the application from accessing the session token at all.
+
** Provide a configurable option to support "cookieless sessions", by passing the session ID as a POST parameter on every form.
 +
** Expose a simple administrative interface for setting P3P rules.
 +
** Automatically validate and signal when the number of cookies in use or the size of cookie data exceeds that which is commonly supported by browsers.
 +
** Prevent application code from overwriting or otherwise manipulating the session cookie. Possibly prohibit the application from accessing the session token at all.
 +
* The framework should prevent session tokens from being included in URLs or accepted as URL parameters.
  
The framework should provide a configurable session management scheme, which includes the following features:
+
The framework should detect evidence of session hijacking and proactively terminate compromised sessions using the following strategies:
 
+
* Alert the user and deauthorize the oldest session when multiple simultaneous logins are detected. Multiple simultaneous logins are prohibited by default, but may be enabled by changing a configuration setting.
* 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.
 
* Terminate session and send security SNMP trap or other configurable message if User-Agent string or other client fingerprinting changes.
 
* Tie the session ID to the SSL session and provide configurable options for actions to take if the session ID is transmitted over a new SSL session. Expose integration points with perimeter technologies to facilitate SSL termination, renegotiation, and other transitions.
 
* Tie the session ID to the SSL session and provide configurable options for actions to take if the session ID is transmitted over a new SSL session. Expose integration points with perimeter technologies to facilitate SSL termination, renegotiation, and other transitions.
 
* 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 include session information as part of a URL in order to support "cookieless" sessions. 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.
+
The framework should provide a configurable option for setting the inactivity and absolute timeouts for sessions. Timeouts should have secure defaults (e.g. 20 minutes of inactivity, 8 hours absolute lifetime). The framework should provide a configuration option to automatically save session state and allow the session to continue of the user successfully reauthenticates after the session times out.
 +
 
 +
The framework should 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 11:41, 22 July 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 or other sensitive cookie values 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. The standard should include a mechanism to tie the session identifier to the SSL session on both the browser and the server.

Perimeter Solution

  • Make sure that all session identifiers are transmitted over an encrypted protocol.
  • Terminate/regenerate the 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.
  • Ensure that session identifiers are transmitted only using the SSL session where they originated. Track sessions across SSL renegotiations and integrate with framework solutions to support common SSL termination/reencryption architectures.

Generic Framework Solution

The framework should prevent leakage of session tokens as much as possible, using the following strategies:

  • 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 check for cookie support and instruct the user how to enable cookies or upgrade the browser to a version that supports the required cookie features.
    • Provide a configurable option to support "cookieless sessions", by passing the session ID as a POST parameter on every form.
    • Expose a simple administrative interface for setting P3P rules.
    • Automatically validate and signal when the number of cookies in use or the size of cookie data exceeds that which is commonly supported by browsers.
    • Prevent application code from overwriting or otherwise manipulating the session cookie. Possibly prohibit the application from accessing the session token at all.
  • The framework should prevent session tokens from being included in URLs or accepted as URL parameters.

The framework should detect evidence of session hijacking and proactively terminate compromised sessions using the following strategies:

  • Alert the user and deauthorize the 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.
  • Tie the session ID to the SSL session and provide configurable options for actions to take if the session ID is transmitted over a new SSL session. Expose integration points with perimeter technologies to facilitate SSL termination, renegotiation, and other transitions.
  • Provide the option to the user when logging in to pin the session to the originating IP.

The framework should provide a configurable option for setting the inactivity and absolute timeouts for sessions. Timeouts should have secure defaults (e.g. 20 minutes of inactivity, 8 hours absolute lifetime). The framework should provide a configuration option to automatically save session state and allow the session to continue of the user successfully reauthenticates after the session times out.

The framework should 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

Discussion / Controversy

References

Session Management Cheat Sheet (OWASP)