<script> without crossorigin attribute can leak cross-origin data through exceptions

RESOLVED INVALID

Status

()

Core
DOM
RESOLVED INVALID
2 years ago
2 years ago

People

(Reporter: annevk, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4211

<script src> will fetch the script with credentials. If the response has Access-Control-Allow-Origin: * specified, we will give credentialed cross-origin exception data. This violates the CORS protocol and therefore the same-origin policy.

We should only allow CORS-like things through <script src crossorigin> as that will actually use the CORS protocol properly.

Found by Simon Pieters. Discussed publicly on the #whatwg IRC channel. Seems to also affect other browsers.

Comment 1

2 years ago
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4210 is the same but without Access-Control-Allow-Origin, showing that the .stack does not include stuff from the cross-origin script in that case.
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4210 is the same
> but without Access-Control-Allow-Origin, showing that the .stack does not
> include stuff from the cross-origin script in that case.

So first of all, the exception being thrown here is not an actual browser exception, it's an AssertionError defined in testharness.js.  And its .stack is set to whatever testharness.js sets it to.

Now the processing in AssertionError.prototype.get_stack in http://w3c-test.org/resources/testharness.js strips out stuff that matches the regexp given by:

  (get_script_url() || "\\btestharness.js") + ":\\d+:\\d+"

In this case get_script_url() returns the the .src of the <script> element that linked to testharness.js.  But the .src in the "failing" case includes '(' and ')' and '*' which are special characters in regexps.  So things go off the rails when attempting to match this string, as a regexp, against the actual stack, and stuff that testharness is _trying_ to strip out doesn't get stripped out.

In other words, the browser behavior here totally does not depend on the Access-Control-Allow-Origin header.  You can see this clearly at http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4215 which is certainly not sending any such header but shows the full stack.

It's a known issue that runtime errors from scripts can leak stack information, as well as information about what functions are defined in the file, etc.  Of course the information about what functions are defined is leaked by merely executing the script.  And information about what the script is doing can generally be exfiltrated by just hooking the various JS standard objects (for example, you can catch pretty much everything other than array and object literal creation that way).

So given that the premise for this bug report (that "Access-Control-Allow-Origin: *" affects things in some way here) is false, is there an actual issue?  ;)
(Reporter)

Comment 3

2 years ago
Ugh, sorry for the poor debugging. We deduced from the two examples that the stack was limited to same-origin information normally.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
We should probably fix testharness to regexp-escape the get_script_url() return value, though....
You need to log in before you can comment on or make changes to this bug.