[theora] <video/> and cross site scripting policy.

[Gregory Maxwell]

On Thu, Nov 6, 2008 at 9:05 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> I believe you, but "Access-Control-Allow-Origin: *" is easier to deploy than
> Content-Type (where you have to choose the right types and extension
> mappings etc).

Yes, until you need to apply it more specifically to prevent the
sudden introduction of XSS vulnerabilities all over the domain.

>> Consider: Gregsbank.com  adds an "Access-Control-Allow-Origin" => "*"
>> to their config, since thats whats a google search told them they had
>> to allow other sites to embed <video/>.
>
> I kinda wonder why a bank wants to serve hot-linkable video...

Oh come now, there are plenty of reasons why a bank might.
Promotional materials, for example.

But forget banks, XSS is a problem for any sites that allow logins.
You don't have to be a bank. This would be a problem for Wikimedia if
not for the fact that uploaded files are already moved to a separate
domain precisely to take advantage of XSS protection.

> I appreciate the issue, but the correct solution here is to serve video from
> a different machine and domain than the one that processes banking
> transactions!

Absolutely.

This is what many people who accept uploads are already doing to guard
against attacks from malicious uploaded content. This is what we do at
Wikimedia. This is also a reason why many people will by hit by the
same-origin policy. As static content is already on other domains for
scaling (CDN distribution, use of lightweight webservers/caches) and
security reasons.

But there are still many sites that won't but would still want to
allow hot linking. Especially smaller sites, for example the xiph.org
wiki would become vulnerable to XSS attack by using an allow all
policy, yet we would want to permit hotlinking images stored on or
servers.  Worse, people who donate capacity to us would make
themselves vulnerable or have to undergo even more complicated
configuration.

As I mentioned earlier in my message, this is a reason that webserver
operators should be unwilling to activate a wildcard allow-origin even
when they wish to allow hotlinking because they need to consider the
security implications for everything else on the domain.

This somewhat analogous to register_globals in PHP.   Some servers
have PHP configured with register_globals, it improves script
compatibility but causes terrible security holes.  Some sites have
register_globals disabled.   No one with an established wants to
change their setting because it will either make things break or make
things insecure.  Changing it selectively is just not worth the
trouble for the slim margin business that small time hosting is,  but
thats what a lot of the public is stuck with for small sites.

>> So with access control we've got a great security mechanism, but by
>> including video we're going to create an enormous incentive to lower
>> security below what we have today.
>
> I honestly don't think so. I don't think a bank or any similar organization
> is going to care that videos on their site can't be hot-linked. Furthermore,
> it's already good practice to isolate your secure services as much as
> possible from other functions. (So www.westpac.co.nz sends you to
> sec.westpac.co.nz for online banking.)

I shouldn't have picked a bank perhaps, since they'll have the
resources to run multiple servers an pay auditors to find these
problems.  XSS is a problem for more than banks.

[snip]
> But that's fine. IFRAMEing the video prevents the linking site from
> accessing the <video> object, which seals off the attack surface we're
> worried about. Now, IFRAMEs themselves have serious security problems
> ("clickjacking", for example), which we'll have to do something about, but
> that's a separate discussion.

Severely constraining the <video/> interface (making it roughly
equivalent to iframed video in the not-explicitly permitted case)
would have the same effect but would make the failure less severe.


I guess it's clear that this has been fairly well considered, and
other than the iframe I haven't thought of anything that you haven't.
I'm very disappointed that this is being addressed in a way which
makes <video/> gratuitously different from <img/> and which precludes
an equivalent security improvement for <img/>, but it seems clear I'm
not going to manage to convince a reconsideration here and now.

So in the interest of progress can we at least get a mechanism that
will allow JS to easily determine that the video failed same-origin
(no guarantee that the video exists, just that it failed same-origin)?

I'm requesting this because I expect that for the next decade <video/>
and <audio/> will usage will be accompanied by JavaScript that
determines the playback capability of the client (Native, embedded
object, Java, or Flash10 (we now have a Vorbis decoder in Flash10
bytecode, I expect Theora at some point in the not-distant future))
and scans the DOM for video/audio tags to be converted to the
appropriate playback mechanism.   If I can detect same-origin failure
I can give the user a sensible error or fall back to one of the many
'legacy' methods which you can not secure through a default-fail
mechanism.