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
7 Tips for Infosec Pros Considering A Lateral Career Move
Kelly Sheridan, Staff Editor, Dark Reading,  1/21/2020
For Mismanaged SOCs, The Price Is Not Right
Kelly Sheridan, Staff Editor, Dark Reading,  1/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
IT 2020: A Look Ahead
Are you ready for the critical changes that will occur in 2020? We've compiled editor insights from the best of our network (Dark Reading, Data Center Knowledge, InformationWeek, ITPro Today and Network Computing) to deliver to you a look at the trends, technologies, and threats that are emerging in the coming year. Download it today!
Flash Poll
How Enterprises are Attacking the Cybersecurity Problem
How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-3154
PUBLISHED: 2020-01-27
CRLF injection vulnerability in Zend\Mail (Zend_Mail) in Zend Framework before 1.12.12, 2.x before 2.3.8, and 2.4.x before 2.4.1 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via CRLF sequences in the header of an email.
CVE-2019-17190
PUBLISHED: 2020-01-27
A Local Privilege Escalation issue was discovered in Avast Secure Browser 76.0.1659.101. The vulnerability is due to an insecure ACL set by the AvastBrowserUpdate.exe (which is running as NT AUTHORITY\SYSTEM) when AvastSecureBrowser.exe checks for new updates. When the update check is triggered, the...
CVE-2014-8161
PUBLISHED: 2020-01-27
PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allows remote authenticated users to obtain sensitive column values by triggering constraint violation and then reading the error message.
CVE-2014-9481
PUBLISHED: 2020-01-27
The Scribunto extension for MediaWiki allows remote attackers to obtain the rollback token and possibly other sensitive information via a crafted module, related to unstripping special page HTML.
CVE-2015-0241
PUBLISHED: 2020-01-27
The to_char function in PostgreSQL before 9.0.19, 9.1.x before 9.1.15, 9.2.x before 9.2.10, 9.3.x before 9.3.6, and 9.4.x before 9.4.1 allows remote authenticated users to cause a denial of service (crash) or possibly execute arbitrary code via a (1) large number of digits when processing a numeric ...