1493106 - CSP host-source implementation mistakes

Status: REOPENED

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

Description

[Jarek Porzucek]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180830143136

Steps to reproduce:

I've created simple html files with the following content:

File #2
<meta http-equiv="Content-Security-Policy" content="script-src 'unsafe-inline' http://example.com;">
<script src="http://example.com:443"></script>
<script src="https://example.com:80"></script>

File #2
<meta http-equiv="Content-Security-Policy" content="script-src 'unsafe-inline' http://example.com:443;">
<script src="https://example.com"></script>


Actual results:

In both cases sources within script tags have been allowed.


Expected results:

According to CSP Level 2 (3 as well) sources within script tags should be blocked as "https://example.com" is not an equivalent of "http://example.com:443". Also "http://example.com" is not equal (in terms of CSP) to either "http://example.com:443" nor "https://example.com:80".

Comment 1

[Jonathan Kingston [:jkt] he/him]

The CSP specification permits this by allowiing upgrading of mixed content without being blocked by CSP  (https://www.w3.org/TR/CSP/#changes-from-level-2).

> The URL matching algorithm now treats insecure schemes and ports as matching their secure variants. That is, the source expression http://example.com:80 will match both http://example.com:80 and https://example.com:443.

Is this not what you are seeing in other browsers?

Comment 2

[Jarek Porzucek]

(In reply to Jonathan Kingston [:jkt] from comment #1)
> The CSP specification permits this by allowiing upgrading of mixed content
> without being blocked by CSP 
> (https://www.w3.org/TR/CSP/#changes-from-level-2).
> 
> > The URL matching algorithm now treats insecure schemes and ports as matching their secure variants. That is, the source expression http://example.com:80 will match both http://example.com:80 and https://example.com:443.
> 
> Is this not what you are seeing in other browsers?

Yeah, I agree with you but http://example.com:80 matching https://example.com:443 is quite different than http://example.com:80 matching http://example.com:443 (pleae notice no "s" in protocol - the connection is not secure).

Chrome dev team seems to understand that and both sources from my scripts are blocked there by CSP policy.

Comment 3

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Jarek Porzucek from comment #2)
> Yeah, I agree with you but http://example.com:80 matching
> https://example.com:443 is quite different than http://example.com:80
> matching http://example.com:443 (pleae notice no "s" in protocol - the
> connection is not secure).

Indeed - it seems there is a discrepancy in our implementation. The problem is that we perform separate checks for scheme [1] and port [2] both allowing the secure equivalent; http allowing https and :80 allowing :443 but do not check both at the same time. I guess we can fix that though.

Reopening and putting in the backlog for now.

[1] https://searchfox.org/mozilla-central/source/dom/security/nsCSPUtils.cpp#405-408
[2] https://searchfox.org/mozilla-central/source/dom/security/nsCSPUtils.cpp#628-635

Comment 4

[Jarek Porzucek]

Just checked both CSP Level 2 and 3 again and it seems I was wrong and the below case should be allowed:

<meta http-equiv="Content-Security-Policy" content="script-src 'unsafe-inline' http://example.com:443;">
<script src="https://example.com"></script>