Difference between revisions of "OWASP Periodic Table of Vulnerabilities - Cookie Theft/Session Hijacking"

From OWASP
Jump to: navigation, search
m
 
(6 intermediate revisions by one user not shown)
Line 11: Line 11:
 
=== Perimeter Solution ===
 
=== Perimeter Solution ===
 
* Make sure that all session identifiers are transmitted over an encrypted protocol.
 
* 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.
+
* 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.
 
* Enforce the Secure and HttpOnly flags on sensitive cookies using a Web Application Firewall.
* Ensure that sessions identifiers are transmitted only over the SSL session where they originated. Track sessions across SSL renegotiations and integrate with framework solutions to support common SSL termination/reencryption architectures.
+
* 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 ===
 
=== 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 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.
+
** Apply Secure and HttpOnly flags.
* Expose simple administrative interface for setting P3P rules.
+
** Set the Domain and Path parameters for the cookie correctly.
* Automatically validate and alert when the number of cookies in use or the size of cookie data exceeds common browser support.
+
** 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.
+
** 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. 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.
+
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 ===
Line 41: Line 43:
  
 
=== Discussion / Controversy ===
 
=== Discussion / Controversy ===
 +
 +
Enforcing short session timeouts helps to mitigate the risk of Session Hijacking, but this is addressed by [[OWASP Periodic Table of Vulnerabilities - Insufficient Session Expiration|Insufficient Session Expiration]].
  
 
=== References ===
 
=== References ===
[https://www.owasp.org/index.php/Session_Management_Cheat_Sheet Session Management Cheat Sheet (OWASP)]
+
[[Session Management Cheat Sheet]]<BR>
 +
[http://projects.webappsec.org/w/page/13246944/Insufficient%20Session%20Expiration Insufficient Session Expiration (WASC)]<BR>
 +
[http://cwe.mitre.org/data/definitions/613.html Insufficient Session Expiration (CWE)]<BR>
 +
[https://tools.ietf.org/html/draft-ietf-websec-session-continue-prob-00 IETF Session Continuation Proposal]<BR>

Latest revision as of 16:27, 14 August 2013

Return to Periodic Table Working View

Contents

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

Enforcing short session timeouts helps to mitigate the risk of Session Hijacking, but this is addressed by Insufficient Session Expiration.

References

Session Management Cheat Sheet
Insufficient Session Expiration (WASC)
Insufficient Session Expiration (CWE)
IETF Session Continuation Proposal