[
https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Compagner closed WICKET-1767.
-----------------------------------
Resolution: Fixed
i added this method:
/**
* Replaces the underlying (Web)Session, invalidating the current one
and creating a new one. By
* calling [EMAIL PROTECTED] ISessionStore#invalidate(Request)} and
[EMAIL PROTECTED] #bind()}
* <p>
* Call upon login to protect against session fixation.
*
* @see "http://www.owasp.org/index.php/Session_Fixation";
*/
public void replaceSession()
{
getSessionStore().invalidate(RequestCycle.get().getRequest());
bind();
}
i think thats the nicest thing to have (maybe a better method name anyone?)
> 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.
