The double-submitted-cookie isn't related to double submit protection, no. Thats a completely different turf.
With that out of the way, its enough to create just one cookie and use that both while rendering and validating forms. I hope that makes it clearer. I'll try to provide a reference implementation tomorrow. Jörn On Mon, Oct 20, 2008 at 12:58 PM, Johan Compagner <[EMAIL PROTECTED]> wrote: > hmm i will read the paper then > I stil dont get it how it is possible with 1 cookie, that then can never > change when it is first generated > and all the forms also just have that value right? > > But it is also for double submit protection right? So the cookie has to > change right? > But how can you then have 1 cookie? for all the forms? > If i submit one and that is rerendered or redirected to another page. > (so it has a new cookie so the double submit cant happen) > But if a new cookie is set then all other forms are also suddenly invalid.. > and that looks pretty wrong to me > > johan > > > On Mon, Oct 20, 2008 at 12:44 PM, Jörn Zaefferer < > [EMAIL PROTECTED]> wrote: > >> 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 >> >> >> > >> >
