Security Threat: Cross Site Request Forgery (CSRF)

If you are responsible for the security of a Web site, chances are darn good it’s got at least one serious vulnerability lurking just beneath the surface. I’m talking about CSRF, or “Cross Site Request Forgery,” and it’s just beginning to be explored by attackers, phishers, and other miscreants.

(Note that CSRF is not to be confused with cross-site scripting, or XSS. They’re distinctly different.)

Before I continue, however, let me just say that I seriously don’t consider myself a “FUD guy”—meaning, I’m not one to try to scare my readers or customers into submission using Fear, Uncertainty, and Doubt. I prefer instead to rely on facts and, when asked, opinions and recommendations. But I’m always explicitly clear about which I’m talking about.

That said, CSRF is a big deal. This is not a fire drill. It affects a huge percentage of today’s Web applications. Numbers are not yet clear, but there are some estimates as high as 80-90% of today’s Web apps are affected by CSRF.

Perhaps more to the point, though, when a CSRF vulnerability is exploited, the attacker has access to all the information and functions accessible to the victim’s account. If the victim can transfer money (to the attacker’s account), the attacker can transfer money, and without the victim’s consent or knowledge. No kidding.

So just what is a CSRF vulnerability and what makes it so heinous? Here’s the scenario: you’re logged into a Web site, or the site has placed a “remember me” cookie in your browser. While the session or cookie is active, you receive an unsolicited email that’s either directly or indirectly—via, for example, a “spambot” network—from the attacker. The email is HTML formatted, and includes an “image tag,” which is an instruction to the HTML renderer to grab an image from another site, normally via a URL pointing to a graphics file.

But this image tag doesn’t contain a harmless pointer to an image file. Instead, it contains an explicit URL pointing the HTML rendering engine off to the site you were logged into back in your browser. (Remember, the email comes in while you’re logged in.)

The request to the web site you’re logged into gets doled out to the HTML subsystem—normally your browser. But your browser knows you have a session open on that site, and it gleefully sends along your session credentials (e.g., JSESSIONID, active cookies).

Now, the really nasty bit… That image request has embedded in it an explicit set of instructions to your Web site that instruct it to, for instance, transfer funds, change your password, send your login credentials to the attacker, or some other unpleasant function.

It’s real. We’ve already seen CSRF attacks that do some fairly straight forward things, that I’d consider as “proof of concept” code to validate the effectiveness of CSRF. To name a couple examples, Netflix had a CSRF flaw that enabled an attacker to add a movie to the victim’s movie queue and place it at the front of the line. (That could result in some interesting discussions with your spouse…) Google had a CSRF flaw that enabled an attacker to change the victim’s default language to Klingon (or any other language, for that matter).

We’ve also seen published examples of CSRF flaws being used to change the configuration of popular routers. (Does the device at 192.168.1.1 on your network have a username/password of admin/admin?) But these are just child’s play compared to what CSRF is really capable of.

CSRF first really came to my attention when the Open Web Application Security Project (OWASP) published its 2007 top 10 list of security defects. Unlike all other defects on previous OWASP top 10 lists, however, CSRF was put on the list in advance of statistical verification. This was done because the OWASP team felt strongly that CSRF is real and urgently needs to be fixed as soon as possible.

Fortunately, the OWASP folks didn’t stop there. They’ve also released the CSRF Guard, which is an open source Java J2EE class library that provides simple and effective protection against CSRF vulnerabilities.

The way the OWASP CSRF Guard works is to include a randomly generated and unpredictable token in each web page, in the form of a hidden HTML field. This allows valid browser requests to pass, but blocks CSRF requests in their tracks, since they don’t have access to this token.

The CSRF Guard is not just simple and effective, it’s free. Kudos to the good folks at OWASP for making this available. And, similar solution sets are available or being developed in other programming languages as well.

So, CSRF is a nasty little vulnerability with potentially very large impacts on vulnerable web site. But it’s also easy to safeguard against. There’s just no excuse for a Web site to remain vulnerable to them. Left unfixed, CSRF issues provide the attacker with a direct avenue of attack to your customers.