Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


12:14 AM
Connect Directly

CSRF Still Armed And Dangerous

Cross-site request forgery may not get the same attention as SQLi or XSS, but it still poses considerable risk to Web apps

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.

Click here for more of Dark Reading's Black Hat articles.

"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.

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
RDP Bug Takes New Approach to Host Compromise
Kelly Sheridan, Staff Editor, Dark Reading,  7/18/2019
The Problem with Proprietary Testing: NSS Labs vs. CrowdStrike
Brian Monkman, Executive Director at NetSecOPEN,  7/19/2019
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2019-07-23
Upwork Time Tracker doesn't verify the SHA256 hash of the downloaded program update before running it, which could lead to code execution or local privilege escalation by replacing the original update.exe.
PUBLISHED: 2019-07-23
GNUBOARD5 has XSS that allows remote attackers to inject arbitrary web script or HTML via the "board title contents" parameter, aka the adm/board_form_update.php bo_subject parameter.
PUBLISHED: 2019-07-23
Jsish 2.4.84 2.0484 is affected by: Reachable Assertion. The impact is: denial of service. The component is: function Jsi_ValueArrayIndex (jsiValue.c:366). The attack vector is: executing crafted javascript code. The fixed version is: after commit 738ead193aff380a7e3d7ffb8e11e446f76867f3.
PUBLISHED: 2019-07-23
If hyperthreading is not disabled, a timing attack vulnerability exists, similar to previous Spectre attacks. Apple has shipped macOS 10.14.5 with an option to disable hyperthreading in applications running untrusted code in a thread through a new sysctl. Firefox now makes use of it on the main thre...
PUBLISHED: 2019-07-23
A possible vulnerability exists where type confusion can occur when manipulating JavaScript objects in object groups, allowing for the bypassing of security checks within these groups. *Note: this vulnerability has only been demonstrated with UnboxedObjects, which are disabled by default on all supp...