Friday, April 11, 2008

CSRF presentation at RSA 2008

My RSA 2008 presentation on Cross-Site Request Forgery, “The Sleeping Giant of Website Vulnerabilities”, attracted a nice sized crowd. Somewhere around 200-300 packed the room all eager to learn about this strange and new CSRF thing they’ve only recently heard of. My goals was to explain what CSRF means to them personally and as a website owner or developer. For those just starting out, CSRF can easily appear FUD like, but fortunately once it clicks, everyone gets the potential impact immediately – especially when exposed to the proper examples. That’s key.

For those already in the know, the best guess is the prevalence of CSRF is equal to or greater than that of XSS, statistically the most widespread vulnerability we’re currently aware of. Its also just as dangerous (or more so), extremely difficult to scan for (so we don't really know how bad it is out there), painful and time consuming to fix, and wouldn’t ya now it…all solutions easily bypassed by XSS exploits. My challenge was making the presentation informative and easy to follow for the newly initiated, representing 90% of the audience, yet compelling enough to keep the deep technical folks engaged. A tough balancing act.

I started off by going through a basic CSRF bank transfer example, some Amazon 1-click scamming, Google Search History fun, onto a Gmail email theft, followed by intranet and printer hacking (plus the DNS-pharming attacks found in the wild), then how XSS can be used to bypass CSRF protections using the Samy Worm as a case study, and finally tossed in a little bit of theoretical CSRF click-a-link-go-to-jail for good measure. The flow felt solid, but I plan to make some adjustments. There were several occasions of pin-drop audience silence where I had to stop and ask if people were “getting it” or simply scared by what they saw. From what I gathered it was the later because the hacks all seemed too easy, and they really are.

Judging from the 15 minutes of questions at the end, the dozens people that came up afterwards, not to mention the volumes of people voicing their appreciation to me on the expo show floor -- I’d say the presentation was a success. What more could a speaker hope for.
Over the next 12 months it’s going to be really important that the industry experts keep spreading the word about the importance of CSRF. For those that couldn’t make it to RSA or the presentation, here my CSRF slides complete with references. Thank you everyone reading who was able to attend and I’ll see you next year!

10 comments:

Alexander Berezhnoy said...

Thank you, Jeremiah.
You mention the "Are you sure?" mitigation on the slide 21. Do you mean an additional page with a "yes/no" form and a hidden token?
If this page is hosted at the separate domain (dedicated for this purpose only), can this protection be bypassed by XSS, and how?

Jim Manico said...

Great work, Jeremiah. Enjoyable/informative presentation. Thanks for posting it for the community.

Anonymous said...

The OWASP CSRFGuard project adds token based protection to applications. There are a lot of practical considerations when implementing tokens that the CSRFGuard project has already wrestled with. One very cool feature is using Javascript to add the tokens - which takes advantage of the parser in the DOM.

Also you can use CSRFTester to test applications for CSRF and create some test cases that prove the power of CSRF to disbelievers. It easily handles multi-step CSRF attacks and saves them as HTML with a variety of CSRF approaches (IMG tags, forms, etc...)

Jeremiah Grossman said...

@alexander, glad you liked it. Doesn't have to be an addition page necessarily, but yes, that's what I meant. Essentially all solutions boil down to a secret somewhere that makes a valid request for one user different from another.

To bypass secrets the bad guys require an XSS on the same domain as the secret, wherever that may be. Once you can get JS to run in someones browser, its fairly trivial to XSS them on any dmain where you have prior knowledge of an XSS issue. Hope this helps.

@Jim, oh no sweat. I think just about every presentation I give is posted publicly at some point. We toss them up here. Some require registration, but most of it doesn't.

@Jeff, thanks for reminding me of those, should have included them... just didn't think of it. I also should find the other CSRF solution libraries for the various other language frameworks (if any) to add as references. Would make the preso more complete.

Alexander Berezhnoy said...

Jeremiah,
I just want to clarify the scope of the problem "No CSRF in the presence of the XSS" which you talked about recently.

"To have XSS on a site" is not the same as "to have XSS on the same domain as the secret".

The former is a usual case, and nobody is guaranteed from XSS.
The latter can be proved to be the same as "to have XSS on each of my domain, no matter how small and primitive is the code" (otherwise, I'd place the secret validation on that non-vulnerable domain).

Anonymous said...

Glad to hear the presentation was such a success. I think many of us in the app sec community forget that some of the things we work with on a daily basis are still relatively new to the community as a whole.

It’s great to hear that the word is getting around and more people are learning about the dangers of CSRF.

Jim Manico said...
This comment has been removed by the author.
Jim Manico said...

Jeff,

There is this cool project called "ESAPI" that has CSRF mitigation built-in for Java, PHP and .NET.

http://owasp-esapi-java.googlecode.com
/svn/trunk/javadoc/
org/owasp/esapi/
HTTPUtilities.html#addCSRFToken(java.lang.String)

Anonymous said...

Hey Jeremiah. Anywhere I can view your actual presentation, not just slides ?

Jeremiah Grossman said...

@Alexander, oh I see what you are saying now. Hmph, that's really clever, I didn't even catch that the first time. To see if I got this straight... put yoru CSRF secrets on a separate domain, which if you do it right could limit your XSS attack surface. Nice! This idea should be given more air time.

@michael, so true. Its one of the harder things I've had to learn as a speaker. Being able to identify with what the audience knows or more importantly doesn't know an focus on those areas. Its all about given the right presentation and the right time and place... that alone is a skill . :)

@Jim, thanks for the links!

@ron, I think they recorded the presentation on video, but have no idea where or when it can be obtained. I think maybe I should do a rerun on a webinar or something.