On Fri, Nov 7, 2008 at 2:27 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;">
We spent nearly two hours trying on IRC to help someone get the mime<br>
types correct a few weeks ago, and all that took is a htaccess line<br>
(logs available if you don't believe me :) ). While you might suspect<br>
the skill level of the person who took that long, this was someone who<br>
had already managed to author a rather sophisticated website and was<br>
just trying to get the media working right.</blockquote><div><br>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).<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;"><div class="Ih2E3d">
I think this is this point raises serious flaw in the "just one line<br></div>
to allow wildcard access" argument. With video you will be mixing<br>
things with vastly different security profiles under the same access<br>
control mechanism. Video and image are nearly identical (you pointed<br>
out that video is somewhat worse, I can agree, but it's still very<br>
similar) while XMLHttpRequest is fairly similar.<br>
<br>
Consider: Gregsbank.com adds an "Access-Control-Allow-Origin" => "*"<br>
to their config, since thats whats a google search told them they had<br>
to allow other sites to embed <video/>.</blockquote><div><br>I kinda wonder why a bank wants to serve hot-linkable video...<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;">
This can be avoided by being careful to add the access control header<br>
to video only, but you've now escaped the simple one line change.<br>
You're talking multiple lines, at least one per audio/video file type,<br>
and on some webservers (lighttpd, for example) doing more than a<br>
single static header is much more complicated.</blockquote><div><br>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!<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 with access control we've got a great security mechanism, but by<br>
including video we're going to create an enormous incentive to lower<br>
security below what we have today.</blockquote><div><br>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 <a href="http://www.westpac.co.nz">www.westpac.co.nz</a> sends you to <a href="http://sec.westpac.co.nz">sec.westpac.co.nz</a> for online banking.)<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;">> It seems a lot easier to add that .htaccess line than to create even that<br>
<div class="Ih2E3d">
> one-line IFRAMEable page on the server.<br>
<br>
</div>Forget an IFRAMable page: someone trying to be a rude hotlinker could<br>
simply IFRAME directly to the media itself. I would be very surprised<br>
if any browser supporting <video/> did not also directly support<br>
playing media URLs, FireFox certainly does. (and would file a bug if I<br>
ever found one...)<br>
</blockquote></div><br>Of course, you're absolutely right. I don't know why I forgot that, since I implemented it :-).<br><br>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.<br>
<br clear="all">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>