Home > Conferences, Defcon > Defcon talk: CSRF: Yeah, It still works by Mike “mckt” Bailey and Russ McRee

Defcon talk: CSRF: Yeah, It still works by Mike “mckt” Bailey and Russ McRee

The talk is designed to demonstrate that an endless stream of applications, platforms, and even critical infrastructure is actually vulnerable to Cross Site Request Forgery (CSRF).

Most vendors that refuse to address these issues all use the same argument: “If users do something stupid it their problem.” Well, if they do it in your context it is your problem. This is what the guys from securewebmail.com found out as well.

So where have we found CSRF issues?
McAfee has a site which you van use to scan your own site. With CSRF an attack could use your session to create an extra account and then use that account to scan your sites and get your vulnerabilities.
Wireless routers like the Linksys WRT wireless and others are vulnerable and  can be owned and opened up to outsider attacks.
ESPN, one of the largest coomunity websites in the world is vulnerable to a CSRF attack against itself. It is wormable without any javascript at all. Noscript will not help you…
Dokeos, an e0learning platform which is also used by the Belgian Defense Agency is also vulnerable. Given its installed base, Dokeos has Millions of users
The osCommerce platform used for thousands of online shops with more then 9,300,000+ users. CSRF can be used here to steal credit card data. Interestingly a lot of these sites are branded McAfee secure.
ZenCart is also vulnerable and widely used.
cPanel/WHM is used in over 7,000,000 sites and it is also vulnerable. cPanels responsed that the cannot fix it because “it is a feature.”

But CSRF has other implications as well. It can be used to e.g. forge a persons browser history, which obviously has legel implications. “People have been convicted based on their search history.”

Alternatively it can be used to polute peoples shopping cart history on e.g. Amazon. This might make valuable advertising

Myths in CSRF mitigation.

  • Only work via POST requests – This doesn’t always work
  • Referrer checking – Referrers get striped in SSL session, also users turn referrer checking of for privacy reasons.
  • Multi-step transactions – Multi-step transactions can also be perfored with CSRF

What does work?

  • CAPTCHA’s – If they are implemented the right way
  • Re authentication – Requesting reauthentication before performing critical actions is a good mitigation action
  • Unique request Tokens – make sure session tokens are cryptographically secure.
  • Share/Bookmark
Categories: Conferences, Defcon Tags: , , ,
  1. No comments yet.
  1. No trackbacks yet.