Wicket
  1. Wicket
  2. WICKET-1782

Protection against CSRF (cross-site request forgery) attacks

    Details

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

      Description

      Currently Wicket doesn't include a uniform and automatic solution against CRSF vulnerability or OWASP-A5 vulnerability [1].

      In order to solve CSRF is necessary to avoid static HTML and create dynamic or aleatory HTML per user.

      Two posible solutions:

      1. Include a random token (aleatory parameter) to each url (link or form). The name and the value of this parameter can be the same per user or change per request (more secure but perform worse). It seems that can be implemented creating other implementation of IRequestCodingStrategy interface.

      2. Encrypt all urls (links and form urls) using "Request Coding Strategy" strategy offered currently by wicket (CryptedUrlWebRequestCodingStrategy). Provide a security factory to use a different key per user or add some aleatory data to encrypted data (for example user jessionid). (SunJceCrypt, bundled in Wicket, is vulnerable to CSRF because obtained encrypted string is the same for all the users)

      [1] http://www.owasp.org/index.php/Top_10_2007-A5

        Activity

        Gorka Vicente created issue -
        Hide
        Johan Compagner added a comment -

        about 1:
        include a random token in each url that wicket generates?
        is then only 1 token valid for 1 request?
        That will not work for wicket. because of partial ajax updates of subsets of the pages then we have urls with token Y and with token Y+1 one 1 page and both urls old and new onces have to work fine.

        Show
        Johan Compagner added a comment - about 1: include a random token in each url that wicket generates? is then only 1 token valid for 1 request? That will not work for wicket. because of partial ajax updates of subsets of the pages then we have urls with token Y and with token Y+1 one 1 page and both urls old and new onces have to work fine.
        Hide
        Igor Vaynberg added a comment -

        yeah, hdiv guys already mentioned they break ajax support for apps that use their filter, so (1) is definetely a no-go for us. we are going to go the (2) route, i am thinking a simple sunjcecrypt and a [sessionid.uuid] key...

        Show
        Igor Vaynberg added a comment - yeah, hdiv guys already mentioned they break ajax support for apps that use their filter, so (1) is definetely a no-go for us. we are going to go the (2) route, i am thinking a simple sunjcecrypt and a [sessionid.uuid] key...
        Hide
        Johan Compagner added a comment -

        do we have a jsessionid always?
        stateless pages?

        What to do if for example there is not session yet? Then the default key is just used?

        Show
        Johan Compagner added a comment - do we have a jsessionid always? stateless pages? What to do if for example there is not session yet? Then the default key is just used?
        Igor Vaynberg made changes -
        Field Original Value New Value
        Assignee Igor Vaynberg [ ivaynberg ]
        Hide
        Igor Vaynberg added a comment -

        in order to have csrf protection you have to create an httpsession...stateless apps are not secure because you need a mirror token on the server

        Show
        Igor Vaynberg added a comment - in order to have csrf protection you have to create an httpsession...stateless apps are not secure because you need a mirror token on the server
        Hide
        Igor Vaynberg added a comment -

        the default crypt factory is now KeyInSessionSunJceCryptFactory which uses a randomly generated encryption key stored in httpsession.

        Show
        Igor Vaynberg added a comment - the default crypt factory is now KeyInSessionSunJceCryptFactory which uses a randomly generated encryption key stored in httpsession.
        Igor Vaynberg made changes -
        Fix Version/s 1.4-M4 [ 12313295 ]
        Resolution Fixed [ 1 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 1.3.5 [ 12313175 ]
        Hide
        Jörn Zaefferer added a comment -

        I found the commit on svnsearch (http://svnsearch.org/svnsearch/repos/ASF/search?logMessage=csrf). Any idea when 1.3.5 will be released? This looks like a much better solution then trying to build my own "secure" forms.

        Show
        Jörn Zaefferer added a comment - I found the commit on svnsearch ( http://svnsearch.org/svnsearch/repos/ASF/search?logMessage=csrf ). Any idea when 1.3.5 will be released? This looks like a much better solution then trying to build my own "secure" forms.
        Hide
        Igor Vaynberg added a comment -

        in the near future is all i can say. if you would like it to be released earlier start a thread on the mailing list

        Show
        Igor Vaynberg added a comment - in the near future is all i can say. if you would like it to be released earlier start a thread on the mailing list
        Hide
        Kent Tong added a comment -

        Is it enough to make sure the pagemap id (representing the window) is random? This way another window will be unable to forge the request.

        Show
        Kent Tong added a comment - Is it enough to make sure the pagemap id (representing the window) is random? This way another window will be unable to forge the request.

          People

          • Assignee:
            Igor Vaynberg
            Reporter:
            Gorka Vicente
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development