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
Fix For: 1.3.6
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.
