CORS header flow

Question

I do not understand something with CORS headers:

Let's suppose i have my website on this domain: http://myverynicesite.com

Let's suppose a hacker managed to inject malicious javascript code on my site.

This malicious javascript is sending data to the hacker's website: http://hackerwebsite.com

There is something i do not understand with CORS headers: The header which allow is set on webservice site. So, the hacker will just have to add this header and it will work:

<?php
header("Access-Control-Allow-Origin: http://myverynicesite.com");
?>

I do not understand why CORS does not work with an inverted flow ? I was thinking that myverynicesite.com should allow hackerwebsite.com with CORS. And i see this is hackerwebsite.com which allows myverynicesite.com.

So i do not understand the value add of CORS.

Thanks

Answer 1

JavaScript runs on your computer, not the server, so if somebody manages to get JavaScript to run that doesn't mean that PHP will be executed on your server.

Plus, CORS is mostly to protect your site from other people's.

Let's say that you have an account with rubbishbank.com, and they put all of your credit card details in a picture. Without CORS, an attacker could just request that image from badsite.com and send it to their server if you visit badsite.com while logged into rubbishbank.com; CORS stops this.

CORS would only fail here if rubbishbank.com is allowing CORS from badlysecuredbankpartner.com (rubbishbank.com needs to have the header you're talking about in your question) and that site gets an XSS attack or something similar; since rubbishbank.com has disabled CORS for badlysecuredbankpartner.com, rubbishbank.com is not protected from it or from any JavaScript running on it.

Answer 2

The Same Origin Policy is designed to stop JavaScript running on Site A from reading data that Site B is willing to share with the owner of the browser.

For example: So that Evil Site cannot use my browser to make an HTTP request to GMail and read my email (which Evil Site could then forward on to Evil Hacker).

CORS is designed to relax that policy so that Site B can grant permission to Site A to access the data.

If an attacker injects JS onto Site B, then the JS will be running on Site B. It doesn't need any special permission to read data from Site B as it is the Same Origin.

The attacker's JS, running on Site B, can then send the data to Site A. It doesn't need special permission to do this because it is sending data, not reading it. Even if it did need permission, Site A would grant it because Site A is the attacker's site.