CORB++: CSS

[annevk]

#721 (comment) has a sketch for the CORB++ idea. Basically, all opaque responses apart from a couple "safelisted responses" are blocked by the networking layer and turned into network errors.

In https://bugzilla.mozilla.org/show_bug.cgi?id=1531405 Mozilla looked at Content-Type headers for opaque responses that might end up being used as style sheets. For Firefox 71 beta, the breakdown is as follows (similar breakdown for other releases so I suspect this is representative enough):

• No header: 0.17%
• Empty header: 0.00% (some samples)
• Failed to parse: 0.00% (some samples)
• text/css: 99.48%
• Other: 0.35%

The main problem I see here is "No header". The platform treats this as text/css and 0.17% seems too high to block. (Note that "Other" is already blocked. Empty/Failed are not blocked currently I think, but could be.) This means that we either have to sniff CSS in addition to JavaScript or give up completely on resources without a Content-Type header. That is, in order to protect against Spectre and memory exploits you need a Content-Type header set on any resource you put online (and ideally you also have X-Content-Type-Options set or CORP obviously as otherwise it still gets sniffed and might end up exposed if it parses as JavaScript).

@bzbarsky @valenting @jakearchibald @anforowicz @youennf thoughts?

[jakearchibald]

The main problem I see here is "No header". The platform treats this as text/css

Huh, is that spec'd? https://html.spec.whatwg.org/multipage/links.html#link-type-stylesheet:process-the-linked-resource suggests the content type must be text/css.

[bzbarsky]

<link> in general is specced ... only so-so. :(

[jakearchibald]

Hah. So what's the actual behaviour here then? Is it:

Cross origin styleheets are blocked if the Content-Type is present and is not text/css. If the Content-Type header is absent, the resource is not blocked.

[bzbarsky]

In Gecko, the behavior is "Blocked if there is a content-type header result of parsing the content-type header produces a nonempty string".

I suspect based on code inspection, but have not tested, that something like:

Content-Type: ; charset="utf-8"

would get treated as "empty string" in Gecko, for example. And not sure about this one:

Content-Type: text/css, ; charset="utf-8"

If we want to know the actual behavior across browsers, we'll need to write some testcases and maybe do some code-sleuthing.

[jakearchibald]

Interesting!

Given the error resilience of CSS, sniffing it sounds hard. Could CSS resources be sanitised out-of-process? As in, ditch everything that doesn't roughly-parse before it enters the process?

[annevk]

It's not immediately clear how that would help as we don't necessarily know where a response will end up getting used due to service workers. All we have is a response and we need to determine whether to allow it through. I suppose instead of the final step of https://github.com/annevk/orb we could return the resource after it has been parsed as CSS rather than blocking it (and modify some of the other steps to not require a MIME type). Hmm...

[annevk]

Closing this in favor of annevk/orb#28.