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

[Robert O'Callahan]

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

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


Putting all your world-accessible video files in one directory subtree and
changing the .htaccess there is still quite simple IMHO. At least if we do
it *now* before all this stuff is deployed and set up.

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.


Good.

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.


That is an issue worth thinking about. It doesn't seem to me very hard to
collect the resources you want to be world-accessible and configure them so
--- I presume video and similar resources are already collected together in
their own directory space, with scripts and other sensitive data elsewhere
--- but, I haven't thought about that very much and I don't have experience
at running a Web site.

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

That depends on how it's done. You'll start leaking the size of the video,
its existence, maybe its type. The spec gets more complex because it has to
describe behaviour in same-origin and cross-origin situations. So does our
code. There's more attack surface.

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.


One thing to keep in mind is that if we ship with a same-origin restriction
now, and then discover later that was a really dumb mistake, we can then
relax it and little has been lost. But if we ship with no restrictions and
then find out *that* was a dumb mistake, there's nothing we can do without
massively breaking things; we'll have to live with that mistake forever
(like <img>).

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 <vido/>
> 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.
>

Why do you need to distinguish same-origin failure from any other failure?
Wouldn't you try fallback no matter what the failure is? And wouldn't you
normally know whether the file you're linking to is same-origin or not?
These are not rhetorical questions, I really want to know :-).

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/d0236039/attachment-0001.htm