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. 

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) https://blog.whitehatsec.com/whitehat-security%E2%80%99s-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/ Regards, Jeremiah Grossman Chief Technology Officer WhiteHat Security, Inc. http://www.whitehatsec.com/

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.

Hi, When it comes to automated identification I[1] 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 another. Then I look if they contain any CSRF tokens[2], if they don't then they are logged and reported. This provides a more detailed breakdown: http://trainofthought.segfault.gr/wp-content/uploads/2010/10/Automated-detection-of-CSRF-worthy-HTML-forms-through-4-pass-reverse-Diff-analysis.pdf Cheers, Tasos L. [1] When I say "I" I mean Arachni. [2] 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) > https://blog.whitehatsec.com/whitehat-security%E2%80%99s-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/ > > > Regards, > > Jeremiah Grossman > Chief Technology Officer > WhiteHat Security, Inc. > http://www.whitehatsec.com/ > > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >

Tasos - thank you for explaining how you test for this! We actually cover this testing paradigm in the article. We find it to be littered with so many false positives that business owners wind up ignoring the overall results, as we discuss in the article. There are other drawbacks as well from what we have observed. What have you found in terms of response to your results so far? --- Arian Evans Sybarite Software Security Scanning Savant On Fri, Apr 22, 2011 at 1:01 PM, Tasos Laskos <tasos.laskos@gmail.com> wrote: > Hi, > > When it comes to automated identification I[1] 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 another. > > Then I look if they contain any CSRF tokens[2], if they don't then they are > logged and reported. > > This provides a more detailed breakdown: > http://trainofthought.segfault.gr/wp-content/uploads/2010/10/Automated-detection-of-CSRF-worthy-HTML-forms-through-4-pass-reverse-Diff-analysis.pdf > > Cheers, > Tasos L. > > [1] When I say "I" I mean Arachni. > [2] 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) >> >> https://blog.whitehatsec.com/whitehat-security%E2%80%99s-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/ >> >> >> Regards, >> >> Jeremiah Grossman >> Chief Technology Officer >> WhiteHat Security, Inc. >> http://www.whitehatsec.com/ >> >> >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >> > > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >

1. Check out important enough pages post-login and check their session state.
2. If session is found to be maintained only in cookies, assume that whole 

1. All sensitive requests SHOULD be POST with https (in most of the cases).
2. Generate hidden parameter and attach it to the form. This is anti-CSRF 

Over the last year I've been noticing increased interest and awareness of 

As far as our experience goes, if post-login, some forms do not contain anti-CSRF tokens, it is fair chance that rest of forms will also be the same. I have seen a notion among developers that we are using POST request and hence we are safe. So we have recently formulated following strategy 1. Check out important enough pages post-login and check their session state. 2. If session is found to be maintained only in cookies, assume that whole application is CSRF prone. 3. Take a help of automated scanners, train them a little bit and generate report. 4. Get it fixed from our developers. For point(2), questions comes how to check if session is maintained only in cookies. We can validate this by carefully observing requests through proxy. Now, lately I have seen some cases where there is anti-CSRF tokens but there is no validation of them :) . So we generally implement it like 1. All sensitive requests SHOULD be POST with https (in most of the cases). 2. Generate hidden parameter and attach it to the form. This is anti-CSRF token. We normally take set their value same as session cookies. 3. Once this form is submitted, we check if cookie-value = value of 'that' hidden parameter. 4. For GET requests, we normally attack anti-CSRF token in query string or we make sure that they are not prone to XSS at all.Regards, Rohit ________________________________ From: Jeremiah Grossman <jeremiah@whitehatsec.com> To: web security <websecurity@webappsec.org> Sent: Sat, April 23, 2011 12:00:54 AM Subject: [WEB SECURITY] How are you tackling CSRF? 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) https://blog.whitehatsec.com/whitehat-security%E2%80%99s-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/ Regards, Jeremiah Grossman Chief Technology Officer WhiteHat Security, Inc. http://www.whitehatsec.com/ _______________________________________________ The Web Security Mailing List WebSecurity RSS Feed http://www.webappsec.org/rss/websecurity.rss Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA WASC on Twitter http://twitter.com/wascupdates websecurity@lists.webappsec.org http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

     Over the last year I've been noticing increased interest and

