3

Today, I was going through the process of making sure my server is protected against CSRF attacks, and I was wondering why there is not just a SameOrigin flag that I can set on my Cookies. In much the same way that you can set HTTPOnly or Secure on cookies, I think there should be a SameOrigin flag which would only send the cookie if the browser was currently on the same website as what the cookie was set on.

Wouldn't this be an elegant solution to solving CSRF attacks? You could also implement it in a backwards compatible way where cookies that don't have SameOrigin set are just treated the way that cookies have always behaved.

  • 1
    Could you elaborate on "Same Origin" for cookies? Cookies are inherently same origin - they are sent only to the domain/sub-domain they were set by. And who is setting the same origin flag here? The client or the application server? – katrix Jan 12 '17 at 20:36
  • Yes, cookies are sent TO the domain they were set by. However, I want the cookie to only be sent FROM the domain they were set by as well. The same origin flag would be set by the application server and would be stored in the browser with this flag. The browser would need to respect this flag and not send site A's cookies to site A's server via site B. – satnam Jan 12 '17 at 20:40
  • 1
    @satnam Cookies aren't sent by a domain. They are sent by an HTTP client, typically a browser, which is inherently domain-less. You could, in practice, simulate what your describing by dropping or ignoring any sensitive cookies if the referer header is from another domain, but this is not fool-proof either, for instance, a referer is not set if the referer is an HTTPS URL and referee is an HTTP URL, or if the client strips referers for privacy reasons. – Xander Jan 12 '17 at 21:10
  • 2
    There is a draft proposal for "same site cookies". I think only Chrome implements them just now. – paj28 Jan 12 '17 at 21:16
  • @paj28, Yes, I think this proposal is exactly what I want. – satnam Jan 12 '17 at 21:23
2

It is a good idea, and as @paj28 pointed out in the comments, there is already an RFC draft for SameSite cookies.

One downside that is mentioned in the draft:

Consider the scenario in which a user reads their email at MegaCorp Inc's webmail provider "https://example.com/". They might expect that clicking on an emailed link to "https://projects.com/secret/project" would show them the secret project that they're authorized to see, but if "projects.com" has marked their session cookies as "SameSite", then this cross-site navigation won't send them along with the request. "projects.com" will render a 404 error to avoid leaking secret information, and the user will be quite confused.

Basically, a strict SameOrigin cookie would break links to backend components.

The draft also proposes a lenient mode which would send cookies on GET requests across origins, but it is a common problem that many applications do not follow restful, but instead have GET requests that change server state.

Another problem is that applications will still need to implement their own CSRF protection for all those users not using up-to-date cookies, so the extra development costs of correctly configuring SameOrigin cookies may not be worth it for some developers.

1

Cookies are inherently same-origin, in the sense cookies are sent by the browser only to the origin (and possible sub-domains) that set the cookie in the first place. Referring to the information on your comment, cookies are only between the browser and a site. The reason a CSRF attack is successful even though the originating request is from a different domain is because of where the request is going TO, not where its coming FROM.

About backwards compatibility, a non-same-origin cookie could be one that could be set by or sent to other domains. That would be dangerous since you wouldn't want evil.com to receive google.com cookies.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.