1570722 - Firefox and Chrome differ on how to treat an invalid CSP header (need WPT test) with non ASCII characters

Status: RESOLVED FIXED

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

Description

[Thomas Wisniewski [:twisniewski]]

The CSP header being specified on https://www.taiwanlottery.com.tw/ is invalid:

Content-Security-Policy: default-src ¡¥self¡¦; script-src ¡¥self¡¦

Chrome seems to ignore the header entirely, but Firefox ends up blocking all of the site's requests for its same-server content, revealing an interop issue.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:wleung, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Thomas Wisniewski [:twisniewski]]

This is also affecting an FDA government site: https://www.accessdata.fda.gov/scripts/ora/pcb/index.cfm?action=tutorial.tutorial

They are serving the HTML with: content-security-policy: frame-ancestors ‘self’

Firefox ends up showing just a vague error page instead of the content.

Comment 3

[Christoph Kerschbaumer [:ckerschb]]

Seesm like a CSP issue, moving over to dom:security for the triage meeting.

Comment 4

[Daniel Veditz [:dveditz]]

The spec ought to be clear on this: the bogus non-self token is a hostname and so nothing else matches. Or even if we rejected that token we'd be left with "default-src ;" with no tokens, and that also is interpreted as 'none' (correctly, in our opinion, since it's saying "I want to use default-src, and nothing matches").

Does chrome reject the header for non-ascii/non-UTF8 characters before it gets to CSP?

Comment 5

[Daniel Veditz [:dveditz]]

We are rejecting the hostname (as per spec, it's got invalid characters), and left with an empty directive.

Mike: how is Chrome intepreting "script-src <errorthing> ;" ? Chrome and FIrefox agree <errorthing> is bad, but apparently not what to do about it? We ignore that token and end up with an empty set, == 'none'. Is Chrome throwing out the entire directive or header? Or is an empty set not the same as "nothing to match"?

Comment 6

[Daniel Veditz [:dveditz]]

See in particular https://w3c.github.io/webappsec-csp/#match-url-to-source-list

2. If source list is an empty list, return "Does Not Match".

Clearly we need a CSP WPT test for this case.

Comment 7

[Daniel Veditz [:dveditz]]

Tom: what are the next steps? The DOM Security team thinks we're following the spec and would therefore WONTFIX this bug. Is there somewhere else you'd like to move it to make progress with Chrome on following the spec?

Comment 8

[Thomas Wisniewski [:twisniewski]]

Since one of the known webcompat issues is already in the queue for site outreach, and the other has since been fixed by the site, the next steps are to find or file a crbug on this, and eventually get a WPT in as well. I'm afraid I'm a bit too swamped to get to either at the moment, however.

Comment 9

[Daniel Veditz [:dveditz]]

We think Firefox is correct, so the "good-first-bug" here is for writing a WPT test for this case.

Comment 10

[guestx86]

Hi, can I work on this? This would be my first bug fix on Firefox.

Comment 11

[antoniosartori]

I believe all browsers agree on Content-Security-Policy: frame-ancestors self. This is a valid CSP, where self gets interpreted as hostname, so it allows being embedded only by the host self and nothing else. Although most likely frame-ancestors 'self' was intended instead, there is no way for the browser to know that.

As for non-ASCII characters in the policy (as in the example Content-Security-Policy: default-src ¡¥self¡¦; script-src ¡¥self¡¦), things get more tricky and at least Chrome and Firefox behave differently. There is also some discussion on the CSP spec https://github.com/w3c/webappsec-csp/issues/473. It would be great to align the behaviour, and I would be happy to work on that on the chromium side.

Comment 12

[Anne (:annevk)]

Thanks to Antonio this was clarified in https://github.com/w3c/webappsec-csp/commit/49ae457205d1445dd3d15628dfed49e1824fbe7c. As we've seen some breakage in the past I suggest we adjust our CSP parser accordingly.

Comment 13

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Anne (:annevk) from comment #12)

Thanks to Antonio this was clarified in https://github.com/w3c/webappsec-csp/commit/49ae457205d1445dd3d15628dfed49e1824fbe7c. As we've seen some breakage in the past I suggest we adjust our CSP parser accordingly.

As discussed, we should probably make an effort to fix more of our CSP backlog bugs in a separate effort (including this one).

Comment 16

[Karl Dubost💡 :karlcow]

Putting back with webcompat Priority so we can triage again.

Comment 17

[Karl Dubost💡 :karlcow]

Some sites are unable to display any content when faced with this issue.

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 5 See Also bugs.
:freddy, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 20

[Tom Schuster (MoCo)]

Attachment: Bug 1570722 - CSP: Ignore directives with non-ASCII tokens. r?freddyb

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d68d4fd4534f
CSP: Ignore directives with non-ASCII tokens. r=freddyb

Comment 22

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/37498 for changes under testing/web-platform/tests

Comment 23

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/d68d4fd4534f

Comment 24

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot