I've created a ticket and attached a reference implementation: https://issues.apache.org/jira/browse/WICKET-1885
Jörn On Mon, Oct 20, 2008 at 11:31 PM, Jörn Zaefferer <[EMAIL PROTECTED]> wrote: > 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 >>> >> >>> > >>> >> >
