4 ms·

If a 3rd party's script loaded from the 3rd party domain initiates any execution on its own (without being invoked by script on the 1st party's site), it won't

by asaph 8y ago

If a 3rd party's script loaded from the 3rd party domain initiates any execution on its own (without being invoked by script on the 1st party's site), it won't have permissions to make calls to the 1st party's domain. Moving the 3rd party script to the 1st party domain opens this up. Update: Given the responses, I'm starting to think I might be incorrect on this point. I'll admit, I'm working from memory here. I'll have to go back and validate this.

woogley 8y ago
I have never heard of this. Can you share a link that goes into detail about this behavior? I don't immediately see anything on MDN's same-origin page talking about it
- benmmurphy 8y ago
  I'm 99% sure this is not a thing and if it was it would be incredibly broken and not secure and most non-trivial pages relying on it for security would be vulnerable to the third party script. Anyway. This can easily be proved one way or another. `Here is an example that shows a third party script accessing a first party domain. There is no CORs as far as I can see: https://jsfiddle.net/aopmtn46/ https://jsfiddle.net/aopmtn46/ If you open the console you will see "STATUS 404" which is not possible if same origin on third party scripts is enforced.
  - woogley 8y ago
    thank you for this test!
benmmurphy 8y ago
I very strongly doubt this is part of the browsers same origin model. Basically, this is only secure under the assumption that the third party script can't trick the first party script into invoking it by modifying its state since the third party script and the first party script both share the same global namespace. Lets see how this is broken when jquery is running as a first party script. 1. third party script calls $(document).on("..", function() {}) 2. event executes which causes jquery to invoke a function in the third party script 3. third party script can now make a request to the 1st party origin bypassing the 'sandbox' ok.. so maybe the browser tries to 'secure' against this attack by marking event listeners as either having a 'good' stack or a 'bad' stack. in this case when the third party script does $(document).on() it would be identified as 'bad' stack and couldn't then make the http request because the browser would see <bad stack> at the start of the event chain. but this can still be worked around: 1. third party script calls $(document).on("event", ".selector", function() {}) after 1st party script had already set a listener on document (not an abnormal thing) 2. event happens and now it is run with 'good' stack because jquery uses a shared event handler and the event handler was originally registered with 'good' stack by the first party script. (the bad script doesn't even have to use the 'live' style. i suspect jquery shares event handlers for the same element so they would just need to try to add an event handler to an element that already has a jquery event handler) there can be no security between scripts that share the same global state.
calaveraDeluxe 8y ago
I don't think this is true. I just tried to replicate it with 2 different hostsnames pointing to 127.0.0.1 in my /etc/hosts. js loaded from origin2.foo on a page with an origin of origin1.foo can XHR things from origin1.foo, but not from origin2.foo. Interestingly, MDN leads the article on same-origin policy with this sentence: The same-origin policy is a critical security mechanism that restricts how a document or script loaded from one origin can interact with a resource from another origin. This seems to support the way that OP described how SOP works.

by asaph 8y ago

woogley 8y ago

I have never heard of this. Can you share a link that goes into detail about this behavior? I don't immediately see anything on MDN's same-origin page talking about it

benmmurphy 8y ago
I'm 99% sure this is not a thing and if it was it would be incredibly broken and not secure and most non-trivial pages relying on it for security would be vulnerable to the third party script. Anyway. This can easily be proved one way or another. `Here is an example that shows a third party script accessing a first party domain. There is no CORs as far as I can see: https://jsfiddle.net/aopmtn46/ https://jsfiddle.net/aopmtn46/ If you open the console you will see "STATUS 404" which is not possible if same origin on third party scripts is enforced.
- woogley 8y ago
  thank you for this test!

benmmurphy 8y ago

I very strongly doubt this is part of the browsers same origin model. Basically, this is only secure under the assumption that the third party script can't trick the first party script into invoking it by modifying its state since the third party script and the first party script both share the same global namespace. Lets see how this is broken when jquery is running as a first party script. 1. third party script calls $(document).on("..", function() {}) 2. event executes which causes jquery to invoke a function in the third party script 3. third party script can now make a request to the 1st party origin bypassing the 'sandbox' ok.. so maybe the browser tries to 'secure' against this attack by marking event listeners as either having a 'good' stack or a 'bad' stack. in this case when the third party script does $(document).on() it would be identified as 'bad' stack and couldn't then make the http request because the browser would see <bad stack> at the start of the event chain. but this can still be worked around: 1. third party script calls $(document).on("event", ".selector", function() {}) after 1st party script had already set a listener on document (not an abnormal thing) 2. event happens and now it is run with 'good' stack because jquery uses a shared event handler and the event handler was originally registered with 'good' stack by the first party script. (the bad script doesn't even have to use the 'live' style. i suspect jquery shares event handlers for the same element so they would just need to try to add an event handler to an element that already has a jquery event handler) there can be no security between scripts that share the same global state.

calaveraDeluxe 8y ago

I don't think this is true. I just tried to replicate it with 2 different hostsnames pointing to 127.0.0.1 in my /etc/hosts. js loaded from origin2.foo on a page with an origin of origin1.foo can XHR things from origin1.foo, but not from origin2.foo. Interestingly, MDN leads the article on same-origin policy with this sentence: The same-origin policy is a critical security mechanism that restricts how a document or script loaded from one origin can interact with a resource from another origin. This seems to support the way that OP described how SOP works.