17

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.

Suraj Jain
  • 103
  • 4
user1217974
  • 179
  • 1
  • 1
  • 3
  • 'Same Origin Policy (SOP) preserves the data of other domains and therefore nulls out the use of CSRF.' Same Origin Policy only prevent that data recieved by making request to other domain is not accesible to javascript, suppose there is some website mygov.com, and it lets you vote if you are login, and send some request mygov.com/?vote=1, now if another website has this link embedded then inspite of SOP, the vote will be registered. As the request will modify server state and no need to see the data given back. I hope I am clear. – Suraj Jain May 03 '18 at 18:26
  • Same Origin Policy only applies to XMLHTTPRequest **This is incorrect.** – Suraj Jain May 06 '18 at 10:11

4 Answers4

38

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.

logi-kal
  • 132
  • 6
Shurmajee
  • 7,335
  • 5
  • 28
  • 59
  • How are they exception, SOP only prevent script running under one origin to read data from other origin, if you use img tag and src set to different origin, you won't be able to read image data, though it is rendered to user. So why are you calling it exception it is usual behaviour. – Suraj Jain May 03 '18 at 18:30
  • You have made a contradictory statement, How is the image getting rendered if the script sitting in the requesting domain is not able to read it? – Shurmajee May 04 '18 at 06:09
  • 1
    Image gets rendered and displayed to user, but javascript in script tag won't be able to access it. – Suraj Jain May 04 '18 at 06:27
  • See this https://stackoverflow.com/a/35553666/5473170 – Suraj Jain May 04 '18 at 06:35
  • Thanks for the link, I get what you are pointing at. I still feel it is okay to to call img and script tags as exceptions after one gives an explanation for SOP. This is similar to the answer you pointed me to where the OP has to mention this after explaining SOP. I feel my answer is worded correctly to say that they get embeded in the requesting page. – Shurmajee May 04 '18 at 09:08
  • 2
    Actually exception would be gravely incorrect term, what is definion of SOP 'The same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin. It is a critical security mechanism for isolating potentially malicious documents.', now the other answer mentions images and script tag because often people get confused with these in relation to SOP, I think you should remove exception it is not phrased correctly, and would at best confuse the reader. The definition of SOP as I have given above, explains all clearly. – Suraj Jain May 04 '18 at 09:27
  • 1
    Embedding of resources in not an exception to start with, SOP was never meant to block them so they are not exception. – Suraj Jain May 04 '18 at 09:27
10

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. Whether you use an 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 cleverly 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 let you send cross origin POST requests.

Utku
  • 726
  • 1
  • 7
  • 13
Anders
  • 65,052
  • 24
  • 180
  • 218
4

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.

Community
  • 1
Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
0

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

schroeder
  • 125,553
  • 55
  • 289
  • 326
aDoN
  • 283
  • 1
  • 3
  • 10
  • Careful: there are `Content-Type` values other than the three you listed that won't trigger a preflight. Overlooking this subtlety can have important security ramifications; here's just [one example](https://jub0bs.com/posts/2022-02-08-cve-2022-21703-writeup/#bypassing-content-type-validation-and-avoiding-cors-preflight). – jub0bs Apr 02 '22 at 10:10