You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Jörn Zaefferer (JIRA)" <ji...@apache.org> on 2008/08/01 09:44:31 UTC
[jira] Created: (WICKET-1767) Protection against Session Fixation
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):
<pre>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);</pre>
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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Jörn Zaefferer (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Assigned: (WICKET-1767) Protection against Session Fixation
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg reassigned WICKET-1767:
-------------------------------------
Assignee: Johan Compagner
> 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
>
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620167#action_12620167 ]
Johan Compagner commented on WICKET-1767:
-----------------------------------------
that is something we cant add to Session but maybe to the WebSession subclass.
i dont like the name replace() to much..
a bit more explicit like invalidateHttpSession() or replaceHttpSession() (in WebSession not Session)
igor should we add this to the api what do you think?
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618986#action_12618986 ]
Johan Compagner commented on WICKET-1767:
-----------------------------------------
that flag shouldnt be in the way one bit
It just says that the session is invalidate or should invalidate
so for the rest it does exactly teh same is the 3 first lines:
getSessionStore().invalidate(RequestCycle.get().getRequest());
Then i you call Session.unset()
and then you ask for a session again (when you login in)
You should get a new one. I guess you really also should call bind() on it because you do want to store it and i guess we dont know that yet
So
session.invalidatNow()
Session.unset()
Session.get().bind();
If that doenst work then i guess that something goes wrong in the bind() call and i guess thats related with:
if (store.lookup(request) == null)
Maybe that somehow sees still the old session.
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619869#action_12619869 ]
Johan Compagner commented on WICKET-1767:
-----------------------------------------
no this is just weird
It has to be in the last bind() call that you do the rest is exactly the same
session.invalidatNow()
Session.unset()
session = Session.get();
session.bind()
i guess that last call is just a NOP. doesnt do anything because store.lookup() still returns something.
for example after that sesion.bind() call does the session have an id?
this code has to work it is just exactly the same as yours i cant see any difference and then it is just the rebinding in the same request that goes wrong
session.invalidatNow()
Session.unset()
session = Session.get(); << this should now be another instance of session!
Application.get().getSessionStore().bind(request, session);
the only thing is that session doesnt have an id then i think.
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Jörn Zaefferer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620155#action_12620155 ]
Jörn Zaefferer commented on WICKET-1767:
----------------------------------------
Thanks Johan, that makes it even shorter.
This works fine:
/**
* 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() {
((WebRequest)RequestCycle.get().getRequest()).getHttpServletRequest().getSession().invalidate();
bind();
}
> 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.
[jira] Updated: (WICKET-1767) Protection against Session Fixation
Posted by "Jörn Zaefferer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jörn Zaefferer updated WICKET-1767:
-----------------------------------
Description:
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.
was:
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):
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.
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Jörn Zaefferer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618980#action_12618980 ]
Jörn Zaefferer commented on WICKET-1767:
----------------------------------------
Thanks for the comment Johan.
invalidateNow actually does more then just store.invalidate(request). It also sets the invalited flag, which has some, in this case, undesired side effects. I didn't understand what exactly happens, but its definitely not the same.
Calling Session.unset() didn't help either.
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Jörn Zaefferer (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Jörn Zaefferer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619973#action_12619973 ]
Jörn Zaefferer commented on WICKET-1767:
----------------------------------------
I don't consider that a problem. On the hand, the old session got invalidet, so there is no way it still contains stale values. On the other, I don't need to invalidate Wickets Session state, all I need is a new HTTP session. After all, the point isn't to remove Wicket's session state, but to get a new session id.
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Jörn Zaefferer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620219#action_12620219 ]
Jörn Zaefferer commented on WICKET-1767:
----------------------------------------
replaceHttpSession() in WebSession sounds good.
By the way, I'm still wondering why Wicket has the seperatation of a non-web-layer and a WebXXX-layer on top of that. Can you give me an idea about that? I haven't seen any hint at usage of Wicket in non-http scenerios...
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Jörn Zaefferer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619887#action_12619887 ]
Jörn Zaefferer commented on WICKET-1767:
----------------------------------------
Tried this:
get().invalidateNow();
Session.unset();
Session session = Session.get();
session.bind();
Application.get().getSessionStore().bind(request(), session);
Without the session.bind() no new HttpSession is created, resulting in a NullPointerException in SessionStore. With the bind-call, as above, it just doesn't work.
Some further experimentation showed that this works, somewhat simplifying my initial solution:
Application.get().getSessionStore().invalidate(RequestCycle.get().getRequest());
Session session = Session.get();
session.bind();
Application.get().getSessionStore().bind(request(), session);
Replacing the first line with get().invalidateNow() does NOT work. So that sessionInvalidated flag in Session must have some undesired sideeffect, as that is the only difference between Session#invalidateNow and my code.
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643761#action_12643761 ]
Igor Vaynberg commented on WICKET-1767:
---------------------------------------
johan, should we just add bind() call to session.invalidatenow()? seems like that is the only missing bit and it would make more sense there then in yet another method.
> 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.
[jira] Updated: (WICKET-1767) Protection against Session Fixation
Posted by "Jörn Zaefferer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jörn Zaefferer updated WICKET-1767:
-----------------------------------
Description:
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):
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.
was:
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):
<pre>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);</pre>
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.
> 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):
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620281#action_12620281 ]
Igor Vaynberg commented on WICKET-1767:
---------------------------------------
a while ago someone also used wicket with apache mina instead of wicket running in jetty. so the separation is used, albeit seldomly.
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618978#action_12618978 ]
Johan Compagner commented on WICKET-1767:
-----------------------------------------
the first 3 lines are exactly what session.invalidate does
But we dont create a new session right away. And i think that is the problem
But what you coud try is doing this:
session.invalidateNow()
Session.unset();
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620225#action_12620225 ]
Johan Compagner commented on WICKET-1767:
-----------------------------------------
for example there was/is talk about a Wap implementation
also the portlets are implemented a bit different, but thats only for the special request/response wrappers
but currently the only impl is really the http/web implementation but the base is http/web free
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619926#action_12619926 ]
Johan Compagner commented on WICKET-1767:
-----------------------------------------
give me a test case then if you cant debug it what is really different
Because currently the only thing i see to fix this is doing that Session.unset() in the invalidateNow() call
Everything should work then (if you call bind() your self in your login code)
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Jörn Zaefferer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619924#action_12619924 ]
Jörn Zaefferer commented on WICKET-1767:
----------------------------------------
I can only repeat myself - and provide a testapp if that helps. You're welcome to give it a try yourself, I don't see how we could get any further otherwise.
> 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.
[jira] Updated: (WICKET-1767) Protection against Session Fixation
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Johan Compagner updated WICKET-1767:
------------------------------------
Fix Version/s: 1.4-M4
will try to apply it in 1.4
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Closed: (WICKET-1767) Protection against Session Fixation
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ 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 {@link ISessionStore#invalidate(Request)} and {@link #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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620038#action_12620038 ]
Johan Compagner commented on WICKET-1767:
-----------------------------------------
so the only thing you want to do is remove the http session but nothing more?
((WebRequest)RequestCycle.get().getRequest()).getHttpServletRequest().getSession().invalidate()
session.bind()
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620031#action_12620031 ]
Igor Vaynberg commented on WICKET-1767:
---------------------------------------
the stale state might not be in the actual httpsession, but it remains in wicket's session object attached to the current thread, and is not synced into httpsession until the end of requests afaik. so there is still a problem there, because between you calling invalidate() and the end of the request you can have business logic acting on old values it stored in wicket's session object.
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619962#action_12619962 ]
Igor Vaynberg commented on WICKET-1767:
---------------------------------------
if you are not replacing the old session instance with the new, then it is possible to still access stale values from the old session instance during that request...
> 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.
[jira] Commented: (WICKET-1767) Protection against Session Fixation
Posted by "Jörn Zaefferer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626500#action_12626500 ]
Jörn Zaefferer commented on WICKET-1767:
----------------------------------------
Any plans to fix this? It doesn't affect any existing code and its only four lines of code...
> 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.