It's been brought to my attention that Mozilla will be changing their implementation of <video/> to default deny cross-site requests. (http://www.w3.org/Bugs/Public/show_bug.cgi?id=6104) In other words: <video src="http://someothersite/videos.ogg"/> Will not work by default. It will not work like the <img/> tag does, or like the embed/object tags do which are used to embed Flash applications, or things like QT video work today. There is a new HTTP access control mechanism http://www.w3.org/TR/access-control/ which can be used by the target server to instruct the client to allow the access. Because it took me a while to understand the implications for these GET requests, I'll explain how the authentication sequence would work: (check my work, if I get this wrong, please correct me). My site, somesite.com has a document which contains <video src="http://yoursite.com/video.ogg"/>. A client visits the document. The client attempts to play the video. It connects to yoursite.com and includes a http request header "Origin: somesite.com". Yoursite.com consults its configuration and responds with "Access-Control-Allow-Origin: somesite.com". The video plays. Alternatively, it could reply with "Access-Control-Allow-Origin: *" and the video would play. If the server us unaware of this little dance and does not include the header, or replies with some other "Access-Control-Allow-Origin:" (perhaps due to an unaware cache) the video will not load and play. I believe this will have some fairly significant impacts on the usability of the <video/> tag, but I'm not completely sure that I understand the authentication mechanism or the implications. I think this issue needs more eyes on it, but I'll ask that you not pick up your pitchforks until we really know that we understand the implications. Thanks.
Robert O'Callahan sent this, in reply to Gregory Maxwell's post, but is not a member of the list and it seem to have got lost. ---------- Forwarded message ---------- From: Robert O'Callahan <robert at ocallahan.org> Date: Thu, Nov 6, 2008 at 3:34 PM Subject: [theora] <video/> and cross site scripting policy. To: theora at xiph.org BTW, a couple of reasons why a default same-origin policy (with opt-in relaxation via Access Controls) is a good idea: The main reason is that it gives servers control over who uses their resources. Checking 'Referrer' headers doesn't work well since it denies access to anyone behind a firewall that strips Referrer for good privacy reasons (or similarly, disables Referrer in the browser for the same reasons). Another reason is that cross-origin loads have been a huge source of security problems on the Web. For example, if a user at example.org visits evil.com, we don't want evil.com to be able to guess the names of videos on intranet.example.com, test if they exist, load them and determine their length and size, get closed-caption data, etc. Yes, similar attacks are already possible on images, scripts and CSS --- and that's been a gigantic source of security troubles. We'd block cross-site loads of those resources if we could without breaking the Web. For new kinds of loads, such as XHR, downloadable fonts, and <video> streams, we would like to get it right this time. The burden of configuring the "Access-Control-Allow-Origin: *" header on the servers that are willing to serve video (or fonts etc) to the world seems like a reasonable tradeoff. 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]
---------- Forwarded message ---------- From: Robert O'Callahan <robert at ocallahan.org> Date: Thu, Nov 6, 2008 at 5:12 PM Subject: Re: [theora] <video/> and cross site scripting policy. To: Gregory Maxwell <gmaxwell at gmail.com> Cc: Chris Double <chris.double at double.co.nz>, theora at xiph.org On Thu, Nov 6, 2008 at 4:12 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:> > On Wed, Nov 5, 2008 Robert O'Callahan <robert at ocallahan.org> wrote: > [snip] > > The main reason is that it gives servers control over who uses their > > resources. Checking 'Referrer' headers doesn't work well since it > > denies access to anyone behind a firewall that strips Referrer for > > good privacy reasons (or similarly, disables Referrer in the browser > > for the same reasons). > > I think most people who have done serious web work are aware of the > significant shortcomings of referrer (unreliability, inability to > distinguish reference from embedding, etc). I'm very glad to see the > new control tools. > > But what would be lost for this purpose by having a fail-working > situation: Client sends "Origin:" and the client displays the result > unless the server response indicates otherwise?Good question. The main reasons: 1) It's generally a good idea to make the secure option the default. 2) Access Controls is used in situations (such as cross-site XMLHttpRequest) where the default is (and must remain) restriction to same-origin. Varying the default based on the kind of load would be confusing, and probably dangerous. Also, if <video> becomes really popular on the Web, as we hope, then I predict that most sites will not want to let other sites "hotlink" to their videos. A smaller number of high-volume sites and hosting providers will. If so, then it's less configuration burden to default to same-origin.> [snip] > > and that's been a gigantic source of security troubles. We'd block > > cross-site loads of those resources if we could without breaking the > > Web. > [snip] > > If this functionality were implemented as fail-working server-opt-in > it could be provided for all media.Yes. In fact, I think we do want to support a server header which says "This resource should not be loaded cross-origin, unless there is additional Access Controls metadata which says otherwise". But that *sucks*. It's only acceptable as the best of a bad set of options for dealing with legacy assumptions.> Is there any reason to expect that <video/> would present a different > security profile from images? (barring implimentation bugs, of course)For <img> we have a bunch of problems with cross-origin information leakage. We try very hard to avoid leaking any more information than the image's existence and size. For example, if a page draws a non-same-origin image into a <canvas>, we "taint" the canvas so that the canvas toDataURL method no longer works. (Of course we have to propagate taint if a tainted canvas is rendered into another canvas...) We now face subtler methods of pixel extraction, such as using SVG filters to move data from color channels to alpha channels and then using SVG pointer-events and the DOM elementFromPoint method to extract information from alpha channels via hit-testing. (See http://markmail.org/message/w3fz4qxycfa2tbic ) <video> has all that of course, but also more because the <video> element's interface is much wider than the <img> element, and it's likely to get wider with time. For example, it would be great if scripts could access read closed-caption data in the stream, but obviously we don't want to leak that data cross-origin. Should a scriptable API to test the video format be accessible cross-origin? Etc.> I routinely see problems where users are hosting files where the > webserver mis-identifies mime types and causes client misbehavior.That is a problem we're quite familiar with :-)> > Even though most webserver software allows mime overrides via simple > tools like htaccess solving this simple problem is far beyond the > technical sophistication of many content creators, and if the server > is controlled by someone else it may be nearly impossible to get a > simple configuration change. I would expect access-control to be > significant more difficult in the short term, and no easier in the > long term.Serving media streams that can be "hotlinked" by anyone in the world doesn't seem like something that everyone is going to want to do. If you want to do it, you need a reasonably large operation capable of handling a lot of traffic. Already today most people who want to serve video just upload it to some site that does all the hard work for them. Note that serving your video in an IFRAME that other people can include cross-origin remains an option.> I hope that at a minimum it will be possible to interrogate the > <video/> object via JS and determine that access was rejected by the > target server so that a human-compatible error message can be produced > rather than silent failure.We should look into that.> Am I off the mark?No. This is a vexed area where all options are unsatisfactory. 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]
Forwarding Robert's reply. We've been silently discarding non-member posts. I've changed it back to moderator-queue accumulation for the moment, so future replies can get through. Very amusing given we're discussing access controls. -r ---------- Forwarded message ---------- From: Robert O'Callahan <robert at ocallahan.org> Date: Thu, Nov 6, 2008 at 4:40 PM Subject: Re: [theora] <video/> and cross site scripting policy. To: Ralph Giles <giles at xiph.org> Cc: Gregory Maxwell <gmaxwell at gmail.com>, theora at xiph.org On Fri, Nov 7, 2008 at 1:14 PM, Ralph Giles <giles at xiph.org> wrote:> > On Thu, Nov 6, 2008 at 2:44 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote: > > > Also, if <video> becomes really popular on the Web, as we hope, then I > > predict that most sites will not want to let other sites "hotlink" to > > their videos. A smaller number of high-volume sites and hosting > > providers will. If so, then it's less configuration burden to default > > to same-origin. > > This feels like the crux of your trade-off. The only way I've been > able to make sense of your position here is if you're already against > hot-linking.I'm not against it at all. If you can't make sense of the points I raised in my last email (or you think I made them in bad faith), then I guess we can't communicate.> > Serving media streams that can be "hotlinked" by anyone in the world > > doesn't seem like something that everyone is going to want to do. If > > you want to do it, you need a reasonably large operation capable of > > handling a lot of traffic. Already today most people who want to serve > > video just upload it to some site that does all the hard work for > > them. > > And it's a fairer burden for a large operation to implement the access > control headers everywhere?Absolutely. The larger the operation, the less relative effort it is to make a trivial one-time configuration change.> I have to agree with Greg: this will be a serious blow to <video> > adoption. The whole point of the new elements was to simplify > embedding video as a first class element in html. Your access > restriction plan makes serving video just as complicated as the way > flash video works now, where it essentially has to be dynamic.Embedding video is completely simple as long as it's same-origin or the media server sends a single static header.> It will work fine as long as I put up a page and the video on the same > server. Until I try to embed it in my blog.You can link to video on your server from a third-party blogging site just fine, as long as you have "Access-Control-Allow-Origin: *" configured on your server. (If you use Apache, it should be as simple as adding Header set Access-Control-Allow-Origin "*" to your .htaccess.)> Or until my cheap shared > webhosting runs out of space I want to move the video to amazon's s3.I'm confident that S3 and other services will add support for Access Controls. Remember that as well as video, this spec is being used for XMLHttpRequest (including IE8's XDR) and fonts, and more stuff over time.> I certainly don't envy you implementing your taint tracking. And if it > doesn't apply to iframes, I guess in practice everyone will just use > an embed snippet that puts it in an iframe.It seems a lot easier to add that .htaccess line than to create even that one-line IFRAMEable page on the server. 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]
Thanks again for having the patience to discuss this with us, my response is inline: On Thu, Nov 6, 2008 at 7:40 PM, Robert O'Callahan <robert at ocallahan.org> wrote:> Absolutely. The larger the operation, the less relative effort it is to make > a trivial one-time configuration change. > >> I have to agree with Greg: this will be a serious blow to <video> >> adoption. The whole point of the new elements was to simplify >> embedding video as a first class element in html. Your access >> restriction plan makes serving video just as complicated as the way >> flash video works now, where it essentially has to be dynamic. > > Embedding video is completely simple as long as it's same-origin or the > media server sends a single static header. > >> It will work fine as long as I put up a page and the video on the same >> server. Until I try to embed it in my blog. > > You can link to video on your server from a third-party blogging site just > fine, as long as you have "Access-Control-Allow-Origin: *" configured on > your server. (If you use Apache, it should be as simple as adding > Header set Access-Control-Allow-Origin "*" > to your .htaccess.)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. And this is assuming Apache. Many other webservers do not provide a 'user' accessible way to change this. So the user is stuck waiting on the sysadmin to get around to it. You can assume the sysadmin may not be too eager, see my next point:> I'm confident that S3 and other services will add support for Access > Controls. Remember that as well as video, this spec is being used for > XMLHttpRequest (including IE8's XDR) and fonts, and more stuff over time.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/>. Now evilhacker.com sets up client side scripting which uses XMLHttpRequest to send users to Gregsbank.com, using their cached session/credentials and has them wire money to Russia. 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. 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.> 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...)
On Thu, Nov 6, 2008 at 4:40 PM, Robert O'Callahan <robert at ocallahan.org> wrote:> If you can't make sense of the points I raised in my last email (or you > think I made them in bad faith), then I guess we can't communicate.I'm sorry if I expressed myself badly. I've certainly never known you to act in bad faith! Trying again: this discussion, to the extent that many of us here are objecting to the cross-site controls as you've described them, is about the tradeoff between security and ease of use. I think you've weighed security too heavily, and am trying to understand why our conclusions are different. I can agree there's little difference in the barrier between people with their own little server and large organizations who have already thought about all this. The burden falls mainline on mid-size sites. The amateurs and startups, if you will. -r
On Fri, Nov 7, 2008 at 2:27 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:> Forget an IFRAMable page: someone trying to be a rude hotlinker could > simply IFRAME directly to the media itself.Yes, that works fine from Firefox: http://www.double.co.nz/video_test/iframe.html Chris -- http://www.bluishcoder.co.nz
On Thu, Nov 6, 2008 at 5:36 PM, Chris Double <chris.double at double.co.nz> wrote:> http://www.double.co.nz/video_test/iframe.htmlHere's a cross-site version, which presumedly will work after the access control changes: http://people.xiph.org/~giles/2008/iframe_test.html And here's a very similar-looking page which won't: http://people.xiph.org/~giles/2008/element_test.html Of course the iframe page doesn't have any neat features beyond user-controlled playback, including format-based fallback. -r
Hi, thanks Gregory for the heads-up, and to Robert for the explanation. One issue that I'm not clear on is: at what point does served content contain such information that it introduces vulnerabilities? Is it when it contains personalized content/markup, or javascript? Or is a static video file somehow susceptible to attack? I understand that the client must deny cross-origin loads in order to protect the user. So my question concerns what the default file serving behavior should be. If we specify to allow all access by default then stuff "just works" for the simple case of someone setting up a personal video server which just serves static files, and embedding the content from their existing blog (hosted elsewhere). I guess that what's important about that scenario is that the video files are static, which we can take to mean that: * the content and markup of the video are not personalized for the viewer * no application side-effects occur as a result of retrieving the video My understanding of the problem is that as the sophistication of video formats progresses, these assumptions will break which may allow sensitive information to leak. For example, a video may contain personalized markup, may itself be the response to part of a transaction, or may contain embedded scripting; and the markup content of a video may be queried by the containing web page. So ... is my understanding of the problem correct? The existing uses of web video are much like <img>, but in future we'd like to see more complex applications where the <video> is a customized part of the interaction. Well, that was a lot of abstract words. I'll finish this email with an example of a vulnerable script for a Web 3.0 video application, and a patch that makes it so! <script language="English"> Shop assistant: Hey there BOB, great to see you! You look FINE! How about a new hat? CLICK NOW to buy a new hat! All your friends like ALICE and MARY think you need a new hat! Shop assistant: Hey there BOB, great to see you! NICE HAT! Do you like ice cream? Wanna see a funny video of a DOG? CLICK NOW to see a funny video about a DOG! Shop assistant: Hey there BOB! This is a DOG! Would you like to know more? </script> Anyway, back to the static file scenario ... For the sake of experimentation, the attached patch to oggz-chop adds a response header allowing all access. If anyone wants to test this out, it would be trivial to modify the patch to specify a particular site. Of course we would want to make this configurable instead. cheers, Conrad. -> needs a new hat -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-add-Access-Control-Allow-Origin-header-to-oggz.patch Type: text/x-patch Size: 1901 bytes Desc: not available Url : http://lists.xiph.org/pipermail/theora/attachments/20081110/90f8b9fa/attachment.bin