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.

Risk

8/13/2013
05:51 PM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

Can We End CSRF With Header-Based Browser Policies?

Newly proposed Storage Origin Security (SOS) policy presented at Black Hat could offer a simpler way to combat cross-site request forgery

As the security community continues to look for easier ways to mitigate the risk of all-too-common Cross-Site Request Forgery (CSRF) attacks, many within the industry have lamented the difficulties that make it tough to do CSRF token deployment just right. With so many moving parts, CSRF tokens are frequently used insecurely, if at all. That is why a pair of researchers from Qualys are now proposing a new header-based browser policy that they say could affect a much simpler and, therefore, more broadly effective means of countering CSRF attack techniques.

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

"There's nothing particularly wrong with the idea of the CSRF token approach -- the problem is people make mistakes," says Mike Shema, director of engineering for Qualys, who, together with his colleague Vaagn Toukharian, presented at Black Hat earlier this month a new HTTP header-based policy they call Session Origin Policy (SOS). "With CSRF tokens, you've got to convince every developer in the world to use CSRF tokens correctly. Here, rather than going after every developer in the world like Vaagn said, we're just trying to convince those four or five developers that work on browsers. If you can get this into the browser, then you can have much better security."

A proposed additional browser-based policy similar to the Content Security Policy, SOS could be applied on one or more cookies for a Web application on a per-cookie or collective basis so that the developer is in the driver's seat for dictating whether the browser uses specific cookies during cross-origin requests.

"You want to make sure that these actions that users are making, like resetting passwords or transferring money, are user-initiated actions, that the user intended to do this, rather than the browser sneaking that request behind the scenes. Because the fundamental problem behind CSRF is that if someone has a session token or session cookie, and I get his browser to do something, that session cookie is going to go along with that request," Shema says. "We said, why don't we give developers or Web applications a way to control whether or not that cookie goes along with that request?"

Shema says that his team focused on the cookie to make it easier to mitigate attack risks without enumerating every single Web form and auditing that with a CSRF token, and because "most Web apps are throwing their session into [them]."

It's hard to say whether SOS will catch on, but some say it has promise.

"Fully implemented, this could be the groundbreaking solution needed in the Web application security space to eradicate CSRF," says Subu Ramanathan, principal consultant with Security Compass, explaining that rather than taking the traditional approach to mitigating CSRF through secure development strategies, SOS relies on impact mitigation. "[It] targets the problem at a cookie level and, if implemented by browsers, can prevent the user’s Web browser from sending session ID cookies for cross-domain requests for specific resources as configured by the Web server."

Ramanathan believes that the logic behind SOS is sound and could be a boon for dev teams working with frameworks that don't have native support for CSRF prevention, or those that just don't have the resources to divert from developing core feature sets. The big problem, as Ramanathan sees it, is that in order for it to work, the browsers have to adopt the SOS policy and outlined HTTP headers.

"One thing we know for certain is that this type of broad browser change does require time, so I would encourage development teams to use existing mitigation patterns for addressing CSRF while keeping tabs on the SOS policy adoption rate by the various Web browsers," he says.

According to Kyle Adams, chief software architect for Junos WebApp Secure at Juniper Networks, the SOS policy proposal is a step in the right direction. He believes that CSRF does need to be solved at the browser level and by allowing sites to change policy. But he thinks the proposal could still use some tweaks.

"The research implies that the browsers would have to maintain this complicated cookie permission policy, on top of all other policies it's already managing for cookies and cross-origin requests," he says. "The chances of all browsers getting this perfect in the first implementation are pretty low. As such, there are likely to be numerous vulnerabilities discovered either in this policy system or as a side effect of this policy system integrating with someone else."

He believes it might be better to require a set policy when issuing the Set-Cookie header to the client, and only changing the policy by reissuing the entire cookie.

"This means that for an attacker to change the policy, they would have to already know the value of the cookie, which means they have no business launching a CSRF attack to begin with because they would already have the cookie and could hijack the whole session locally," Adams says. "Every cookie would have its policy defined at assignment; there would be no need to do 'preflight' checks. This means that there would be less wasted bandwidth, less opportunity to use it for DDoS, and no chance of a hacker maliciously influencing the policy."

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
Comments
Newest First  |  Oldest First  |  Threaded View
Aviation Faces Increasing Cybersecurity Scrutiny
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/22/2019
Microsoft Tops Phishers' Favorite Brands as Facebook Spikes
Kelly Sheridan, Staff Editor, Dark Reading,  8/22/2019
MoviePass Leaves Credit Card Numbers, Personal Data Exposed Online
Kelly Sheridan, Staff Editor, Dark Reading,  8/21/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
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
CVE-2016-6154
PUBLISHED: 2019-08-23
The authentication applet in Watchguard Fireware 11.11 Operating System has reflected XSS (this can also cause an open redirect).
CVE-2019-5594
PUBLISHED: 2019-08-23
An Improper Neutralization of Input During Web Page Generation ("Cross-site Scripting") in Fortinet FortiNAC 8.3.0 to 8.3.6 and 8.5.0 admin webUI may allow an unauthenticated attacker to perform a reflected XSS attack via the search field in the webUI.
CVE-2019-6695
PUBLISHED: 2019-08-23
Lack of root file system integrity checking in Fortinet FortiManager VM application images of all versions below 6.2.1 may allow an attacker to implant third-party programs by recreating the image through specific methods.
CVE-2019-12400
PUBLISHED: 2019-08-23
In version 2.0.3 Apache Santuario XML Security for Java, a caching mechanism was introduced to speed up creating new XML documents using a static pool of DocumentBuilders. However, if some untrusted code can register a malicious implementation with the thread context class loader first, then this im...
CVE-2019-15092
PUBLISHED: 2019-08-23
The webtoffee "WordPress Users & WooCommerce Customers Import Export" plugin 1.3.0 for WordPress allows CSV injection in the user_url, display_name, first_name, and last_name columns in an exported CSV file created by the WF_CustomerImpExpCsv_Exporter class.