Difference between revisions of "Session Fixation in Java"
From OWASP
(→Countermeasures) |
|||
| Line 9: | Line 9: | ||
* Session ID should be regenerated after login, and switching in and out of SSL | * Session ID should be regenerated after login, and switching in and out of SSL | ||
| − | |||
| − | |||
session.invalidate(); | session.invalidate(); | ||
session=request.getSession(true); | session=request.getSession(true); | ||
| + | |||
| + | Comment: Please note that JBOSS has proven to NOT regenerate a new session id via this method as of December 2007. | ||
* Disable URL rewriting | * Disable URL rewriting | ||
| − | + | Comment: What threat does this mitigate?<br/> | |
| + | Answer: URL rewriting mitigates Session Hijacking/Session Sniffing via session id's being exposed in a GET parameter of your url (as well as being stored in your browser history, proxy servers, etc). See http://www.owasp.org/index.php/Session_hijacking_attack | ||
Revision as of 00:08, 1 January 2008
Status
This article is in DRAFT
Overview of Session Fixation
A detailed overview on session fixation can be found here: Session Fixation
Countermeasures
- Session ID should be regenerated after login, and switching in and out of SSL
session.invalidate(); session=request.getSession(true);
Comment: Please note that JBOSS has proven to NOT regenerate a new session id via this method as of December 2007.
- Disable URL rewriting
Comment: What threat does this mitigate?
Answer: URL rewriting mitigates Session Hijacking/Session Sniffing via session id's being exposed in a GET parameter of your url (as well as being stored in your browser history, proxy servers, etc). See http://www.owasp.org/index.php/Session_hijacking_attack
