[WEB SECURITY] How are you tackling CSRF?
tasos.laskos at gmail.com
Fri Apr 22 16:01:08 EDT 2011
When it comes to automated identification I look for forms that only
appear *with* the set cookies and ignore the rest.
It's a fair bet to assume that those forms will be tightly coupled with
the current user/session and thus affect business logic in one way or
Then I look if they contain any CSRF tokens, if they don't then they
are logged and reported.
This provides a more detailed breakdown:
 When I say "I" I mean Arachni.
 Unrecognized token formats is a weakness of this approach -- you
can't anticipate everything.
On 04/22/2011 07:30 PM, Jeremiah Grossman wrote:
> Hi All,
> Over the last year I've been noticing increased interest and awareness of Cross-Site Request Forgery (CSRF). A welcome change as for most of the last decade few considered CSRF a vulnerability at all, but an artifact of the way the web was designed. But, the as it normally happens, the bad guys have been showing us how damaging CSRF can really be.
> To help bring more clarity we've recently published a detailed blog post describing how our testing methodology approaches CSRF. What we're interested is how other pen-testers and developers are tackling the issue because automated detection is currently of limited help.
> WhiteHat Security’s Approach to Detecting Cross-Site Request Forgery (CSRF)
> FYI: Several weeks ago we launched our new blog, where I'll be diverting all my web security material. We've been piling up new content: https://blog.whitehatsec.com/
> Jeremiah Grossman
> Chief Technology Officer
> WhiteHat Security, Inc.
> 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
More information about the websecurity