I've been looking at Chris Shiflett's CSRF GET to POST converter and have to say that it's got me a bit freaked out. I don't normally do the annual prediction thing, but the more I look at it, the more I think we'll see 2008 as the year of the CSRF, particularly if social networking sites continue to grow in popularity among less-technical users.
I've seen mention that the attack can be mitigated by using a nonce of sorts in the form and session data, a value that must be posted back with the form for a valid request. But as I look at how Chris executed his redirector (loading an iframe on click), I can't help but think that once I have an unprotected and confused security context on the browser, I'm able to work around such nonces when:
1) I can make a reasonable guess that the user has an authenticated session. I don't always have to be right, just every couple of times will do fine.
2) I can parse out a response from the server such that I can snag the nonce parameter. Not hard once I have a confused, unprotected scripting context in an iframe that the browser is mistakenly trusting.
#1 is not a big deal. I can make some reasonable guesses, target my links appropriately using a bit of social engineering. Doesn't have to be terribly accurate, just moderately successful and I can grab some "seed" accounts from which to stage future attacks.
#2 is easy - if I can execute script in an iframe (as Chris' demonstrates), then I can string together multiple XHRs. As long as the user has a session I can piggy-back on, extracting a form nonce is no more difficult than submitting the post in Chris' redirector.
Would love to hear some thoughts on how others are dealing with the issue in the face of user-provided content.
Oh, and if you're wondering how to execute one of those attacks, you have a Blogger account *and* you clicked on the link to Chris' account above, consider yourself vulnerable - that's about all it takes.
Thursday, January 17, 2008
CSRF is the new XSS
Subscribe to:
Post Comments (Atom)
2 comments:
You must error on the side of caution in what you allow users to input - even if is at the cost of convience. That is the bottom line.
You must also worry about what content you are pulling into your system and displaying to the end user in the browser. This includes RSS, etc.
Interesting you mention RSS. I had a sentence in the original post about Atom feeds but took it out for clarity's sake. I can certainly see how that could be a vector for CSRF as well, particularly when combined with poorly-written apps (state changes via GET) and browser-based readers.
Post a Comment