While they may not pack the same punch or crop up at the same frequency as injection or cross site scripting attacks, cross site request forgery (CSRF) attacks should still be very much on the radar of application developers. This year, CSRF may have gotten bumped down a few notches on the OWASP top Web app vulnerability rankings, but it still remains on the top ten and, according to some, CSRF attacks may well be accelerating.

"These attacks are exceptionally dangerous because they directly target website users and are very easy to create and launch with a high degree of success," says Kyle Adams, chief software architect for Junos WebApp Secure at Juniper Networks. "CSRF attacks are also very difficult to detect, because they look very much like a legitimate request from a trusted user."

OWASP currently ranks CSRF attacks as the number eight most common and critical Web application vulnerability, down from the five spot since the last list was compiled. But a report out from FireHost this spring showed that, year-over-year, the first quarter of 2013 saw a 132 percent increase in CSRF attacks.

Designed to exploit the domain cookie trust model, CSRF attacks essentially take advantage of the trust the Web application has in its authenticated users, says Subu Ramanathan, principal consultant with Security Compass.

"In order to execute this attack, a user would have to navigate to a malicious website while logged into the victim Web application," says Ramanathan. "The malicious website, being designed to attack users of the victim application, would make [requests] to complete sensitive transactions on the victim application on behalf of the user behind the scenes."

Therein lies the rub—the application being attacked can't really distinguish the bogus request from a real one since the attacks is originating from the browser.

"Using this technique, an attacker can perform any sensitive transaction such as money transfer, password change, reset, or delete account that is vulnerable to CSRF," Ramanathan says.

According to Adams, the inherent problem with CSRF attacks is that they use the HTTP protocol exactly as it was designed to work.

[How does HTML5 increase risk? See Beware of HTML5 Development Risks.]

"The security flaw is deep in the core of the HTTP protocol. As such, companies have to take the burden of fixing it in each of their apps, or the HTTP protocol has to be extended and everyone is forced to change their apps anyway to handle the new protocol," says Adams, explaining that it's not realistic for the latter to happen. "Browsers are slowly starting to add protections as well, but they are best-effort at this stage and can still be overcome by an attacker."

And sometimes vulnerabilities in the browser can make it easier for attackers to leverage CSRF. Just last month in its Firefox 22.0 release, Mozilla patched a bug discovered by WhiteHat Security researcher Johnathan Kuskos that made the browser vulnerable to HEAD request verb tampering and therefore more susceptible to CSRF.

Most of the CSRF risk mitigation measures in common use today are server-side, primarily through CSRF tokens.

"Most rely on the website in question adding an unpredictable parameter to every transaction," says Ari Elias-Bachrach, application security consultant and trainer for Defensium, referring to the principle behind tokens. "In .NET, this can be done by activating the viewstate userkey, or using Microsoft's antiforgerytoken class. In Java you can do it manually, or use the CSRF filter that exists in newer versions of Tomcat."

By adding a token to the request process, developers make it more difficult to craft URLs to carry out an attack.

"Because the CSRF token is different for every user, attackers cannot predict a static URL to point image tags to, which is how they typically exploit a URL during a CSRF attack," Adams says. "Given they also cannot read the CSRF cookie, they can't get the value using JavaScript to craft the correct URL, either."

But tokens do have their limitations. Without an added layer of technology to smooth the process, they typically require legacy apps to undergo updating of application logic to handle to token. And if the application is vulnerable to other types of vulnerabilities that could give the attacker access to site content, it would render the security of the token ineffective. So, a site utilizing tokens but vulnerable to cross-site scripting could potentially still suffer a CSRF.

In fact, next month at Black Hat, two researchers will present on how a new side-channel vulnerability in HTTPS traffic could make it possible for attackers to learn the value of CSRF tokens.

However, there may also be some relief coming from the research community at Black Hat as well, most notably from a trio of Qualys researchers who plan on proposing a new header-based HTTP policy for cookies and session objects that could head off CSRF attacks without requiring HTML modifications. They say the proposed solution "focuses on simplicity to make it easier to retrofit on current apps, but requires browsers to support a new client-side security control."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.