XSRF (Cross Site Request Forgery) is a huge security problem affecting most web applications. There have been a lot of articles written about XSRF, including the useful XSRF FAQ I linked to earlier.
There are quite a few free and commercial web application security assessment tools and static code analysis tools in the market today. A few commercial security assessment tool vendors have published white-papers about the importance of discovering XSRF vulnerabilities, yet their own products do not have the ability to assess for XSRF. I think there are multiple reasons for this, and here are my preliminary thoughts:
1. Lack of business awareness and demand.
SQL injection vulnerabilities are visually impactful. It is clear why SQL injection is bad, and why they can threaten the survival of an organization. On the other hand, the business impact of XSS (Cross Site Scripting) can be harder to demonstrate or explain. Thanks to some of the recent media coverage on XSS, most people who care about security in a business organization know that finding and remediating XSS vulnerabilities is important (I do not agree that organizations are making reasonable progress in understanding what XSS is, I just feel that a lot of people have heard of 'Cross Site Scripting' and know it is bad, and the awareness stops there. Other security professionals are more optimistic than me, but I'll leave this topic to future discussion). Compared to XSS, the awareness of XSRF is just beginning to brew, and businesses are slowly realizing the impact. Most applications, by design, are vulnerable to XSRF - yet we don't see the media jumping up and down about XSRF (as much as they do for XSS) just yet. This is slowly improving.
2. Even (some) security professionals do not understand XSRF.
I've interviewed sales and engineering folks from companies that sell security assessment tools, and I've come across many people who don't know what XSRF is or think they know what it is (they confuse it with XSS).
3. It is hard to write a zero knowledge signature for XSRF that is *accurate*.
This point is specific to web application security assessment tools. These tools, for the most part, rely on input and output. To find SQL injection issues for example, the tools fuzz parameters with SQL code to see if the resultant output differs. To find XSS, these tools insert certain HTML characters into the parameters and look to see if the same characters are output without being escaped. Going by this general principle, finding XSRF and guaranteeing a low false positive rate is hard. Assume the following actions:
a. http://www.example.com/servlet/blah?action=hello
b. http://www.example.com/servlet/blah?action=delete_user
It is clear that even though action a. may be XSRF-able, it is the XSRF vulnerability in action b. that would need to be called out as a high risk vulnerability. But how can a scanner differentiate between the two? One possibility would be to rely on a list of English words that when found in a GET or POST request imply that the action is important, but this has the potential of giving rise to high false positives. It also has the potential of missing important actions that may be labeled differently.
Perhaps a better way to approach the issue is for the assessment tool to require the analyst to point out critical actions before the scan is launched. This may take away from the 'point and click' promise marketing departments at security companies like to make.
4. It is hard to *accurately* find XSRF issues using static code analysis.
There are many ways to mitigate XSRF so it can become difficult to tell if a XSRF vulnerability exists in a given piece of source code just by performing static analysis. As with 3., one approach may be for the static code analyzer to require the analyst to pick a method that is responsible for mitigating the issue, causing the analyzer to point out code that doesn't invoke the given method. Yet again, this requires effort on part of the analyst and commercial security vendors prefer to advertise a no-brainer solution.
[NOTE: My thoughts on 3. and 4. are limited to initial brain-storming. If you have any thoughts on elegant solutions on how to find XSRF using automated tools, or know of a tool that already does this well, feel free to comment].
In summary, I feel XSRF hasn't obtained the impact awareness it deserves - yet. Businesses are slowly becoming aware of the risk posed by XSRF, and I sincerely hope the security assessment products catch up soon.