After Cross Site Scripting (XSS), the second most common web application security exploit is probably one you haven’t heard of: Cross Site Request Forgery (or CSRF for short). This little-known but very troubling web-application attack essentially hijacks a user’s browser to perform actions he or she didn’t intend--anything from ordering merchandise to sending threatening letters to the White House.
By their nature CSRF attacks are hard to prove. Unless you have a case like the Samy worm that produces a major disruption, it’s hard even to know such an exploit is out there. (The 2005 Samy worm was only discovered because it used CSRF to temporarily make the writer the most popular person on MySpace.) Unlike an XSS attack, which tricks the site into uploading malicious code, CSRF simply has the site execute legitimate commands--just not commands issued by the user.
Despite this type of attack being difficult to detect, Jeremiah Grossman, CTO at web application security vendor Whitehat Security, estimates that it’s the second most common web application attack, after XSS, and believes that it is about where XSS was a couple of years ago: Few security professionals are aware of it, but it is being increasingly exploited by computer criminals.
Here’s how it works. The attacker inserts a snippet of code--often disguised as an IMG, SCRIPT or IFRAME in HTML, or an IMAGE object in Javascript--that contains a payload of the form "http://host/?command". This code instructs the victim's browser to send a request to the target web site. If the victim is authenticated on the site or the site does not require authentication, the targeted website executes the command without further prompting.
This example won’t work if the site uses the POST command to receive information from the web browser, instead of the GET command. (Both POST and GET are HTTP commands used to request files from a web server.) But attacking a site that uses POST is only slightly more complex, with the attacker using a Javascript form in place of the simple command.
While the dangers of such attacks on sites that require authentication are obvious, even CSRFs against sites that don’t require authentication can be damaging. Grossman points out that Whitehouse.gov doesn’t require authentication, but sending a bunch of threatening e-mails to the White House is probably going to get you a visit from the FBI.
Of course, the vast majority of people who encounter the attack on a site that does have authentication won’t be logged into the site. But then, almost no one buys penis enlargement pills from spam ads, either--it just takes one or two victims to make the effort worthwhile. "The bad guys are just looking in the off chance someone is logged into that particular website," Grossman says.
If the technique is simple, good defenses aren’t. For one thing, there’s really no way the user can protect himself, short of extreme web browsing habits. For the most part, the defense has to come from the threatened web site.
The most basic defense is authenticating each session individually and possibly authenticating again before the user can perform risky actions. Amazon.com has reportedly adopted this method and now requires reauthentication before a customer performs actions such as changing the shipping address.
A more sophisticated defense involves making sure the bad guys wont have the exact command to execute an action on the target website. "Essentially what the developer is trying to do is make sure the request is unpredictable," Grossman says. "The same request I use to do a wire transfer will not be identical to one you make." Typically this would involve generating cryptographic tokens for each user.
It’s not an easy option. "The solution has to be on every web site, and the logic has to be buried in the middle of a function flow," Grossman says, noting that he isn’t aware of any third-party software application developers can use to add that feature.
Oh, and there’s one other problem. "With every solution we’re aware of, if a web site is vulnerable to a XSS attack they [the CSRF protections] don’t work," Grossman says. In other words, developers need to protect against XSS before they can protect against CSRF.