Why Same-origin policy isn't enough to prevent CSRF attacks?

Question

First of all, I assume a backend that control inputs to prevent XSS vulnerabilities.

In this answer @Les Hazlewood explain how to protect the JWT in the client side.

Assuming 100% TLS for all communication - both during and at all times after login - authenticating with username/password via basic authentication and receiving a JWT in exchange is a valid use case. This is almost exactly how one of OAuth 2's flows ('password grant') works. [...]

You just set the Authorization header:

Authorization: Bearer <JWT value here>

But, that being said, if your REST client is 'untrusted' (e.g. JavaScript-enabled browser), I wouldn't even do that: any value in the HTTP response that is accessible via JavaScript - basically any header value or response body value - could be sniffed and intercepted via MITM XSS attacks.

It's better to store the JWT value in a secure-only, http-only cookie (cookie config: setSecure(true), setHttpOnly(true)). This guarantees that the browser will:

1. only ever transmit the cookie over a TLS connection and,
2. never make the cookie value available to JavaScript code.

This approach is almost everything you need to do for best-practices security. The last thing is to ensure that you have CSRF protection on every HTTP request to ensure that external domains initiating requests to your site cannot function.

The easiest way to do this is to set a secure only (but NOT http only) cookie with a random value, e.g. a UUID.

I don't understand why we need the cookie with the random value to ensure that external domains initiating requests to your site cannot function. This doesn't come free with Same-origin policy?

From OWASP:

Checking The Origin Header

The Origin HTTP Header standard was introduced as a method of defending against CSRF and other Cross-Domain attacks. Unlike the referer, the origin will be present in HTTP request that originates from an HTTPS url.

If the origin header is present, then it should be checked for consistency.

I know that the general recommendation from OWASP itself is Synchronizer Token Pattern but I can't see what are the vulnerabilities that remains in:

• TLS + JWT in secure httpOnly cookie + Same-origin policy + No XSS vulnerabilities.

UPDATE 1: The same-origin policy only applies to XMLHTTPRequest, so a evil site can make a form POST request easily an this will break my security. An explicit origin header check is needed. The equation would be:

• TLS + JWT in secure httpOnly cookie + Origin Header check + No XSS vulnerabilities.

Answer 1

Summary

I had a misunderstood concepts about Same-origin policy and CORS that @Bergi, @Neil McGuigan and @SilverlightFox helped me to clarify.

First of all, what @Bergi says about

SOP does not prevent sending requests. It does prevent a page from accessing results of cross-domain requests.

is an important concept. I thought that a browser doesn't make the request to the cross domain accordingly to the SOP restriction but this is only true for what Monsur Hossain calls a "not-so-simple requests" in this excellent tutorial.

Cross-origin requests come in two flavors:

• simple requests
• "not-so-simple requests" (a term I just made up)

Simple requests are requests that meet the following criteria:

• HTTP Method matches (case-sensitive) one of:
  • HEAD
  • GET
  • POST
• HTTP Headers matches (case-insensitive):
  • Accept
  • Accept-Language
  • Content-Language
  • Last-Event-ID
  • Content-Type, but only if the value is one of:
    • application/x-www-form-urlencoded
    • multipart/form-data
    • text/plain

So, a POST with Content Type application/x-www-form-urlencoded will hit to the server (this means a CSRF vulnerability) but the browser will not make accessible the results from that request. A POST with Content Type application/json is a "not-so-simple request" so the browser will make a prefligth request like this

OPTIONS /endpoint HTTP/1.1
Host: https://server.com
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: https://evilsite.com
Access-Control-Request-Headers: content-type
Accept: */*
Accept-Encoding: gzip, deflate, sdch
Accept-Language: es-ES,es;q=0.8

If the server respond with for example:

Access-Control-Allow-Origin: http://trustedsite.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: content-type
Content-Type: text/html; charset=utf-8

the browser will not make the request at all, because

XMLHttpRequest cannot load http://server.com/endpoint. Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header contains the invalid value 'trustedsite.com'. Origin 'evilsite.com' is therefore not allowed access.

So I think that Neil was talking about this when he pointed out that:

the Same-origin Policy only applies to reading data and not writing it.

However, with the origin header explicit control that I proposed to Bergi I think is enough with respect to this issue.

With respect to my answer to Neil I didn't mean that that answer was the one to all my question but it remembered me another important issue about SOP and it was that the policy only applies to XMLHTTPRequest's.

In conclusion, I think that the equation

• TLS + JWT in secure httpOnly cookie + Origin Header check + No XSS vulnerabilities.

is a good alternative if the API is in another domain like SilverlightFox says. If the client is in the same domain that the client I will have troubles with requests that doesn't include the Origin header. Again from the cors tutorial:

The presence of the Origin header does not necessarily mean that the request is a cross-origin request. While all cross-origin requests will contain an Origin header, some same-origin requests might have one as well. For example, Firefox doesn't include an Origin header on same-origin requests. But Chrome and Safari include an Origin header on same-origin POST/PUT/DELETE requests (same-origin GET requests will not have an Origin header).

Silverlight pointed this out to.

The only risk that remains is that a client can spoof the origin header to match the allowed origin, so the answer i was looking for was actually this

UPDATE: for those who watch this post, I have doubts about if the origin header is needed at all using JWT.

The equation would be:

• TLS + JWT stored in secure cookie + JWT in request header + No XSS vulnerabilities.

Also, the previous equation has httpOnly cookie but this won't work if you got the client and the server in different domains (like many SPA application today) because the cookie wouldn't be sent with each request to the server. So you need access the JWT token stored in the cookie and send it in a header.