No, the cookie is subject to the same-origin-policy, both in reading
and writing. The request is authenticated because the session cookie
is set, but its invalid when the form itself is missing the value.
Combining the attack with XSS would give access to the cookie, but
then he could just as well hijack the session directly.

In other words: With CSRF alone there is no way for the attacker to
read the cookie, therefore its enough to use just one.

Their whitepaper may do a better job of explaining the techniquie:
http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf
Solutions are described on page 8ff.

Jörn

On Mon, Oct 20, 2008 at 12:33 PM, Johan Compagner <[EMAIL PROTECTED]> 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
>>
>

Reply via email to