Home » Data Protection » Application Security

Threat Watch: Cross Site Request Forgery (CSRF)

Why a little-known web application vulnerability could cause big problems

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 wonâ¬"t 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.