1896700 - Detect Content Script of Cross-Origin Using Script Load Error

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[Shaheen Fazim]

Attachment: poc.html

On Firefox browser, a site can still detect content across cross-origin, whether it is application/javascript, by using script load errors. This is done by loading the content as a script tag and listening for a script load error. If the script fails to load, we can detect this; if not, we can use this to differentiate between the two types.

Steps to Reproduce:

1. Download the file poc.html.
2. Open poc.html in a Firefox browser, then copy and paste https://www.google-analytics.com/analytics.js into the input field and click "check" to see if it is detected. Repeat with just https://www.google-analytics.com to see not detected.

Comment 1

[:Gijs (he/him)]

I can also reproduce in Chrome. Did you file with them as well? If so can you link the ticket?

Comment 2

[Shaheen Fazim]

(In reply to :Gijs (he/him) from comment #1)

I can also reproduce in Chrome. Did you file with them as well? If so can you link the ticket?

Yes, just now: https://issues.chromium.org/issues/340398749

Comment 3

[Shaheen Fazim]

Attachment: demo.mp4

Comment 4

[:Gijs (he/him)]

So AIUI the alleged vulnerability here is that the attacker can determine whether or not the script exists for a given URL, which may be interesting if it's an oracle for user signed-in-ness or other server-side x-origin state - right?

I'm not an expert on this type of issue, but from a quick look, based on bug 1368921 and bug 1274200 it's not clear to me that this is unexpected, though that is about the content of the script being revealed in some way. As bz points out, a script is not normally safe from being manipulated or the innards of its execution being discovered, if it's loaded in the same window context as other (attacker-controlled) scripts: the attacker can "just" manipulate object prototypes etc. so that execution of the target script does something different. There is no way for the browser to prevent this without changing the way script contexts interact with web pages, which would break... most of the web, at this point.

Put differently:

• not firing either a load or error event for x-origin scripts is likely not web-compatible
• always firing a load event even if the script load fails would likely be detectable via a timing oracle
• even if those problems didn't exist, and the events were completely undetectable, an attacker could use prototype manipulation or other techniques to work out whether the script executed or not (this assumes some knowledge of the content of the script, which seems plausible for the case where an attacker would be interested in this)

Comment 5

[Daniel Veditz [:dveditz]]

The current HTML spec requires onload and onerror on all elements
https://html.spec.whatwg.org/#event-handlers-on-elements,-document-objects,-and-window-objects:event-handlers-3

This is a natural outcome of that fact and I don't think we should change it without consensus amongst the browser vendors

Comment 6

[Simon Pieters [:zcorpan]]

The load and error events expose a bit of information. This is true for most kinds of subresources that allow no-cors fetching. Changing only script wouldn't plug the hole generally (e.g. you can detect changes to image dimensions, font loads, CSS loads, video loads, etc.). Many scripts will also leave a detectable trail (e.g. adding a property to the global), or the script load could likely be detected through a timing attack. Plugging the hole generally would probably amount to disallowing no-cors cross-origin fetches, which is not web compatible.

Comment 7

[Daniel Veditz [:dveditz]]

Olli: do you agree?

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Don't we end up doing the following
https://html.spec.whatwg.org/#execute-the-script-element
"If el's result is null, then fire an event named error at el, and return."

and I'd expect the web to very much rely on that

Comment 9

[Andrew Sutherland [:asuth] (he/him)]

It's worth calling out that an importance difference between bug 1886108 and this bug is that in bug 1886108 the issue was that we were exposing extra entropy on NetworkError by way of the message string varying (and with the default case in particular literally exposing the underlying load result, modulo some explicitly handled error identifiers).

Comment 10

[Daniel Veditz [:dveditz]]

This should be raise as an issue in the spec if you want it to change. Perhaps one option would be to require CORS to get the events, but that's going to break lots of sites.