There seems to be a problem with Cross-Site Request Forgeries. It seems like a large majority of people have this type of attack confused and I am not just talking about developers or end users. Security professionals still don’t know what this attack vector is (and I’m not talking about higB’s tongue-in-cheek Balls post.) The other week I heard a webinar by a major Web Application Firewall vendor claim his product protected apps from XSS and therefore it was the same as stopping CSRF. Granted, maybe the product can try to prevent both types of attacks, but it sure isn’t going to do it with the same types of checks. This was followed by a web application security meeting where the slides were trying to show a CSRF example and the presenter talked about checking for XSS. If the people in the security industry can’t even get this right, how are we suppose to educate developers and clients about this issue?

Let’s all start by renaming this attack. While I personally like the name ‘OMG you stole all my money without JavaScript’, the more generic ‘Session Riding’ probably works better for the long term. Yes it’s a subtle change, but it states what the attack is doing and drops the unnecessary ‘cross-site’. I’ve also found that many people think scripting is required for a Session Riding attack. While there’s no doubt that you’ll typically find JavaScript included in crafting a complex or obfuscated attack, it’s clearly not a requirement. In fact, it’s one reason these attacks can be so terrifying is that you can browse with all scripting disabled, no third party components, dropped privileges and a fully patched browsers, but a Session Riding attack could still work against you.

I’d recommend reading this PDF and the CSRF FAQ which both go into good deal on Session Riding attacks and countermeasures. But for a quick difference between the two, just look at what your typical attack payload for an XSS attack verses a CSRF attack would be.

XSS Attack Payload:
<script>alert(‘xss’)</script>

Session Riding Payload:
http://www.example.com/changepwd.jsp?newpwd=1234&confirm=1234
 
While you typically need to store/reflect your XSS payload on the site you’re going after, in the case of a Session Riding attack, you can store this URL on any site. In this example payload, we are trying to change the user’s password. JavaScript would not need to be required. The site can be doing whitelist input validation and it wouldn’t stop this attack.

There are plenty of ways to protect against these attacks (CAPTCHA, re-entering password, additional secure tokens, …). Some of the popular web application frameworks even have settings or plug-ins that can be dropped in to prevent Session Riding attacks. However, if we don’t understand the risk or report the threat, how can we help developers to implement this correctly into their applications?

-b3nn