The most common cause for a false positive would be unrecognized, but present, CSRF tokens. On the other hand, unprotected search forms and the like (things that do not affect business logic) are classified as noise. PS. Paul does have a point about search forms DoSing you but unless the attack page is Slashdot or something then it's a bit far fetched -- I agree with him though. On 04/23/2011 11:09 PM, Steven M. Christey wrote: > > 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 >>> >> >>