Clarify/test which quote characters may be used

[foolip]

This issue is similar to #5, but for quote characters rather than whitespace.

In https://bugzilla.mozilla.org/show_bug.cgi?id=1629699 a site was broken in Firefox, and it appeared to be because an odd quote character was used, U+0091 PRIVATE USE ONE. I'm not familiar with this Unicode character, it's mentioned in https://en.wikipedia.org/wiki/Private_Use_Areas#Private-use_characters_in_other_character_sets and seems to be a control character and not private use despite its name.

I have no idea how it came about, but https://html.spec.whatwg.org/multipage/parsing.html#numeric-character-reference-end-state maps the ‘ character reference to U+2018 LEFT SINGLE QUOTATION MARK, so there is a connection to quotation marks.

I haven't checked what happens the 0x91 byte appears in a CSP header.

Tests for this in WPT and a spec update to clarify if necessary would be great.

[annevk]

https://bugzilla.mozilla.org/show_bug.cgi?id=1629699#c6 is particularly relevant here. It would be really great if someone defined a proper parser for CSP based on Infra Standard primitives and testing existing implementations.

[foolip]

I tried some basic combinations in web-platform-tests/wpt#23561 and have confirmed there are differences, but I don't know quite how to interpret them.

It looks like double quotes do... something... in all browsers. And in Firefox, all the other variants of quotes I tried also do something different than in Chrome and Safari.

However, I don't know if this comes down to how an invalid CSP header is treated, or if these quotes are actually supported.

@mikewest can you help figure out what to test here and whether it's a spec bug or implementation bug at the bottom of the apparent interop issue?

[bakkot]

My understanding is that the spec says those are not valid, because they contain characters which are not ASCII code points, which means a string containing them is not a serialized CSP. Unfortunately, the spec does not say what to do with malformed CSPs; see #6 and #414.

Last time I tested this, Chrome and Safari rejected any CSP with a non-ASCII character (and consequently failed open, i.e. did not enforce anything), whereas Firefox treated them as non-matching host-sources and still enforced the rest of the policy.

[evilpie]

In Firefox we are continuing to get web compatibility issues because people use an invalid CSP header and Chrome defaults to allow everything and Firefox restricts. @mikewest

https://bugzilla.mozilla.org/show_bug.cgi?id=1764261

[antosart]

According to the spec, keywords like self or none must be included into normal quotes (ASCII 0x27). Backticks (ASCII 0x60) are not allowed. However, since backticks are ASCII, the spec just ignores that particular source expression. As a result, both script-src `none` and script-src `self` should be interpreted as just script-src (which effectively means script-src 'none').

On the other side, if some non-ASCII quotes are included, then the whole directive should be ignored.

I think chrome follows this behaviour. Where is this different from Firefox?

[evilpie]

I think chrome follows this behaviour. Where is this different from Firefox?

I doesn't look like Chrome follows that behavior. The following test case uses "fancy quotes" in script-src: script-src ‘self’. Firefox treats it like script-src 'none', but Chrome just seems to ignore the whole script-src directive instead.

https://jsbin.com/rudaginuva/edit?html,output

[annevk]

@evilpie doesn't that follow from step 2.2 of https://w3c.github.io/webappsec-csp/#abstract-opdef-parse-a-serialized-csp? If the directive contains non-ASCII it's ignored.

This was changed in 49ae457 although it doesn't seem impl bugs were filed necessarily. It would probably be good for WebAppSec to adopt a variant of WHATWG's PR template.

[evilpie]

Firefox now implements this less safe behavior and ignores tokens that contain non-ASCII characters. There are also tests for this including one with fancy quotes. https://hg.mozilla.org/mozilla-central/rev/d68d4fd4534f