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

[Gregory Maxwell]

On Thu, Nov 6, 2008 at 11:07 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> 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.

Back to the assumption that the server supports htaccess.

Even still,  It is still more complicated. From my perspective every
step is another chunk of users who won't get it working, and another
chunk who will shoot themselves in the head security wise.    With
that in mind I think we can understand each other's positions.

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

It depends.  Structured CMS systems like mediawiki will have that
behavior,  virtually everything else wont.   In practice people are
going to handle this incorrectly.

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

True.

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

This is a very good point which I had not fully considered.

I'd like to point out that <img> can be significantly improved:
Specify a header Access-Control-Deny-Origin: with the following rules:
 If there is an allow header mentioning your origin, allow. If there
is a deny mentioning your origin deny.  If there is a wildcard allow,
allow, wildcard deny deny.  No header?  Allow for legacy things, deny
for new things/unsafe things.

Under that scenario images would eventually gain the protection as
servers are updated to emit a deny.   But in that situation I'd
suggest that video should work like img in accordance with the
principle of least surprise.

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

I know if it's same origin or not but I do not know if the not-same
request will be permitted or denied by the target server.  The
fall-backs are clearly inferior to native support (including long load
times, wasted bandwidth, and some risk of triggering a client crash),
we would prefer not to use them unless we must (so, no flipping to
Java just because it's not the same-origin).   Additionally,  it would
create tremendous confusion if I popped up a message that said "This
video will not play because fooserver.com does not allow playback from
barserver.com. See here for more info on fixing this problem"  when in
reality the file is corrupt or just doesn't exist.  (if the file
doesn't exist AND the file was not permitted, this message is less
harmful)