[jira] Resolved: (WICKET-1885) CSRF Protection via Double-submitted-cookie

["Igor Vaynberg (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Igor Vaynberg resolved WICKET-1885.
-----------------------------------

    Resolution: Won't Fix
      Assignee: Igor Vaynberg

we already offer csrf protection that works on forms and links, and that is the crypted url coding strategy which stores its key in user's session. we do not need yet another way to do this.

i suggest you put this code on the wiki or start a wicket-stuff project, but i dont think we need another one of these in core.

> CSRF Protection via Double-submitted-cookie
> -------------------------------------------
>
>                 Key: WICKET-1885
>                 URL: https://issues.apache.org/jira/browse/WICKET-1885
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket
>    Affects Versions: 1.3.4
>            Reporter: Jörn Zaefferer
>            Assignee: Igor Vaynberg
>             Fix For: 1.3.6
>
>         Attachments: SecureForm.java
>
>
> As documented by this article (http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks), the most effective and efficient protection against CSRF attacks is the double-submitted-cookie pattern.
> The pattern works like this: For every form, add a hidden input field with a secure random token as the value. Read that token from a cookie or generate it and set is as a cookie. Add validation for the input to ensure that the field value matches the cookie value.
> A form generated by the webserver contains the necessary value, a form generated by a CSRF attacker doesn't, and due to the same-origin-policy, the attacker has no way to read the cookie or a valid form (unless due to another vulnerability, which usually makes CSRF irrelevant anyway).
> While the implementation is actually rather easy with Wicket, the theory behind it is not trivial, and therefore there is a good incentive to add a default implementation to Wicket, taken the burden away from the application developer to worry about this issue.
> Attached is an implementation of a Form subclass called SecureForm. It adds the input and generates the cookie when necessary. This is just a reference, not a patch. It can be used by replacing "extend Form" with "extend SecureForm" and adding the necessary markup: <input type="hidden" wicket:id="csrf-protection" />
> A better implementation would generate the necessary markup on the fly, avoiding the need to manually specify the markup. Also the token-generator should probably be replaced, eg. using existing facilities in Wicket to genrate secure random tokens.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.