How does CSRF correlate with Same Origin Policy

Question

I'm trying to understand what roles do CSRF and same origin play in the grand scheme of things. With CSRF, I'm able to pretty much do anything on other websites on clients by making requests.Same Origin Policy (SOP) preserves the data of other domains and therefore nulls out the use of CSRF.

Now considering the Same Origin Policy only applies to XMLHTTPRequest, so with a cleverly crafted form, I can do a POST request witch voids the SOP and hence the need for CSRF tokens.

Now with all of this, does the CSRF kind of work around the SOP or works through it?I'm finding it hard to answer, but maybe that's because the question itself is confusing.

Answer 1

Let us start by defining the term "origin". The origin of a page is decided by three unique factors: hostname, protocol and port number. For example, http://test.com and https://test.com have different origins as the protocol is different. Similarly http://one.test.com and http://two.test.com have different origins as the hostnames are different. The origin property is also different for two services running on the same host with different port numbers e.g. http://test.com:8081 and http://test.com:8082 are considered to be different origins.

Same Origin Policy (SOP) is a browser-level security control which dictates how a document or script served by one origin can interact with a resource from some other origin. Basically, it prevents scripts running under one origin to read data from another origin.

Cross-domain requests and form submissions are still permitted but reading data from another origin is not permitted. This means that if you are performing a CSRF attack on a vulnerable site which results in some server side state change (e.g. user creation, document deletion etc), the attack will be successful but you would not be able to read the response.

In short SOP only prevents reading data which was served from a different origin. It does not cover cross-domain form submissions which are used to carry out a CSRF attack.

As far as performing cross-domain communication using AJAX is concerned, there are a few other security controls which dictate the communication. Refer to Cross Origin Resource Sharing. CORS allows different origins to communicate and share data in a controlled way and a CORS misconfiguration may also result in security vulnerabilities.

Note that SOP does not prevent resources hosted on different domains to be embedded in a page by using script tags, CSS and image tags. While this might not allow a direct reading of the contents, side effects of the loading and rendering can be used to determine (parts of) the content. Note also that Websockets are not covered by SOP at all and thus cross-site reading is possible.

P.S. Taken from my blog.

Answer 2

Same Origin Policy (SOP) preserves the data of other domains...

There are two parts to the SOP:

1. It prevents scripts on origin A from reading data from origin B.
2. It prevents sites on origin A from sending anything but so called "simple" requests to origin B. Simple requests are limited to GET and POST, and only a few headers can be modified.

...and therefore nulls out the use of CSRF.

The SOP does not protect against CSRF. Why?

1. A CSRF attack is done by sending a request, and not by reading anything from the response. In fact, you neither can nor need to read the response.
2. You would normally use simple requests in a CSRF attack.

As you can see, the limitations mentioned above that the SOP puts in place does not prevent CSRF attacks.

Now considering the Same Origin Policy only applies to XMLHTTPRequest...

No, it does not. It applies to all data a browser handles. If you use XMLHTTPRequest, an ordinary form, or the fetch API is irrelevant. The same restrictions apply.

...so with a cleverly crafted form, I can do a POST request witch voids the SOP and hence the need for CSRF tokens.

With a clever crafted form you can make a POST request that executes a CSRF attack, yes. And that is why you need special protection, such as CSRF tokens.

Now with all of this, does the CSRF kind of work around the SOP or works through it?

I'm not sure what "working around" or "working through" the SOP would mean. Instead, let me say this: CSRF is possible because browsers lets you send cross origin POST requests.

Answer 3

A site A can cause a request to the different site B in various ways, for example with including an image from site B inside the HTML from site A (i.e. <img src=http://B/...>) or do similar things with forms or Javascript or HTTP redirects. Requests which are initiated from one site but are directed to another site are called cross-site requests.

Cross-Site Request Forgery (CSRF) means that a cross-site request can be misused. This is typically the case because an existing session cookie from a previous connection to site B is sent to each request on this site, even if the request is initiated from site A, i.e. cross-site. This means that the request is executed with the identity of the user logged into side B. A successful CSRF attack means that such a cross-site request can cause harm, for example by changing the DNS settings in a router vulnerable to CSRF.

Same-Origin Policy (SOP) does not make CSRF impossible but it somehow limits the impact of CSRF in that the request gets send to site B but the result returned by the server of site B can not be seen by the attacker. Thus SOP makes CSRF write-only, i.e. CSRF can be used to execute unwanted actions but it cannot be used by itself to exfiltrate data from site B. For example an external attacker might use a CSRF vulnerability in a internal company Wiki to create a new posting in the name of an existing user or delete a posting, but due to SOP he cannot read the content of the internal Wiki and send it back to the external attacker.

Note that not all cross-site communication is restricted by the SOP. Notably Websockets are not restricted and thus it is for possible for an attacker at site A to use a browser as a trampolin to fully communicate with a Websocket at site B with the permissions of the logged in user, i.e. both write and read data.

Answer 4

Yes it was to do with CSRF, because, I would say that:

Same-Site Origin only allows you to perform simple requests

So, for example, if you want to exploit a CSRF you must use GET, POST or HEAD and the Content-Type must be:

• application/x-www-form-urlencoded
• multipart/form-data
• text/plain

The rest of the requests trigger the CORS Preflight.

Now, let's go to the core of the question, how can you use these concepts to exploit more vulnerabilities:

"CORS is a controlled relaxation of the same-origin policy, so poorly configured CORS may actually increase the possibility of CSRF attacks or exacerbate their impact."

-> https://portswigger.net/web-security/cors/access-control-allow-origin

So, if the CORS policy accepts Custom Headers, or the Content-Type, you can exploit CSRF with Content-Type:application/json, for example, or, with a Custom Header