[ 
https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619902#action_12619902
 ] 

Johan Compagner commented on WICKET-1767:
-----------------------------------------

that that code works is weird you dont even call unset() !
So the second line where you do session.get() you should get the same session 
that is already stored in the thread local


I still dont get what that sessioninvalidate flag has to do with anything.
If you call Session.unset()
and then Session.get() then you have a new session. That that old object with 
that flag is not used anymore..
So how can it be in the way??

So you are saying that you have to call session.bind() else you dont have a new 
httpsession. then what thought would go wrong that it would go into this if

        if (store.lookup(request) == null)
                {
                        // explicitly create a session
                        id = store.getSessionId(request, true);
                        // bind it
                        store.bind(request, this);

isnt the case. So your call that you do also your self:
Application.get().getSessionStore().bind(request(), session); 

is already done. so why do you have to call it a second time also yourself? 
This all doesnt make sense.



> 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.

Reply via email to