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 - Session Fixation"

From OWASP
Jump to: navigation, search
(Created page with "Return to Periodic Table Working View == Insufficient Session Expiration == Session Fixation is...")
 
 
Line 1: Line 1:
 
[[OWASP_Periodic_Table_of_Vulnerabilities#Periodic_Table_of_Vulnerabilities|Return to Periodic Table Working View]]
 
[[OWASP_Periodic_Table_of_Vulnerabilities#Periodic_Table_of_Vulnerabilities|Return to Periodic Table Working View]]
  
−
== Insufficient Session Expiration ==
+
== Session Fixation ==
−
 
 
−
Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack takes advantage of a limitation in the way the web application manages session IDs. When authenticating a user, an application vulnerable to session fixation does not assign a new session ID to the user, and instead recycle the current users anonymous session id.
 
−
 
 
−
The attack consists of inducing a user to authenticate himself with a known session ID, and then hijacking the user-validated session by the knowledge of the used session ID. The attacker has to provide a legitimate Web application session ID and try to make the victim's browser use it.
 
−
 
 
−
The session fixation attack is a class of Session Hijacking, which steals the established session between the client and the web server after the user logs in. Instead, the Session Fixation attack fixes an established session on the victim's browser, so the attack starts before the user logs in. There are several techniques to execute the attack; it depends on how the Web application deals with session tokens.
 
  
 
=== Root Cause Summary ===
 
=== Root Cause Summary ===
−
Session fixation occurs when an anonymous session id is re-used (and not rotated) during authentication.  
+
An attacker can force a victim to use a session ID that is already known to the attacker; if the application does not change the ID when the privileges associated with the session change, the attacker then has access to those privileges via the known session ID.
  
 
=== Browser / Standards Solution ===
 
=== Browser / Standards Solution ===
Line 19: Line 13:
  
 
=== Generic Framework Solution ===
 
=== Generic Framework Solution ===
−
Most web application frameworks provide configuration settings for IDLE timeout.  
+
The framework must not create new sessions using session IDs supplied by the HTTP client.
 +
 
 +
The framework must discard an existing session ID and generate a new token for a session any time the privilege level of the session changes. Examples of privileges changing include:
 +
* A user logging in after starting an anonymous session
 +
* An administrator authorizing access to secure features during a session where only user-level privileges are being used
 +
* A user switching to a different user account during an active session with another account
 +
* An anonymous user submitting sensitive data which will be stored in session state and later echoed back to the user
  
 
=== Custom Framework Solution ===
 
=== Custom Framework Solution ===
Line 25: Line 25:
  
 
=== Custom Code Solution ===
 
=== Custom Code Solution ===
−
Most web frameworks are vulnerable to session fixation. If necessary, be sure to invalidate all existing sessions at login time before creating a new authenticated session for any user.
+
 
 +
None
  
 
=== Discussion / Controversy ===
 
=== Discussion / Controversy ===
Line 35: Line 36:
  
 
[https://www.owasp.org/index.php/Session_fixation OWASP Session Fixation Page]<br>
 
[https://www.owasp.org/index.php/Session_fixation OWASP Session Fixation Page]<br>
 +
 +
[http://projects.webappsec.org/w/page/13246960/Session%20Fixation Session Fixaction (WASC)]

Latest revision as of 11:28, 22 July 2013

Return to Periodic Table Working View

Session Fixation

Root Cause Summary

An attacker can force a victim to use a session ID that is already known to the attacker; if the application does not change the ID when the privileges associated with the session change, the attacker then has access to those privileges via the known session ID.

Browser / Standards Solution

None

Perimeter Solution

None

Generic Framework Solution

The framework must not create new sessions using session IDs supplied by the HTTP client.

The framework must discard an existing session ID and generate a new token for a session any time the privilege level of the session changes. Examples of privileges changing include:

  • A user logging in after starting an anonymous session
  • An administrator authorizing access to secure features during a session where only user-level privileges are being used
  • A user switching to a different user account during an active session with another account
  • An anonymous user submitting sensitive data which will be stored in session state and later echoed back to the user

Custom Framework Solution

None

Custom Code Solution

None

Discussion / Controversy

None

References

Session Management Cheat Sheet

OWASP Session Fixation Page

Session Fixaction (WASC)

Retrieved from "https://wiki.owasp.org/index.php?title=OWASP_Periodic_Table_of_Vulnerabilities_-_Session_Fixation&oldid=155813"