[WEB SECURITY] How are you tackling CSRF?
rohirp92 at yahoo.com
Mon Apr 25 04:06:56 EDT 2011
You are basically assuming that there is XSS on some of the requests. If there
is no XSS, even if you keep a value of your CSRF token same as cookies, it wont
Also, if we correctly implement CSRF on each and every page (including GET),
that would automatically mitigate XSS too as a request carrying XSS string wont
be accepted on server side. (Provided CSRF token validation is done strictly).
From: Paul McMillan <paul at mcmillan.ws>
To: Steven M. Christey <coley at rcf-smtp.mitre.org>
Cc: web security <websecurity at webappsec.org>
Sent: Sun, April 24, 2011 3:28:15 AM
Subject: Re: [WEB SECURITY] How are you tackling CSRF?
Good point about CSRF tokens that are present but not actually validated.
>From your remediation step list, it sounds like you're using your
session token as the CSRF token. This is a really bad idea. Your
session cookie should be set to HTTP-only, to prevent it from being
malicious attackers may be able to use that information to steal your
If you hash your session cookie value and use that for your token, you
will (mostly) mitigate this problem.
In general, ALL forms should have CSRF protection. Things like search
don't appear to be important at first, until you imagine how easily a
non-CSRF search could be used to cause a DoS on your site. Search is
usually an expensive operation. Don't make it easier for attackers.
The Web Security Mailing List
WebSecurity RSS Feed
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
websecurity at lists.webappsec.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the websecurity