Phase2Results.php" ); ?> Stronger Cross-site Request Forgery Protection - RuntimeWiki

Stronger Cross-site Request Forgery Protection

From RuntimeWiki

Jump to: navigation, search



Stronger Cross-site Request Forgery Protection

Detailed write-up


All browsers support “cookie” which allows web applications to store a small amount of data on the client side. When a browser sends a request to a server, cookies issued by this server are always sent back as part of the request. A lot of web applications store stateful information using “cookies”. Not uncommonly, cookies can contain security sensitive information.

As a result of “same domain policy”, a server does not have access to cookies issued by other servers, which is good. However, given that browsers always send cookies back to the server as part of every request, this “trust” relationship between client side “cookies” and server side state can be exploited for security breaches. Cross-Site Request Forgery (CSRF) is an attack that typically leverages cookies to breach this trust relationship in launching security attackes.

Citing from reference [1]:

Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.

Why Is This Important?

For most sites, browsers will automatically include with server requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish CSRF from a legitimate user request.

In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website.

Sometimes, it is possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called Stored CSRF flaws. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.

Synonyms: CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

Possible Solutions

In general, I have not seen enough solid proposals to solve the XSRF problem from an Ajax runtime perspective. In general, the best way to prevent XSRF is to rely on developers to write code on the server side to handle such issues. From an Ajax runtime perspective, some of the proposals to make cookie less vulnerable are:

  1. Adding “httpOnly” cookie attribute: Internet Explorer adds a cookie attribute called “httpOnly” that cookies with such attribute are not accessible from scripts. Unfortunately other browsers do not support this. “httpOnly” makes web site less vulnerable from XSS, see reference Mitigating Cross-site Scripting With HTTP-only Cookies
  2. Joe Walker (see reference proposed adding “sameRefererOnly” attribute to cookies so that such cookies will only be sent back to a server if the referring web page is from this server. “sameRefererOnly” will help make cookies more secure, and make it harder to carry out XSRF.

Background material that request this feature


In this section, the contributors should express their opinions about this feature request, such as providing particular technical analysis or describing in prose why this feature is important (or not). It is recommended that each contributor create his own level-3 sub-section (e.g., === Jon Ferraiolo Comments ===).

It is OK for others to insert comments within other people's sections, but as a courtesy please make sure that it is clear which part of the section is original and which section are annotative comments. For example, perhaps annotative comments would be colorized (e.g., enclosed by <span style="color:red">JON: Here is what I think about what you are saying.</span>).

Jon Ferraiolo's comments

It doesn't seem to me that there is much that future browsers can do to eliminate CSRF attacks. Suppose future browsers somehow established barriers to control when Malicious Site M could trigger POST requests to Target Site T. Even if this happened, there is still a mountain of legacy HTML and legacy browsers that would still expose the vulnerabilities.

For the most part, it is incumbent on web sites to implement appropriate server-side CSRF protection (where the server never trusts the client), rather than waiting for some magic pixie dust from future browsers.

The key thing for future browsers is to not open new CSRF attack vectors. For example, the XDomainRequest does not send cookies. From a CSRF prevention perspective, this is good.

Kris Zyp's comments

I agree, I don't think there is anything we really need to push on browser vendors here. This is mainly about improving tools and developer education. The responsibility is in our laps with these issues.

Also, XDomainRequest actually has a slightly larger vector of attack than the W3C/ACs proposal for non-opt-in users, because in XDomainRequest, POST requests can be sent (albiet without cookies) without the user's permission and can be used to create POST requests that would otherwise be unforgeable with forms (like requests with JSON content). I believe an important consideration with XDomainRequest and cross-site XHR is that sufficient capability be provided to developers such that these mechanisms will actually get used. If these mechanisms are excessively limited (and I believe both proposals have some limitations that are unnecessary) developers will simply resort to hacks (like script tag loading) and we are back to square one.

Brad Neuberg's comments

I agree that there is not much the browser can do to help this situation. However, as we add new capabilities to the browser for the other proposals we should think through if they add new attack vectors for CSRF attacks, as Kris mentions.

Phase I Voting - Vote for Your Top 5 Features

NOTE: PHASE I VOTING IS NOW OPEN. (2008-04-01) We have now changed the voting procedure. Instead of putting votes on each separate wiki page, we are asking people to cast their Phase I Votes on the following wiki page:

Phase II Voting

More about this later.

Personal tools