CODEWITHSUNDEEP
javascriptsame-origin-policy
Johnny
Johnny

Reputation: 7351

Same origin policy - still not getting it

At first I though the same origin policy meant that JS loaded from a different domain couldn't be executed on a page. But after reading this, this and this I became confused. The claim is that if you load JS in a script tag's src property the loaded script has the same origin as the loading page, which means everything coming from a CDN or third party (Google anaytics etc.) now has complete access to the DOM etc. To me that looks like a horrifying security vulnerability. It means if a CDN or similar is ever breached an attacker could serve up malicious JS which could, for example, steal usernames/passwords from multiple sites. So did I understand this correctly or not?

Upvotes: 1

Views: 553

Answers (4)

Tom
Tom

Reputation: 4292

I've made my comment an answer so I can quote the reference for completeness

You understand CORS/SOP correctly, but not its use.

CORS & SOP aren't meant to protect against XSS attacks - they're designed to allow hosts to protect who access their data.

Please see the following, taken from https://security.stackexchange.com/questions/108835/how-does-cors-prevent-xss

TL;DR: How does CORS prevent XSS? It does not. It is not meant to do so.

CORS is intended to allow resource hosts (any service that makes its data available via HTTP) to restrict which websites may access that data.

Example: You are hosting a website that shows traffic data and you are using AJAX requests on your website. If SOP and CORS were not there, any other website could show your traffic data by simply AJAXing to your endpoints; anyone could easily "steal" your data and thus your users and your money.

In some cases that sharing of data (Cross Origin Resource Sharing) is intended, e.g. when displaying likes and stuff from the Facebook API on your webpage. Simply removing SOP to accomplish that is a bad idea because of the reasons explained in the above paragraph. So CORS was introduced.

CORS is unrelated to XSS because any attacker who can place an evil piece of JavaScript into a website can also set up a server that sends correct CORS headers. CORS cannot prevent malicious JavaScript from sending session ids and permlogin cookies back to the attacker.

Upvotes: -1

Quentin
Quentin

Reputation: 944196

The claim is that if you load JS in a script tag's src property the loaded script has the same origin as the loading page,

Yes. The origin is defined by where the HTML document comes from, not anything else.

which means everything coming from a CDN or third party (Google anaytics etc.) now has complete access to the DOM etc.

Yes. This is why you must completely trust the source of any JS you allow to execute on your pages.

To me that looks like a horrifying security vulnerability. It means if a CDN or similar is ever breached an attacker could serve up malicious JS which could, for example, steal usernames/passwords from multiple sites.

That is a risk. It has happened in the past.

If you choose to use a CDN then you must trust them to be sufficiently good at security that that will not happen.

As for what the Same Origin Policy actually does: See this answer.

Upvotes: 4

Bergi
Bergi

Reputation: 665286

You did understand this correctly. Loading scripts from third parties is a horrifying security risk, and there have been multiple occasions where ad networks or analytics providers were used to deliver malicious content on otherwise unbreached websites.

And no, the same-origin-policy is not there to prevent this scenario. It is meant to protect confidential data served to users from being accessed through XHR (and other techniques) on arbitrary other domains.

Upvotes: 1

Joe Clay
Joe Clay

Reputation: 35837

This is definitely a risk that you take when using CDNs - for that reason, browsers are now starting to implement Subresource Integrity (SRI), which allows you to place a checksum on a script/link tag - the Bootstrap docs provide an example of this:

<link rel="stylesheet" 
    href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" 
    integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" 
    crossorigin="anonymous">

If the hash doesn't match that of the actual file that gets loaded, then the resource is blocked. This obviously only protects user that are using browsers that support SRI, however.

Upvotes: 1

Related Questions