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

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
Introducing 'Secure Access Service Edge'
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  7/3/2020
Russian Cyber Gang 'Cosmic Lynx' Focuses on Email Fraud
Kelly Sheridan, Staff Editor, Dark Reading,  7/7/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-5607
PUBLISHED: 2020-07-10
Open redirect vulnerability in SHIRASAGI v1.13.1 and earlier allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via unspecified vectors.
CVE-2020-15001
PUBLISHED: 2020-07-09
An information leak was discovered on Yubico YubiKey 5 NFC devices 5.0.0 to 5.2.6 and 5.3.0 to 5.3.1. The OTP application allows a user to set optional access codes on OTP slots. This access code is intended to prevent unauthorized changes to OTP configurations. The access code is not checked when u...
CVE-2020-15092
PUBLISHED: 2020-07-09
In TimelineJS before version 3.7.0, some user data renders as HTML. An attacker could implement an XSS exploit with maliciously crafted content in a number of data fields. This risk is present whether the source data for the timeline is stored on Google Sheets or in a JSON configuration file. Most T...
CVE-2020-15093
PUBLISHED: 2020-07-09
The tough library (Rust/crates.io) prior to version 0.7.1 does not properly verify the threshold of cryptographic signatures. It allows an attacker to duplicate a valid signature in order to circumvent TUF requiring a minimum threshold of unique signatures before the metadata is considered valid. A ...
CVE-2020-15299
PUBLISHED: 2020-07-09
A reflected Cross-Site Scripting (XSS) Vulnerability in the KingComposer plugin through 2.9.4 for WordPress allows remote attackers to trick a victim into submitting an install_online_preset AJAX request containing base64-encoded JavaScript (in the kc-online-preset-data POST parameter) that is execu...