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.
Did you read?
http://sla.ckers.org/forum/read.php?4,11594
http://sla.ckers.org/forum/read.php?4,11780
they confuse it with XSS
That's because CSRF can't be prevented if there is a sitewide XSS in play as well. Maybe you're not confusing it with XSS?
The other thing is - why would you want to find it automated? CSRF is a business logic flaw. It is best found like other business logic flaws.
The reason I wouldn't use an automatic static source code scanner (e.g. FortifySoftware SCA) to find CSRF is because I would just look at the code (manual review). If you're not using full CSRF protections in your code, (e.g. using ViewState on POST operations but not using Validator and SSL and not protecting certain operations with a password, and not timing out sessions, etc), then you're probably vulnerable!
The reason I wouldn't use an automated dynamic analysis fault-injection scanner (e.g. HP SPI Dynamics WebInspect) is because I would just create two users in the web application (or ask the company/organization under pen-test for two accounts if they have to be tied to unique identifiers such as social security numbers or bank account numbers). Once you have two users for the application, you can try and pass information between them like you would do for finding any other normal business logic flaw. Then you try and work other business logic flaws as well. This is all a normal part of a manual black-box assessment (source-code assisted or not). This is really the only way to know, so you're right - but that doesn't mean that certain tools can't help speed up the manual process. And what's wrong with a few manual assessment techniques, especially if augmented by some good tools? Why does everything have to be point-and-click?
Hi Dre
Thanks for your comment.
Having spent a lot of time dealing with people in the industry, when I said I've come across people who do not understand XSS, I was referring to people who do not understand what XSS is - period. I was not referring to people who understand what XSS is and are aware of it's business impact compared to XSRF.
(You make a good point about not being able to prevent XSRF should a sitewide XSS issue exist. I agree that it would be very hard to prevent a XSRF condition in this case, but I I'd like to add that I think that the risk caused by a sitewide XSS vulnerability would retain its business impact regardless of XSRF)
I don't know what you mean by that. A XSRF vulnerability doesn't require XSS. Maybe you typed that wrong? If not, perhaps you can rephrase so it is more clear.That said, I think we are both in agreement. In fact, I challenge you to find anyone who feels more strongly than me about the perils of relying on automated application security assessments!
I do agree that organizations who *solely* rely on automated solutions are NOT doing the right thing at all - in fact, as a security purist, my heart aches to see organizations throw money on solutions that are guaranteed to be automated - they think they are saving money, but I think they end up paying more because they don't fix the root cause. I am a huge advocate of implementing a thorough SDLC process with the goal of developing secure software.
The reason I brought up the points about automated assessment tools is to attempt to brainstorm on reasons why we are not seeing any product vendors come up with solutions on XSRF. I think we both know the reasons why, but they dare not admit it. That said, as a scientist, I would be interested in hearing about a proposal that may assess this automatically (I'm not holding my breath however).
In summary, I agree with you that the question 'is an application vulnerable to XSRF?' tends towards a design review rather than something that relies on fuzzing and patterns.