Is this CSP bypass?

I've put your repro here: https://bayden.com/test/csp/blockmixed.htm

I see the same behavior in Chrome and Firefox 46.0.1; the browser respects the upgrade-insecure-requests directive and converts the HTTP reference to HTTPS. As a consequence, the image loads over HTTPS and there is no mixed content.

In Firefox 49.0.1, the non-secure resource is blocked with a console warning: "Content Security Policy: Blocking insecure request ‘http://googlechrome.github.io/samples/images/touch/chrome-touch-icon-192x192.png’."

If the request was upgraded, I don't see a security issue here. Could anyone from the cc list take a look and remove it from the security queue if you agree?

Per https://www.w3.org/TR/upgrade-insecure-requests/#mix, Chrome's behavior is by-design, and Firefox 49 should have a bug filed against it:

"The upgrade-insecure-requests directive results in requests being rewritten at the top of the Fetching algorithm [FETCH], as specified in §4.1 Upgrade request to a potentially secure URL, if appropriate. It’s important to note that the rewrite happens before either Mixed Content [MIX] or Content Security Policy checks take effect [CSP].

This ordering means that upgraded requests will not be flagged as mixed content. Moreover, it means that upgrade-insecure-requests’s effect takes place before the block-all-mixed-content directive would have a chance to block the request. If the former is set, the latter is effectively a no-op."

So what does this note mean?

This requirement is not met by Mixed Content’s strict mode, which makes something like the opposite assertion.

> It’s important to note that the rewrite happens before either Mixed Content [MIX] or Content Security Policy checks take effect [CSP].

Question:

Why does chrome block iframe?

Thanks Eric. Closing as WontFix based on c#5.

Hopefully someone more familiar with this can chime in on c#6-7.

RE: #6

<<This requirement is not met by Mixed Content’s strict mode, which makes something like the opposite assertion.>>

... means: "Upgrade-insecure-requests means that requests for non-secure resources will succeed (because they have been silently upgraded to HTTPS). In contrast, the block-mixed-content directive has the opposite behavior (resources which are not HTTPS will be blocked)."

Basically, this paragraph is saying: "This specification introduces the upgrade-insecure-requests directive because we want mixed content requests to be UPGRADED and not BLOCKED."

RE: #7: <<Why does chrome block iframe?>>

Chrome is blocking the iframe as mixed content because it is not upgrading it to HTTPS. Chrome currently does not apply the Upgrade-insecure-requests directive to subframes (unlike Firefox); this is probably a bug in Chrome. Clarifying the desired behavior for IFRAMEs in the upgrade-insecure-requests specification is tracked here: https://github.com/w3c/webappsec-upgrade-insecure-requests/issues/4

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot