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
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-2021
Published: 2014-10-24
Cross-site scripting (XSS) vulnerability in admincp/apilog.php in vBulletin 4.4.2 and earlier, and 5.0.x through 5.0.5 allows remote authenticated users to inject arbitrary web script or HTML via a crafted XMLRPC API request, as demonstrated using the client name.

CVE-2014-3604
Published: 2014-10-24
Certificates.java in Not Yet Commons SSL before 0.3.15 does not properly verify that the server hostname matches a domain name in the subject's Common Name (CN) field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.

CVE-2014-6230
Published: 2014-10-24
WP-Ban plugin before 1.6.4 for WordPress, when running in certain configurations, allows remote attackers to bypass the IP blacklist via a crafted X-Forwarded-For header.

CVE-2014-6251
Published: 2014-10-24
Stack-based buffer overflow in CPUMiner before 2.4.1 allows remote attackers to have an unspecified impact by sending a mining.subscribe response with a large nonce2 length, then triggering the overflow with a mining.notify request.

CVE-2014-7180
Published: 2014-10-24
Electric Cloud ElectricCommander before 4.2.6 and 5.x before 5.0.3 uses world-writable permissions for (1) eccert.pl and (2) ecconfigure.pl, which allows local users to execute arbitrary Perl code by modifying these files.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.