I’ve been finishing the OWASP Top 10. One of the things I profess I know little about is automated tools. Up until recently, they’ve created more work (false positives, false negatives) than is actually justified in running the tool. However, they are getting better.
After discussions with Jeremiah Grossman of White Hat Security and WASC fame, I was a little surprised to find that none of the tools can detect CSRF vulnerabilities. This is doubly surprising in that of all the attacks, this one is tractable given a flexible enough engine.
The basic game plan is this:
a) Watch an action take place
b) Determine what changed so you can create a signature of the attack
c) Create a pre-canned request from (a) but add in your CSRF locator strings
d) Go.
Now, how to exploit the CSRF? It will need something like a eggshell site of pre-canned CSRF attack payloads. Most CSRF attacks start with a XSS, so the game plan has to be … find a XSS and insert the eggshell in there. This is not hard, just requires that the victim browser has access to the eggshell site, or the CSRF attack is small enough to be self contained by the hosting site itself (as in the Samy worm).
However, it is fun to read professionals dismissing the potential of CSRF. This list either shows ignorance about how many apps work, or worse, ignorance of how you can easily submit a form from a GET request, creating a POST request. All it requires is sufficient payload space to include a link to a vulnerable reflected or persistent XSS to start obviating the HTML stream. Once that’s done, CSRF is all but in the can.
Interesting. We need to do more, not less CSRF promotion in our camp. However, on the other hand, our defenses are woeful, so maybe leaving it in a less than well understood state is a good idea. Hard to say. What do you think?
Leave a Reply