Risk
7/17/2013
00:14 AM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%

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
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading, September 16, 2014
Malicious software is morphing to be more targeted, stealthy, and destructive. Are you prepared to stop it?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-1032
Published: 2014-09-17
Cross-site scripting (XSS) vulnerability in the Euroling SiteSeeker module 3.x before 3.4.5 for EPiServer allows remote attackers to inject arbitrary web script or HTML via unspecified vectors. NOTE: the provenance of this information is unknown; the details are obtained solely from third party inf...

CVE-2012-1417
Published: 2014-09-17
Multiple cross-site scripting (XSS) vulnerabilities in Local Phone book and Blacklist form in Yealink VOIP Phones allow remote authenticated users to inject arbitrary web script or HTML via the user field to cgi-bin/ConfigManApp.com.

CVE-2012-1506
Published: 2014-09-17
SQL injection vulnerability in the updateStatus function in lib/models/benefits/Hsp.php in OrangeHRM before 2.7 allows remote authenticated users to execute arbitrary SQL commands via the hspSummaryId parameter to plugins/ajaxCalls/haltResumeHsp.php. NOTE: some of these details are obtained from th...

CVE-2012-1507
Published: 2014-09-17
Multiple cross-site scripting (XSS) vulnerabilities in OrangeHRM before 2.7 allow remote attackers to inject arbitrary web script or HTML via the (1) newHspStatus parameter to plugins/ajaxCalls/haltResumeHsp.php, (2) sortOrder1 parameter to templates/hrfunct/emppop.php, or (3) uri parameter to index...

CVE-2012-2583
Published: 2014-09-17
Cross-site scripting (XSS) vulnerability in Mini Mail Dashboard Widget plugin 1.42 for WordPress allows remote attackers to inject arbitrary web script or HTML via the body of an email.

Best of the Web
Dark Reading Radio