1440370 - No CORS preflight request to http://127.0.0.1 from secure context

Status: RESOLVED DUPLICATE of bug 1376310

(Core :: DOM: Security, defect)

Description

[Ben]

Attachment: nginx location block with access-control-allow-* headers set

Firefox does not send a preflight request from a secure context to http://127.0.0.1 when required - presumably blocking the request due to "mixed content". It has been agreed that 127.0.0.0/8 and ::1/128 should be considered "potentially trustworthy"[1], and therefore no mixed content blocking should apply from a secure context (as is currently the case for GET requests to http://127.0.0.1 from secure contexts). Blocking the preflight request results in requests requiring preflight requests (e.g. PATCH, PUT) failing with error code 0, even when they should succeed.

Steps to reproduce:
 - Start a web server on your local machine listening for HTTP and HTTPS (with a self-signed certificate) requests, with suitable Access-Control-Allow-* headers configured for OPTIONS, PATCH, and (optionally) GET requests. A suitable location block for nginx has been attached to this bug.
 - Visit https://127.0.0.1/ and add a security exception to trust the self-signed certificate.
 - Run the below JavaScript in the console on a page with a secure context (e.g. https://yamm.io) and an insecure context (e.g. http://trains.im), changing the url variable between "http://127.0.0.1" and "https://127.0.0.1", and watching the web server access log. You will observe that no preflight OPTIONS request is sent when sending a PATCH request to http://127.0.0.1 from a secure context (and the request therefore fails), and in other cases Firefox behaves as expected. Note that Content Security Policies may prevent any requests to 127.0.0.1 from working properly, but the example websites are known to have suitable CSPs.

var url = 'https://127.0.0.1';
var method = "PATCH";
var xhr = new XMLHttpRequest();
xhr.open(method, url, true);
xhr.onload = console.log("Patch success");
xhr.onerror = console.log("Patch error");
xhr.send();

This bug was tested on Ubuntu 16.04, using both Firefox 58 and Firefox Nightly (60). This bug is not present in Chrome 64.

[1] - see https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy, https://bugzilla.mozilla.org/show_bug.cgi?id=903966, https://chromium.googlesource.com/chromium/src.git/+/130ee686fa00b617bfc001ceb3bb49782da2cb4e, https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/11963735/

Comment 1

[Ben]

Attachment: JavaScript to run in console

Comment 2

[Daniel Veditz [:dveditz]]

Tanvi: can you confirm this or know what's likely to be going on? XHR to localhost seems like a common case that led to the need to treat localhost as secure in the first place.

Comment 3

[Ben]

Below are more detailed instructions to reproduce this bug (skip to later steps if a suitable environment is available):

Step 1
Install Ubuntu 16.04.4 server in a virtual machine (don't install any optional packages). Update Ubuntu, rebooting if required.

Step 2
Install desktop prerequisites (sudo apt install xorg xterm gdm menu gksu synaptic --no-install-recommends). Install the desktop (sudo apt-get install gnome-session gnome-panel metacity gnome-terminal --no-install-recommends). Reboot into the desktop.

Step 3
Install wget (sudo apt install wget). Install Chrome (see https://askubuntu.com/a/510186).

Step 4
Download and extract Firefox nightly.

Step 5
Install nginx (sudo apt install nginx). Configure nginx by replacing /etc/nginx/sites-available/default with a suitable configuration file (see attachment below). Reload nginx so the new configuration file takes effect (sudo systemctl reload nginx).

Step 6
Load https://yamm.io (or any other secure context with a suitable content security policy) in Chrome and Firefox. Watch the nginx access log (e.g. less +F /var/log/nginx/access.log). Run the JavaScript in the developer console (see attachment below) in Chrome and Firefox. Note that Chrome correctly sends an OPTIONS request followed by the PATCH request and the request succeeds ("Patch success" is logged to the console), but Firefox fails to send any HTTP requests and the request fails ("Patch error" is logged to the console).

Comment 4

[Ben]

Attachment: nginx configuration file (see comment 3 step 5)

Comment 5

[Ben]

Attachment: javascript to run in console (see comment 3 step 6)

Comment 6

[Tanvi Vyas[:tanvi]]

This is a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1376310.  See also https://bugzilla.mozilla.org/show_bug.cgi?id=903966#c27


Not sure where in the code this has to be fixed.  In bug 903966 we updated nsMixedContentBlocker:
https://dxr.mozilla.org/mozilla-central/source/dom/security/nsMixedContentBlocker.cpp#393
https://dxr.mozilla.org/mozilla-central/source/dom/security/nsMixedContentBlocker.cpp#744

Shouldn't CORS preflights go through the same logic?  Anyway, marking as duplicate and will ping Biru on duplicate bug to see if it is on his roadmap.

Comment 7

[Amit Shani]

What's up with this?
I have a single page application which communicates with a local application on my computer
Works like a charm in Chrome, Edge and Safari
On Firefox I get this error message:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://127.0.0.1:44512/?token=fake-token-1234. (Reason: CORS request did not succeed)
The SPA is served over HTTPS and the local app is serving an HTTP server