1514396 - [Mixed Content] Firefox only web platform test failures

Status: NEW

(Core :: DOM: Security, defect, P3)

Description

[David Burns :automatedtester]

The following tests are only failing in Firefox as documented in https://foolip.github.io/ad-hoc-wpt-results-analysis/firefox-lone-failures.html

/mixed-content/classic-data-worker-fetch/http-csp/cross-origin-http/top-level/keep-scheme-redirect/blockable/opt-in-blocks.https.html
/mixed-content/classic-data-worker-fetch/http-csp/cross-origin-http/top-level/no-redirect/blockable/opt-in-blocks.https.html
/mixed-content/classic-data-worker-fetch/http-csp/cross-origin-http/top-level/swap-scheme-redirect/blockable/opt-in-blocks.https.html
/mixed-content/classic-data-worker-fetch/http-csp/same-host-http/top-level/keep-scheme-redirect/blockable/opt-in-blocks.https.html
/mixed-content/classic-data-worker-fetch/http-csp/same-host-http/top-level/no-redirect/blockable/opt-in-blocks.https.html
/mixed-content/classic-data-worker-fetch/http-csp/same-host-http/top-level/swap-scheme-redirect/blockable/opt-in-blocks.https.html
/mixed-content/classic-data-worker-fetch/meta-csp/cross-origin-http/top-level/no-redirect/blockable/opt-in-blocks.https.html
/mixed-content/classic-data-worker-fetch/meta-csp/same-host-http/top-level/no-redirect/blockable/opt-in-blocks.https.html
/mixed-content/classic-data-worker-fetch/no-opt-in/cross-origin-http/top-level/keep-scheme-redirect/blockable/no-opt-in-blocks.https.html
/mixed-content/classic-data-worker-fetch/no-opt-in/cross-origin-http/top-level/no-redirect/blockable/no-opt-in-blocks.https.html
/mixed-content/classic-data-worker-fetch/no-opt-in/cross-origin-http/top-level/swap-scheme-redirect/blockable/no-opt-in-blocks.https.html
/mixed-content/classic-data-worker-fetch/no-opt-in/same-host-http/top-level/keep-scheme-redirect/blockable/no-opt-in-blocks.https.html
/mixed-content/classic-data-worker-fetch/no-opt-in/same-host-http/top-level/no-redirect/blockable/no-opt-in-blocks.https.html
/mixed-content/classic-data-worker-fetch/no-opt-in/same-host-http/top-level/swap-scheme-redirect/blockable/no-opt-in-blocks.https.html

Comment 1

[Jonathan Kingston [:jkt] he/him]

Looking into this.

Comment 2

[Jonathan Kingston [:jkt] he/him]

Attachment: Bug 1514396 - Only pass the mixedContentBlocker codebase principals for aRequestingLocation.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9fedba33cfa3
Only pass the mixedContentBlocker codebase principals for aRequestingLocation. r=ckerschb

Comment 4

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/9fedba33cfa3

Comment 5

[Eliza Balazs [:ebalazs_]]

Backed out changeset 9fedba33cfa3 (Bug 1514396) for causing regression Bug 1521239, requested by jkt. CLOSED TREE

Backout push: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cusercancel%2Crunnable&revision=2885dbea4efe7f400bef8f594c0798e8aab6bd01

Comment 6

[Jonathan Kingston [:jkt] he/him]

Passing this back to you :ckerschb sorry.

Comment 7

[Christoph Kerschbaumer [:ckerschb]]

I'll take a look - thanks.

Comment 8

[Jens Hausdorf :jens1o [ni? me]]

In the last week, I looked more closely into the bug (with some help by Frederik)

What We Already Know:

1. The mixed-content/gen/worker-classic-data.http-rp/opt-in/fetch.https.html Web Platform Tests work like this:

• The test suite is loaded as an HTML document (https origin)
• All these test cases start from a worker web worker (security context: worker) with a data URL.
• Test cases make a variety of outbound requests to various combinations of same or swapped schemes (including redirect chains that end up keeping/swapping the chain or intermingling non-HTTPS schemes).
• Every test that involves an non-HTTPS scheme should be blocked.
• Looking at all test cases and results systematically, we conclude this is not happening.
• Because the worker is loaded from a data URI, all requests have a NullPrincipal as loadingPrincipal. The mixed content blocker exits early, as the principal’s scheme is not HTTPS.
• The NullPrincipal and the LoadInfo object do not easily allow us to reach through to the originating document, where we could check for HTTPS instead.
• Main reason for bug: Currently the request is allowed as the request comes from a data-URI and is targeting an http endpoint -> “Request will be allowed because the requesting location is not using HTTPS”

2. Using the MCBLog lazylogger implemented (but not checked-in) from bug 1514396, the checks look like this:

shouldLoad:
  - contentLocation: http://web-platform.test:8000/common/security-features/subresource/xhr.py?action=purge&key=337898c6-17f6-4347-8773-0869ab491537&path=%2Fmixed-content
  - internalContentPolicyType: TYPE_FETCH
  - loadingPrincipal: moz-nullprincipal:{e33afc21-948e-47c2-a4db-6c9e529b2008}
  - triggeringPrincipal: moz-nullprincipal:{e33afc21-948e-47c2-a4db-6c9e529b2008}
  - URISafeToBeLoadedInSecureContext:
    - schemeLocal: 0
    - schemeNoReturnData: 0
    - schemeInherits: 0
    - schemeSecure: 0
  -> decision: Request will be allowed because the requesting location is not using HTTPS.