Huh... I probably missed it in the article. There are 2 difficulties I've spotted with it: o How do you compare forms? i.e. What are the criteria for 2 forms being equal? o Identifying CSRF tokens -- not all of them are going to be of the same format. The first one is not hard to solve, create an ID string made from concatenated input names and the action URL. The second one is harder, right now Arachni checks for CSRF tokens same way that Skipfish does; it looks for strings that look likebase10/16/32/64. Although these are the most common formats they're not the only ones. The only false positives I've seen are caused by this -- they are quite rare but they exist. So all-in-all yes it works for me, if great minds do think alike then short of doing what you guys do I doubt that we're going to figure out a better *fully* automated way. Maybe a DB with CSRF token signatures could help but we'll see... I've accepted, in my old age,the fact that we've kind of hit a barrier with our usual techniques so I'm kind of moving into baselines/meta-analysis as a filtering mechanism. Something akin to a subsystem saying: ----------- Yes, huh...so these are the scan results...Wait, what? There are 60 forms total and all of the are vulnerable? I seriously doubt that. Well, report them but put them in a special "These may be false positives" section. ----------- We've previously discussed my thoughts on the last subject but I've also documented them here: http://trainofthought.segfault.gr/2011/02/03/high-level-meta-analysis-in-webappsec-scanners/ I doubt that you business guys would like this approach since you have qualified people between the webapp and the scanner who's job is to interpret the results, so you don't need it. But in a system like Arachni I believe that even probable false positives are worth reporting because they too have something to offer. Since false positives appear mostly due to webapp or server quirks it's worth looking into them during a pen test. This way laypeople are happy that the pretty report at the end of the scan isn't full of noise and hacker-folk are happy that they are given the chance to dig deeper and see why the webapp behaved in a way that produced false positives. However, you guys have more customers than the size of my user-base (x10 probably)so I imagine that you've seen a *lot* of edge cases which justify your design decisions. What I mean is that it all comes down to pushing our ego aside and implement whatever gets the job done. PS. If I'm being perfectly honest only one person has reported a CSRF false positive (https://github.com/Zapotek/arachni/issues/14) and even though it technically was an FP it was a good thing overall that it happened. On 04/23/2011 04:19 AM, Arian J. Evans wrote: > Tasos - thank you for explaining how you test for this! > > We actually cover this testing paradigm in the article. We find it to be > littered with so many false positives that business owners wind up > ignoring the overall results, as we discuss in the article. There are > other drawbacks as well from what we have observed. > > What have you found in terms of response to your results so far? > > --- > Arian Evans > Sybarite Software Security Scanning Savant > > > On Fri, Apr 22, 2011 at 1:01 PM, Tasos Laskos<tasos.laskos@gmail.com> wrote: >> Hi, >> >> When it comes to automated identification I[1] 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 another. >> >> Then I look if they contain any CSRF tokens[2], if they don't then they are >> logged and reported. >> >> This provides a more detailed breakdown: >> http://trainofthought.segfault.gr/wp-content/uploads/2010/10/Automated-detection-of-CSRF-worthy-HTML-forms-through-4-pass-reverse-Diff-analysis.pdf >> >> Cheers, >> Tasos L. >> >> [1] When I say "I" I mean Arachni. >> [2] 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) >>> >>> https://blog.whitehatsec.com/whitehat-security%E2%80%99s-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/ >>> >>> >>> Regards, >>> >>> Jeremiah Grossman >>> Chief Technology Officer >>> WhiteHat Security, Inc. >>> http://www.whitehatsec.com/ >>> >>> >>> _______________________________________________ >>> The Web Security Mailing List >>> >>> WebSecurity RSS Feed >>> http://www.webappsec.org/rss/websecurity.rss >>> >>> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >>> >>> WASC on Twitter >>> http://twitter.com/wascupdates >>> >>> websecurity@lists.webappsec.org >>> >>> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >>> >> >> >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >> >

