Difference between revisions of "Session Fixation in Java"

From OWASP
Jump to: navigation, search
(Reverting to last version not containing links to www.textcnanor.com)
 
(4 intermediate revisions by 3 users not shown)
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: Disabling of URL rewriting mitigates Session Hijacking/Session Sniffing via session id's being exposed in a GET parameter of your url's (as well as being stored in your browser history, proxy servers, etc). See [[Session hijacking attack]]

Latest revision as of 13:28, 27 May 2009

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: Disabling of URL rewriting mitigates Session Hijacking/Session Sniffing via session id's being exposed in a GET parameter of your url's (as well as being stored in your browser history, proxy servers, etc). See Session hijacking attack