Require CORS for HLS and DASH media formats

[annevk]

We've had a bit of a discussion exploring manifest-based media formats in annevk/orb#23. In particular, both HLS and DASH are resources that effectively list a bunch of other resources to fetch that when composed result in media. I think the effective conclusions of that thread are as follows:

• If the media element gets an "opaque" response that's HLS or DASH, treat it as a network error. This shouldn't really be possible with (C)ORB so maybe it can be an assert, except that https://tools.ietf.org/html/rfc8216#section-4 suggests HLS might do path extension matching(!). So I think it's possible for a resource to somehow make its way through https://github.com/annevk/orb and get identified as HLS, if implementations indeed do such a thing. There's such a path for DASH as well, but I think we should add application/dash+xml to the (C)ORB blocklist and if media elements require a MIME type for DASH it should then not be possible to get such an "opaque" response.
• Furthermore, we should require that any fetches that HLS and DASH resources want user agent to make use "cors" as request mode.

cc @whatwg/media @acolwell

[sandersdan]

Just some quick notes on Chromium Android's current HLS implementation for <video>:

• We fetch the manifest (following redirects) once before handing off to the platform player. The mode depends on the crossorigin attribute but typically will be no-cors.
• The platform player does its own content detection which does involve matching path components (not just extensions!). This is best (as in most safely) treated as an additional restriction rather than the primary detection method.

[annevk]

@sandandsnow I was led to believe there is a same-origin restriction on Android due to annevk/orb#23 (comment) by @acolwell. Is that not correct?

[sandersdan]

It is not correct. We set android-allow-cross-domain-redirect: 0 on the platform player, but this is after fetching and following redirects the first time. There is no origin restriction on the initial manifest fetch.

[annevk]

So what does that mean exactly? Say the document is on origin A and the manifest is on origin B. Does that work? What origin can the resources listed in the manifest be from?

[sandersdan]

That should work, and the resources must be on origin B.

It's worth noting explicitly that this is an incomplete implementation. A feature-complete HLS implementation would presumably support the full set of cross-origin media features and behaviors.

[annevk]

Okay, @anforowicz's https://crrev.com/c/3202583 has more context.

As you said this is a problem for Android/iOS (and for Safari on macOS) as per https://en.wikipedia.org/wiki/HTTP_Live_Streaming#Clients.

The same-origin-with-the-HLS-manifest limitation makes this hard to abuse for attackers. They would have to inject an HLS manifest into the origin of which they want to attack resources. Given the extremely lax resource type checking this is made easier, but it's still non-trivial.

For https://github.com/annevk/orb this presents a challenge. Thoughts:

• We cannot blocklist "application/vnd.apple.mpegurl" or "audio/mpegurl". I.e., part of Block manifest-based media and WebVTT annevk/orb#26 needs to be reverted.
• The ORB algorithm would have to be able to both detect and parse HLS in order to obtain the URLs the media element will want to fetch. It will need to allow responses to requests for those URLs to bypass ORB (similar to how certain range responses get a pass). It's not clear to me how well HLS detection and parsing are defined. (In the case where implementations hand of HLS to something else that they blindly trust with parsing and fetching we would only have to be able to detect HLS. It sounds like this might be the case in current HLS implementations of Chrome and Firefox at least.)

Both of these we could make conditional upon HLS support to reduce the attack surface when it's not supported.

@anforowicz @sandersdan what do you think?

[sandersdan]

A nit: there is also application/x-mpegurl and audio/x-mpegurl.

Parsing the manifests seems a bit extreme to me. The manifest resources are going to be one of (A) more manifests, (B) MPEG2 TS, or (C) MP4. I expect all of these would be treated as media resources and therefore allowed with no special handling.

I don't know offhand whether there are any issues with inaccurate content types on these resources.

Making the logic conditional on UA support seems reasonable, from the above list Chromium Android should be able to block MPEG TS since it's not supported by the current <video> implementation.