Open
Bug 1493106
Opened 6 years ago
Updated 2 years ago
CSP host-source implementation mistakes
Categories
(Core :: DOM: Security, defect, P3)
Tracking
()
REOPENED
People
(Reporter: jarporz, Unassigned)
Details
(Whiteboard: [domsecurity-backlog1])
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".
Updated•6 years ago
|
Component: Untriaged → DOM: Security
Product: Firefox → Core
Comment 1•6 years ago
|
||
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?
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 2•6 years ago
|
||
(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•6 years ago
|
||
(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
Status: RESOLVED → REOPENED
Ever confirmed: true
Priority: -- → P3
Resolution: INVALID → ---
Whiteboard: [domsecurity-backlog1]
Reporter | ||
Comment 4•6 years ago
|
||
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>
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•