On Fri, Nov 7, 2008 at 4:38 PM, Gregory Maxwell <span dir="ltr"><<a href="mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Thu, Nov 6, 2008 at 9:05 PM, Robert O'Callahan <<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>> wrote:<br>
> I believe you, but "Access-Control-Allow-Origin: *" is easier to deploy than<br>
> Content-Type (where you have to choose the right types and extension<br>
> mappings etc).<br>
<br>
</div>Yes, until you need to apply it more specifically to prevent the<br>
sudden introduction of XSS vulnerabilities all over the domain.</blockquote><div><br>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.<br>
</div><div><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">But forget banks, XSS is a problem for any sites that allow logins.<br>
You don't have to be a bank. This would be a problem for Wikimedia if<br>
not for the fact that uploaded files are already moved to a separate<br>
domain precisely to take advantage of XSS protection.</blockquote><div><br>Good.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
But there are still many sites that won't but would still want to<br>
allow hot linking. Especially smaller sites, for example the <a href="http://xiph.org" target="_blank">xiph.org</a><br>
wiki would become vulnerable to XSS attack by using an allow all<br>
policy, yet we would want to permit hotlinking images stored on or<br>
servers. Worse, people who donate capacity to us would make<br>
themselves vulnerable or have to undergo even more complicated<br>
configuration.</blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">[snip]<br>
<div class="Ih2E3d">> But that's fine. IFRAMEing the video prevents the linking site from<br>
> accessing the <video> object, which seals off the attack surface we're<br>
> worried about. Now, IFRAMEs themselves have serious security problems<br>
> ("clickjacking", for example), which we'll have to do something about, but<br>
> that's a separate discussion.<br>
<br>
</div>Severely constraining the <video/> interface (making it roughly<br>
equivalent to iframed video in the not-explicitly permitted case)<br>
would have the same effect but would make the failure less severe.<br>
</blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I guess it's clear that this has been fairly well considered, and<br>
other than the iframe I haven't thought of anything that you haven't.<br>
I'm very disappointed that this is being addressed in a way which<br>
makes <video/> gratuitously different from <img/> and which precludes<br>
an equivalent security improvement for <img/>, but it seems clear I'm<br>
not going to manage to convince a reconsideration here and now.</blockquote><div><br>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>).<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">So in the interest of progress can we at least get a mechanism that<br>
will allow JS to easily determine that the video failed same-origin<br>
(no guarantee that the video exists, just that it failed same-origin)? <br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
I'm requesting this because I expect that for the next decade <vido/><br>
and <audio/> will usage will be accompanied by JavaScript that<br>
determines the playback capability of the client (Native, embedded<br>
object, Java, or Flash10 (we now have a Vorbis decoder in Flash10<br>
bytecode, I expect Theora at some point in the not-distant future))<br>
and scans the DOM for video/audio tags to be converted to the<br>
appropriate playback mechanism. If I can detect same-origin failure<br>
I can give the user a sensible error or fall back to one of the many<br>
'legacy' methods which you can not secure through a default-fail<br>
mechanism.<br>
</blockquote></div><br>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 :-).<br clear="all">
<br>Rob<br>-- <br>"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]<br>