1355794 - JS fetch() information leak

Status: RESOLVED INVALID

(Firefox :: Untriaged, defect)

Description

[radekg]

Attachment: xsstest.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170323105023

Steps to reproduce:

Created 3 files in 3 domains different:
http://testdom4.local/~radekg/xsstest.html
http://testdom5.local/~radekg/testdom-xss.js
http://testdom6.local/~radekg/test ("evil page" - empty page)
First file contains input field with a secret value. Second file contains script which read secret value and tries to pass it to evil page. The third file is empty. Opened first URL in browser.


Actual results:

According to default same-origin policy, the script is unable to read resource (and error is logged in JS console), but browser makes HTTP request (with secret data embedded in URL). The URL which is stored in testdom6.local access log contains secret data retrieved from page:
192.168.1.2 - - [12/Apr/2017:14:35:53 +0200] "GET /~radekg/test?secret HTTP/1.1" 200 - "http://testdom4.local/~radekg/xsstest.html" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0"




Expected results:

fetch() should not make request to resources blocked by SOP (/~radekg/test?secret).

Comment 1

[radekg]

Attachment: testdom-xss.js

Comment 2

[:Gijs (he/him)]

(In reply to radekg from comment #0)
> fetch() should not make request to resources blocked by SOP
> (/~radekg/test?secret).

But the requests would be allowed if the testdom6 server had the appropriate Allow-Cross-Origin header, and the only way to determine if that is the case would be to make the request, right?

In other words, I believe this behaviour (request being made, but the page not having access to the contents) is expected. The danger of making unauthorized non-GET requests is remediated by restrictions on POST and mimetypes and so forth (so in some cases we'd send an OPTIONS request rather than immediately sending a POST request). See https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS for more info.

Comment 3

[radekg]

> In other words, I believe this behaviour (request being made, but the page
> not having access to the contents) is expected.

So basically a script can make any "simple request" to any network resource, but browser does not allow it to read results (and tears connection when know that CORS does not permit such access)?
It would be nice to add appropriate note in SOP documentation.

Comment 4

[:Gijs (he/him)]

(In reply to radekg from comment #3)
> > In other words, I believe this behaviour (request being made, but the page
> > not having access to the contents) is expected.
> 
> So basically a script can make any "simple request" to any network resource,
> but browser does not allow it to read results (and tears connection when
> know that CORS does not permit such access)?
> It would be nice to add appropriate note in SOP documentation.

Which SOP documentation? The Same-origin policy page on MDN ( https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Cross-origin_network_access ) has a section that lists multiple ways webpages can connect to non-same-origin resources that do not allow cross-origin read access, but do make the request.

(Unhiding this bug)