Difference between revisions of "LII:Web Application Security Guide/Session fixation"
From LIMSWiki
Jump to navigationJump to searchShawndouglas (talk | contribs) (Created as needed.) |
Shawndouglas (talk | contribs) m (Added further reading) |
||
| Line 4: | Line 4: | ||
===To prevent this type of attack=== | ===To prevent this type of attack=== | ||
* Regenerate (change) the session ID as soon as the user logs in (destroying the old session) | * Regenerate (change) the session ID as soon as the user logs in (destroying the old session). | ||
* Prevent the attacker from making the user use his session by accepting session IDs only from cookies, not from GET or POST parameters (PHP: php.ini setting “<tt>session.use_only_cookies</tt>”) | * Prevent the attacker from making the user use his session by accepting session IDs only from cookies, not from GET or POST parameters (PHP: php.ini setting “<tt>session.use_only_cookies</tt>”). | ||
===Rationale=== | ===Rationale=== | ||
Regenerating the ID makes the old session ID worthless to the attacker. Even if the attacker manages to fix a session, his session will never be authenticated. The second countermeasure is aimed at making it impossible to fix the session. However, XSS or similar issues with other applications on the same domain (not necessarily sub-domain!) may allow attackers to set false cookies. | Regenerating the ID makes the old session ID worthless to the attacker. Even if the attacker manages to fix a session, his session will never be authenticated. The second countermeasure is aimed at making it impossible to fix the session. However, XSS or similar issues with other applications on the same domain (not necessarily sub-domain!) may allow attackers to set false cookies. | ||
==Further reading== | |||
* [[wikipedia:Session fixation|Session fixation]] | |||
==Notes== | ==Notes== | ||
The original source for this page is [https://en.wikibooks.org/wiki/Web_Application_Security_Guide/Session_fixation the associated Wikibooks article] and is shared here under the [https://creativecommons.org/licenses/by-sa/3.0/ CC BY-SA 3.0] license. | The original source for this page is [https://en.wikibooks.org/wiki/Web_Application_Security_Guide/Session_fixation the associated Wikibooks article] and is shared here under the [https://creativecommons.org/licenses/by-sa/3.0/ CC BY-SA 3.0] license. | ||
Latest revision as of 22:38, 10 August 2016
Session fixation
In a session fixation attack, an attacker creates an unauthenticated session and then tricks a user to use and authenticate the session. As soon as the user has authenticated, the attacker can then use the session, as he knows the session id.
To prevent this type of attack
- Regenerate (change) the session ID as soon as the user logs in (destroying the old session).
- Prevent the attacker from making the user use his session by accepting session IDs only from cookies, not from GET or POST parameters (PHP: php.ini setting “session.use_only_cookies”).
Rationale
Regenerating the ID makes the old session ID worthless to the attacker. Even if the attacker manages to fix a session, his session will never be authenticated. The second countermeasure is aimed at making it impossible to fix the session. However, XSS or similar issues with other applications on the same domain (not necessarily sub-domain!) may allow attackers to set false cookies.
Further reading
Notes
The original source for this page is the associated Wikibooks article and is shared here under the CC BY-SA 3.0 license.
