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
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 Truths About BEC Scams
Ericka Chickowski, Contributing Writer,  6/13/2019
DNS Firewalls Could Prevent Billions in Losses to Cybercrime
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/13/2019
10 Notable Security Acquisitions of 2019 (So Far)
Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
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-2019-12865
PUBLISHED: 2019-06-17
In radare2 through 3.5.1, cmd_mount in libr/core/cmd_mount.c has a double free for the ms command.
CVE-2017-10720
PUBLISHED: 2019-06-17
Recently it was discovered as a part of the research on IoT devices in the most recent firmware for Shekar Endoscope that the desktop application used to connect to the device suffers from a stack overflow if more than 26 characters are passed to it as the Wi-Fi name. This application is installed o...
CVE-2017-10721
PUBLISHED: 2019-06-17
Recently it was discovered as a part of the research on IoT devices in the most recent firmware for Shekar Endoscope that the device has Telnet functionality enabled by default. This device acts as an Endoscope camera that allows its users to use it in various industrial systems and settings, car ga...
CVE-2017-10722
PUBLISHED: 2019-06-17
Recently it was discovered as a part of the research on IoT devices in the most recent firmware for Shekar Endoscope that the desktop application used to connect to the device suffers from a stack overflow if more than 26 characters are passed to it as the Wi-Fi password. This application is install...
CVE-2017-10723
PUBLISHED: 2019-06-17
Recently it was discovered as a part of the research on IoT devices in the most recent firmware for Shekar Endoscope that an attacker connected to the device Wi-Fi SSID can exploit a memory corruption issue and execute remote code on the device. This device acts as an Endoscope camera that allows it...