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

From OWASP
Jump to: navigation, search
(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
 
(Comment: Could expand on why this is important)
 
 
    
 
    
 
   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: How does one do this in the popular web containers?, and what threat does this mitigate?)
+
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