The Complexities of Assessing XSRF Automatically Yet Accurately

by Nitesh Dhanjani

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:

2 Comments

dre
2007-07-17 16:18:29
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?

Nitesh
2007-07-17 18:25:35
Hi Dre


Thanks for your comment.


they confuse it with XSS

That's because CSRF can't be prevented if there is a sitewide XSS in play as well.


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)


Maybe you're not confusing it with XSS?

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.