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. Jörn On Mon, Oct 20, 2008 at 12:42 PM, Nino Saturnino Martinez Vazquez Wael <[EMAIL PROTECTED]> wrote: > 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] > >
