[
https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619020#action_12619020
]
Jörn Zaefferer commented on WICKET-1767:
----------------------------------------
I lack the necessary knowledge about Wicket internals, so I was trying out
things while reading bits of Wicket source code.
session.invalidatNow()
Session.unset()
Session.get().bind();
Those didn't work. One possible issue with Session.get(), called after
invalidate/unset could be that get() actually creates the session, but without
creating a HTTP session.
Also store.lookup has to return null, as store.invalidate(request) kills the
HTTP session, and lookup takes the session id and uses getAttribute to access
the HTTP session.
My code seems to work because, in constract to the various "alternatives", it
first invalidates the HTTP session, then creates a new Wicket Session (via
Application#newSession, then binds it to the HTTP session (creating a new one),
then binding it to the SessionStore.
What do you think? Would a simple test application, that does nothing but login
in with a single button and outputting the session id help?
> 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.
