1519406 - Mixed content blocker is getting a nullprincipal in an opaque document case

Status: RESOLVED FIXED

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

Description

[Jonathan Kingston [:jkt] he/him]

In Bug 1514396 I noticed that we can't assert that nullprincipal URI isn't ever set for the requestingLocation so a narrower assert was added.

The failing test I found was in testing/web-platform/tests/content-security-policy/inheritance/iframe-all-local-schemes-inherit-self.sub.html when a sandboxed frame / data URI loads an image. The image NodePrincipal is a nullprincipal.

nsMixedContentBlocker::ShouldLoad then sets requestingLocation to be the principal URI which seems an incorrect check rather than using the parent document to check for CSP etc.

I would like to investigate that this is either not a problem or that we should be passing the correct NodePrincipal into the image to be used in mixed content blocking cases. I'm setting this as security sensitive as it's a little concerning that we are bypassing security checks.

Comment 1

[Jonathan Kingston [:jkt] he/him]

I'm going to reprioritise this, even though I am concerned this might be a MCB escape still this is a larger project than expected.

I haven't written a test case but it appears we aren't adhering to the standard. For strict blocking of mixed content we don't appear to be checking the framing element and also the top level document if strict blocking is enabled. The standard also calls for the global settings object of a document to be initialised with the same strict blocking value as it's parent. This wording is irrelevant but it doesn’t appear we behave this way.

Using principals to decide the requestingLocation appears to be broken in that we now use null principals for data: uri loads. This has the impact of making the algorithm return early and permit the load, rather than checking the frame and the top level document.

Comment 2

[Christoph Kerschbaumer [:ckerschb]]

Tracking the precursor URI (work within Bug 1715167) will allow us to fix that, after we have the precuros URI on a NullPrincipal, then we can fix this problem within 1551886. I am not marking it as a duplicate, but I think it is one actually.

Comment 3

[Niklas]

Like Christoph suggested, this was fixed in Bug 1551886.