[
https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643790#action_12643790
]
Johan Compagner commented on WICKET-1767:
-----------------------------------------
that doesnt sound logical to me
if i call invalidateNow() of a wicket session then it doesnt say to me that
that where i just called invalidateNow() on is then added to a new HttpSession
so it is kind of still alive not really invalidated at all (at least not the
object i called it on)
And then the boolean in the wicket session
sessionInvalidated = true; // set this for isSessionInvalidated
is telling us what?...
no i guess having a nice method like replaceHttpSession is way better.
> 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
> Assignee: Johan Compagner
> Fix For: 1.4-M4
>
>
> 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.
