JS fetch() information leak

RESOLVED INVALID

Status

()

RESOLVED INVALID
a year ago
a year ago

People

(Reporter: radekg, Unassigned)

Tracking

52 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

190 bytes, text/html
Details
83 bytes, application/x-javascript
Details
(Reporter)

Description

a year ago
Created attachment 8857463 [details]
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).
(Reporter)

Comment 1

a year ago
Created attachment 8857465 [details]
testdom-xss.js

Comment 2

a year ago
(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.
Flags: needinfo?(radekg)
(Reporter)

Comment 3

a year ago
> 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.
Flags: needinfo?(radekg)

Comment 4

a year ago
(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)
Group: firefox-core-security

Updated

a year ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.