Closed Bug 1274200 Opened 8 years ago Closed 8 years ago

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

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: annevk, Unassigned)

Details

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.
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?  ;)
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
Closed: 8 years ago
Resolution: --- → INVALID
We should probably fix testharness to regexp-escape the get_script_url() return value, though....
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.