Isn't CSRF a browser security issue?

Question

Regarding cross-site request forgery (CSRF) attacks, if cookies are most used authentication method, why do web browsers allow sending cookies of some domain (and to that domain) from a page generated from another domain?

Isn't CSRF easily preventable in browser by disallowing such behavior?

As far as I know, this kind of security check isn't implemented in web browsers, but I don't understand why. Did I get something wrong?

About CSRF:

• On wikipedia
• On coding horror

Edit: I think that cookies should not be sent on http POST in the above case. That's the browser behavior that surprises me.

Answer 1

Why wouldn't the browser send cookies?

Site A (http://www.sitea.com) sets a cookie for the user.

User navigates to site B (http://www.siteb.com). Site B features integration with site A - click here to do something on site A! The users clicks "here".

As far as the browser can tell, the user is making a conscious decision to make a request to site A, so it handles it the same way it would handle any request to site A, and that includes sending site A cookies in the request to site A.

---

Edit: I think the main issue here is that you think there is a distinction between authentication cookies and other cookies. Cookies can be used to store anything - user preferences, your last high score, or a session token. The browser has no idea what each cookie is used for. I want my cookies to always be available to the site that set them, and I want the site to make sure that it takes the necessary precautions.

Or are you saying that if you search yahoo for "gmail", and then click on the link that takes you to http://mail.google.com, you shouldn't be logged in, even if you told gmail to keep you logged in, because you clicked on the link from another site?

Answer 2

It isn't that a browser is sending the cookie to or from an outside domain, it's the fact that you're authenticated and the site isn't validating the source of the request, so it treats it as if the request came from the site.

As far as whether a browser should disallow that... what about the many situations where cross-site requests are desirable?

Edit: to be clear, your cookie is not sent across domains.

Answer 3

I don't know that there's much the browser can do in that situation since the point of an XSRF attack is to direct the browser to another point in the application that would perform something bad. Unfortunately, the browser has no idea whether or not the request it's being directed to send is malicious or not. For example, given the classic example of XSRF:

<img src="http://domain.com/do_something_bad" />

it's not apparent to the browser that something bad is happening. After all, how is it to know the difference between that and this:

<img src="http://domain.com/show_picture_if_authenticated" />

Answer 4

A lot of the old protocols have big security holes -- think back to the recently-discovered DNS vulnerabilities. Like basically any network security, it's the responsibility of the end-points; yeah, it sucks that we have to fix this ourselves, but it's a lot harder to fix at the browser level. There are some obvious ones (<img src="logoff.php"> looks damn fishy, right?), but there will always be edge cases. (Maybe it's a GD script in a PHP file after all.) What about AJAX queries? And so on...

Answer 5

The cookies for a site are never sent to another site. In fact, to implement a successful CSRF attack, the attacker does not need to have access to these cookies.

Basically, an attacker tricks the user, who is already logged in to the target website, into clicking a link or loading an image that will do something on the target site with that user's credentials.

I.e., the user is performing the action, and the attacker has tricked the user into doing so.

Answer 6

Some people have said they don't think there's a lot the browser can do.

See this:

http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html

It's an overview of a proposal for a new HTTP header to help mitigate CSRF attacks.

The proposed header name is "Origin" and it's basically the "Referer" header minus the path, etc.