I've looked at CSRFGuard, the approach has several of the drawbacks
described in the paper. Its much less effective then the
double-submitted-cookie, eg. it involves buffering and rewriting the
response to modify forms. It generates values for each rendered form
and stores it in the user session
(http://www.owasp.org/index.php/How_CSRFGuard_Works). The
double-submitted-cookie doesn't require any serverstate at all.

I'm not sure what happens when you open multiple tabs/windows, but
considering that the value is stored in the session, it probably
breaks. Again something the cookie pattern isn't affected by.


On Mon, Oct 20, 2008 at 12:42 PM, Nino Saturnino Martinez Vazquez Wael
> I found this interesting:
> "Don't forget OWASP CSRFTester and CSRFGuard
> <http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks#comment-100619>
> Comment by Jeff Williams <http://www.owasp.org> on September 29th, 2008 at
> 9:53 am.
> OWASP has made two tools available to help with CSRF problems. The first is
> CSRFTester which will allow you to test your website for CSRF problems. The
> tool allows you to create multi-step test cases and has been used to
> transfer funds, create accounts, issue checks, etc...
> The second tool is called CSRFGuard, and it's a Java EE filter that can be
> placed in front of an entire application to provide CSRF protection.
> CSRFGuard uses javascript to insert tokens into forms and links, and then
> validates the token in every request.
> You can find both free tools at http://www.owasp.org.";
> Especially the part about the filter. If it's compatible with wicket and a
> okay approach, I'd say forget about these things...
> Johan Compagner wrote:
>> what i dont get
>> if an attacker wants to submit the form. and it can get to the form it can
>> do the post
>> but you say it cant access the cookie. But if the cookie value is just
>> compared to the form post value
>> we have to make sure that the name of the cookie cant be guessed right? So
>> what should the name be?
>> Because if the name would be "wicket-form-uuid" then couldnt the attacker
>> also just generate that cookie?
>> I guess there is a cookie per form (there can be many forms on the same
>> page
>> or different active pages)
>> and that cookie must be regenerated/set on every form render?
>> johan
>> On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer <
>> [EMAIL PROTECTED]> wrote:
>>> Hi,
>>> my application currently uses CryptedUrlWebRequestCodingStrategy to
>>> protect against CRSF attacks. Afaik 1.3.5 will include an update that
>>> generates the key based on user sessions:
>>> http://issues.apache.org/jira/browse/WICKET-1782
>>> According to Johan Compagner, there are still issues with that
>>> approach, though I don't know if that has been fixed:
>>> http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593
>>> Anyway, the point of this mail is to bring up a different strategy for
>>> CSRF protection, the double-submitted-cookie. Discussion of that are
>>> here http://www.codinghorror.com/blog/archives/001175.html which links
>>> to this article, including a whitepaper:
>>> http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks
>>> The basic idea is:
>>> "When a user visits a site, the site should generate a
>>> (cryptographically strong) pseudorandom value and set it as a cookie
>>> on the user's machine. The site should require every form submission
>>> to include this pseudorandom value as a form value and also as a
>>> cookie value. When a POST request is sent to the site, the request
>>> should only be considered valid if the form value and the cookie value
>>> are the same. When an attacker submits a form on behalf of a user, he
>>> can only modify the values of the form. An attacker cannot read any
>>> data sent from the server or modify cookie values, per the same-origin
>>> policy. This means that while an attacker can send any value he wants
>>> with the form, he will be unable to modify or read the value stored in
>>> the cookie. Since the cookie value and the form value must be the
>>> same, the attacker will be unable to successfully submit a form unless
>>> he is able to guess the pseudorandom value."
>>> For Wicket, this would mean: Generate a pseudorandom value and set is
>>> as a session cookie, when the cookie doesn't yet exist. Insert a
>>> hidden input into each form with the generated value. Validate that
>>> the value equals the cookie when submitting a form. The input and
>>> validation can be abstracted into a Form subclass (or even add it to
>>> Wicket's Form class...).
>>> That really easy to implement, is much more efficient (generate only
>>> one value per user/browser session, store it on the client, not the
>>> server) and is now the most common strategy to protect against CSRF
>>> attacks. I've read a lot about CSRF, and this strategy seems the only
>>> one both easy enough to implement and without holes.
>>> What do you think? Should Wicket support that out-of-the-box?
>>> Jörn
> --
> -Wicket for love
> Nino Martinez Wael
> Java Specialist @ Jayway DK
> http://www.jayway.dk
> +45 2936 7684
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to