Open Bug 1570722 Opened 3 years ago Updated 4 months ago

Firefox and Chrome differ on how to treat an invalid CSP header (need WPT test)

Categories

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

defect

Tracking

()

Webcompat Priority P2

People

(Reporter: twisniewski, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: good-first-bug, Whiteboard: [domsecurity-backlog])

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.

Webcompat Priority: --- → ?

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(wleung)

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.

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

Component: Security → DOM: Security
Flags: needinfo?(wleung)

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?

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"?

Flags: needinfo?(mkwst)

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

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

Clearly we need a CSP WPT test for this case.

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?

Flags: needinfo?(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.

Flags: needinfo?(twisniewski)

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

Keywords: good-first-bug
Priority: -- → P3
Summary: Firefox and Chrome differ on how to treat an invalid CSP header → Firefox and Chrome differ on how to treat an invalid CSP header (need WPT test)
Whiteboard: [domsecurity-backlog]

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

Webcompat Priority: ? → P3

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.

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.

Flags: needinfo?(mkwst) → needinfo?(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).

Flags: needinfo?(ckerschb)
Duplicate of this bug: 1497742
Duplicate of this bug: 1757913

Putting back with webcompat Priority so we can triage again.

Webcompat Priority: P3 → ?
Webcompat Priority: ? → P2

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

You need to log in before you can comment on or make changes to this bug.