[
https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619928#action_12619928
]
Jörn Zaefferer commented on WICKET-1767:
----------------------------------------
I just noticed an interesting thing here: I'm not calling Session.unset, thats
why it works at all. Basically I'm replacing the HTTP session WITHOUT(!)
replacing the Wicket Session - it just gets bound to the new HTTP session, and
thats it.
Thats why invalidateNow doesn't work: The Session is marked as invalid and
rebinding it fails.
Good to finalize realize that. All wicket related state is bound to the wicket
Session object. By just rebinding it to a new Session, everything continues to
work as intentended. Creating a new wicket Session kills the state that has to
be maintained.
Assuming the session-fixation-protection is a desired feature, can we add
something to Session that makes this easier to use and much easier to document?
Something like Session.get().replace().
/**
* Replaces the underlying HTTP Session, invalidating the current one and
* creating a new one.
* <p>
* Call upon login to protect against session fixation.
*
* @see http://www.owasp.org/index.php/Session_Fixation
*/
public void replace() {
getSessionStore().invalidate(RequestCycle.get().getRequest());
bind();
getSessionStore().bind(RequestCycle.get().getRequest(), this);
}
> Protection against Session Fixation
> -----------------------------------
>
> Key: WICKET-1767
> URL: https://issues.apache.org/jira/browse/WICKET-1767
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.3.4
> Reporter: Jörn Zaefferer
>
> Securing a Wicket application against Session Fixation attacks
> (http://www.owasp.org/index.php/Session_Fixation) is currently not trivial.
> This is especially problematic as most Java webservers fall back to URL
> rewriting when the user disabled cookies. The session is gets appended to the
> URL and its trivial to steal a session.
> To protect against session fixation, the HTTP session must be invalidated and
> recreated on login, giving the user a new session id. The following code does
> exactly that, it must be called before loggin in the user (eg. store
> credentials). A redirect isn't required, though it should be part of the
> login-form anyway.
> ISessionStore store = Application.get().getSessionStore();
> Request request = RequestCycle.get().getRequest();
> store.invalidate(request);
> Session session = Application.get().newSession(request,
> RequestCycle.get().getResponse());
> session.bind();
> store.bind(request, session);
> Calling session.invalidateNow() does NOT work (I have no idea why).
> I'd like to see support for this as part of Wicket - it took me about 6 hours
> to figure out the Wicket internals and produce these 6 lines of code. Others
> shouldn't have to bother with that.
> I can't provide a testcase. Applications work fine without the addition, but
> leave users vulnerable to the session-fixation. Manual testing has to look at
> the session id (eg. via Firebug's Net tab) before and after a login.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
