Ahh, a no go for their filter then. The idea are very nice though.

Jörn Zaefferer wrote:
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
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
or different active pages)
and that cookie must be regenerated/set on every form render?


On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer <


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:
According to Johan Compagner, there are still issues with that
approach, though I don't know if that has been fixed:

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:


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?


-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
+45 2936 7684

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
+45 2936 7684

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to