Wicket
  1. Wicket
  2. WICKET-1767

Protection against Session Fixation

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3.4
    • Fix Version/s: 1.4-RC1
    • Component/s: wicket
    • Labels:
      None

      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.

        Activity

        Jörn Zaefferer created issue -
        Jörn Zaefferer made changes -
        Field Original Value New Value
        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):

        <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.
        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.
        Jörn Zaefferer made changes -
        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.
        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.
        Igor Vaynberg made changes -
        Assignee Johan Compagner [ jcompagner ]
        Johan Compagner made changes -
        Fix Version/s 1.4-M4 [ 12313295 ]
        Johan Compagner made changes -
        Status Open [ 1 ] Closed [ 6 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Johan Compagner
            Reporter:
            Jörn Zaefferer
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development