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.
Theres 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, youve 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, were 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 drivers 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 dont 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].
Its 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 dont have native support for CSRF prevention, or those that just dont 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 its 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 youd like to contact
Dark Readings
editors directly,
send us a message
.

Last News
▸ Scan suggests Heartbleed patches may not have been successful. ◂ Discovered: 23/12/2024 Category: security	▸ IoT Devices on Average Have 25 Vulnerabilities ◂ Discovered: 23/12/2024 Category: security	▸ DHS-funded SWAMP scans code for bugs. ◂ Discovered: 23/12/2024 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps