Add a security consideration about content sniffing.

[jyasskin]

This fixes #321, I think. @molnarg, how do you feel about this?

I'll need to add this to bundles too, but I want to get the SXG text right first.

---

Preview | Diff

[nyaxt]

still lg

[nyaxt]

Chromium CL: https://chromium-review.googlesource.com/c/chromium/src/+/1373430

[annevk]

I need some help understanding the model.

Is the idea that application/signed-exchange and application/webbundle responses cannot be sniffed as scripts or same-origin quirks mode style sheets? If so, we could add them to https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-mime-type?. I don't think it matters for other nosniff contexts per https://mimesniff.spec.whatwg.org/#determining-the-computed-mime-type-of-a-resource.

Or is the idea that the responses they encompass (i.e., those in the bundle/archive) cannot be sniffed? If so, we could "dynamically inject" this header when we create those responses ensuring "determine nosniff" always returns true for them downstream.

[jyasskin]

@annevk One of the bigger risks is that they might be sniffed as PDFs, Flash, or other plugin-recognized types. The risky file types don't necessarily follow the Fetch spec, so the header isn't guaranteed to work, but we thought it'd improve our chances.

@mikewest may have other answers. He suggested requiring nosniff here. We also want to make internal responses automatically nosniff, but that'll come in a separate change.

[annevk]

Ah plugins, that is indeed a poorly specified area. Note that currently we don't have any language that suggests nosniff would work for plugins.

[jyasskin]

Yep. I don't personally have evidence that this improves things for any particular plugin; we're just hoping. I don't have strong feelings about whether this is the right thing to do.

[annevk]

I think we need to know concretely what this will help with so it can be tested for (and specified if it isn't already). In particular as we'd have to do this for other new formats too, presumably (e.g., Wasm)? (I see the benefits for the contained non-HTTP responses, but as you said that's separate.)

[mikewest]

In general, I'd like for us to be strict about new mechanisms we're adding to the platform that might result in executable code. I don't have any concrete examples of places where plugins could misinterpret an SXG response as something unfortunate, but there are a number of examples of plugins' propensity to zealously sniff incoming content into executable code. I'd like to make that less likely.

That said, when I was talking with @jyasskin about this a few days ago, I incorrectly assumed that nosniff applied to plugin content. In the meantime, @jyasskin pointed out that https://html.spec.whatwg.org/multipage/iframe-embed-object.html#object-type-detection makes strictly obeying Content-Type headers entirely optional for plugin resources, and that we apparently don't do so in Chrome. I think we should change that (though I don't have any data that would suggest that it's safe to do so; I'll add some metrics). If we don't, then I think I agree with @annevk that the Fetch bits of this change wouldn't have any teeth.

Or is the idea that the responses they encompass (i.e., those in the bundle/archive) cannot be sniffed? If so, we could "dynamically inject" this header when we create those responses ensuring "determine nosniff" always returns true for them downstream.

As above, I'd like for us to strictly enforce MIME type checks for resources contained in SXG responses. Implicitly injecting a nosniff requirement seems like it would indeed be simpler for developers, so I'd be on board with that kind of mechanism. It seems like requiring developers to include the header has a higher chance of increasing usage even in browsers that don't support SXG (as presumably developers would inject the header themselves on both the SXG-encoded resource, and the plain ol' resource), but that might be asking too much.

[jyasskin]

I'm going to revert the discussion of X-Content-Type-Options:nosniff in this PR, to land the general anti-sniffing advice, and then open a new PR that deals specifically with that header, both for the SXG itself and for its contents.