Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Won't Fix
-
1.3.4
-
None
-
None
Description
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.