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

[Robert O'Callahan]

On Fri, Nov 7, 2008 at 2:27 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> We spent nearly two hours trying on IRC to help someone get the mime
> types correct a few weeks ago, and all that took is a htaccess line
> (logs available if you don't believe me :) ).  While you might suspect
> the skill level of the person who took that long, this was someone who
> had already managed to author a rather sophisticated website and was
> just trying to get the media working right.


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).

I think this is this point raises serious flaw in the "just one line
> to allow wildcard access" argument.  With video you will be mixing
> things with vastly different security profiles under the same access
> control mechanism.  Video and image are nearly identical (you pointed
> out that video is somewhat worse, I can agree, but it's still very
> similar) while XMLHttpRequest is fairly similar.
>
> 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...

This can be avoided by being careful to add the access control header
> to video only, but you've now escaped the simple one line change.
> You're talking multiple lines, at least one per audio/video file type,
> and on some webservers (lighttpd, for example) doing more than a
> single static header is much more complicated.


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!

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.)

> It seems a lot easier to add that .htaccess line than to create even that
> > one-line IFRAMEable page on the server.
>
> Forget an IFRAMable page:  someone trying to be a rude hotlinker could
> simply IFRAME directly to the media itself.  I would be very surprised
> if any browser supporting <video/> did not also directly support
> playing media URLs, FireFox certainly does. (and would file a bug if I
> ever found one...)
>

Of course, you're absolutely right. I don't know why I forgot that, since I
implemented it :-).

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.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/theora/attachments/20081107/e2bb6685/attachment-0001.htm