There's actually also a Programming Language theory related to CSRF, which we've been investigating: Types and Effects. With an appropriate programming language (Java could be sufficient, with annotations) and a good library, it is quite feasible to have the compiler (or an external audit tool) determine automatically if the simple fact of accessing a given resource while authenticated will trigger behavior that should only take place by explicit demand of a user. Cheers, David -- David Rajchenbach-Teller CSO, MLstate On Apr 23, 2011, at 5:19 AM, Arian J. Evans wrote: > Tasos - thank you for explaining how you test for this! > > We actually cover this testing paradigm in the article. We find it to be > littered with so many false positives that business owners wind up > ignoring the overall results, as we discuss in the article. There are > other drawbacks as well from what we have observed. > > What have you found in terms of response to your results so far? > > --- > Arian Evans > Sybarite Software Security Scanning Savant >

Disclaimer: I'm mostly ignorant about automated detection of CSRF. Just a random thought. Has anybody investigated filtering/prioritizing forms based on how many pages invoke those forms? I would guess that some critical state-changing forms would only be accessible from a single page, whereas (e.g.) a search or login function might be accessible from many. In a CMS scenario for example, there might be lots of pages that link to a "create a new page" form, but only one page that points to the form "commit the new page content you just filled in." This might not serve as *proof* that a form should have CSRF protection, but it might be one way of sorting the potential false-positives. - Steve

Hey Steve, In a intranet environment where all browser/network settings are controlled, HTTP Referrer header verification (what you are suggesting below) can be effective as a •partial• CSRF defense to be used in addition to cryptographic nonces. But when your website has Internet-facing customers/consumers, you can no longer rely on referrer headers. Some organizations strip them in an outbound way to prevent data leakage. Jim Manico On Apr 23, 2011, at 9:33 AM, "Steven M. Christey" <coley@rcf-smtp.mitre.org> wrote: > > Disclaimer: I'm mostly ignorant about automated detection of CSRF. > > Just a random thought. Has anybody investigated filtering/prioritizing forms based on how many pages invoke those forms? I would guess that some critical state-changing forms would only be accessible from a single page, whereas (e.g.) a search or login function might be accessible from many. > > In a CMS scenario for example, there might be lots of pages that link to a "create a new page" form, but only one page that points to the form "commit the new page content you just filled in." > > This might not serve as *proof* that a form should have CSRF protection, but it might be one way of sorting the potential false-positives. > > - Steve > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Rohit, 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 stolen or misused by Javascript in the event of an XSS bug. If you use the same value in your form, Javascript can access it, and malicious attackers may be able to use that information to steal your users sessions. If you hash your session cookie value and use that for your token, you will (mostly) mitigate this problem. Steve, 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. -Paul

Jim, Sorry if I wasn't clear - I was asking about methods for automatically detecting when a page/function might be vulnerable to CSRF, not which protection mechanisms could be used to defend against it. If all forms should be CSRF-protected as suggested by another poster, then my question is moot... but would then prompt me to ask what a "false positive" would look like. - Steve On Sat, 23 Apr 2011, James Manico wrote: > Hey Steve, > > In a intranet environment where all browser/network settings are > controlled, HTTP Referrer header verification (what you are suggesting > below) can be effective as a •partial• CSRF defense to be used in > addition to cryptographic nonces. > > But when your website has Internet-facing customers/consumers, you can > no longer rely on referrer headers. Some organizations strip them in > an outbound way to prevent data leakage. > > Jim Manico > > On Apr 23, 2011, at 9:33 AM, "Steven M. Christey" > <coley@rcf-smtp.mitre.org> wrote: > >> >> Disclaimer: I'm mostly ignorant about automated detection of CSRF. >> >> Just a random thought. Has anybody investigated filtering/prioritizing forms based on how many pages invoke those forms? I would guess that some critical state-changing forms would only be accessible from a single page, whereas (e.g.) a search or login function might be accessible from many. >> >> In a CMS scenario for example, there might be lots of pages that link to a "create a new page" form, but only one page that points to the form "commit the new page content you just filled in." >> >> This might not serve as *proof* that a form should have CSRF protection, but it might be one way of sorting the potential false-positives. >> >> - Steve >> >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > >