Monday, November 10th, 2008

Video and audio tags and cross origin access

Category: HTML

Thanks to Chris Double I saw the email thread on cross origin access to media files via the video and audio HTML 5 tags.

Jonas Sicking does a great job at explaining the issue, and why we need to restrict access. This is going to take a lot of people by surprised. Most will assume that you can video src="my cdn" to another domain just as you can with img, iframe, and a few others. Having to tweak server side headers is a significant barrier (remember why PHP did so well?) and as we move to the cloud, it is yet another feature that is required, so we can let users tweak it.

But, let’s listen in to Jonas and his thoughts on why, despite the pain, we need to do this correctly:

Why restrictions?

It is an absolute requirement from a security point of view that data is
not leaked cross site. We don’t want a page on an internet server, lets
call it attacker.com, to read data that lives on an intranet server
behind a firewall, intranet.com.

It is also important that that one site, attacker.com, can’t read
personal data stored on other site, bank.com. If it could it would be
possible for any site to read your bank statements as soon as you log in
to your bank.

This is why we for example only allow XMLHttpRequest to make requests to
the same site, but not other sites.

Unfortunately we have inherited a few exceptions to this same-site rule
from the olden, more innocent, days of the internet when security wasn’t
as heavily considered. This is why for example <img>, <iframe>, <link
rel=stylesheet>, and <script> can be used cross site.

In all of these cases we try very hard to limit access as much as possible.

For example while you can display another site in an <iframe>, you can’t
reach in to the DOM of the page. However click-jacking was recently
discovered which might mean that we’ll have to put very complex
restrictions on iframes. Or rely on that sites deploy their own
protections against it. Many probably won’t due to not knowing about the
issue.

And while you can style your page using a cross site <link
rel=stylesheet> you can’t read parse errors since then you could point
to a url of a HTML page that contains sensitive data and potentially get
sensitive information through the parse error messages. We are somewhat
saved here by the fact that it seems very unlikely that someone would
put sensitive data into a stylesheet.

However if someone did, for example a stylesheet setting a background
color to different colors depending on portfolio results in the last
quarter, that data could be read by any site on the internet. Even if
the stylesheet lives on a server protected by firewalls and/or requires
login. This is something that web developers simply has to know. Most
probably don’t.

We are in a bad situation with <script> and we have had situations where
sensitive JSON data could be read by pointing a <script> tag at it. The
way we had to fix this was adding limitations to the javascript language.

With <img> we are trying very hard to not expose more than what we can’t
prevent. So for example you can get the size of the image (since we
can’t prevent that anyway since it affects layout), but you can’t get
the pixel data. If we allowed pixel data to be retrieved, again any site
on the internet could read any image data placed on a webserver, even if
protected by passwords/firewalls.

This has prevented the API for <img> to remain unchained for years. And
when we added <canvas> we had to deal with tainting which can cause
confusing behaviors for developers since suddenly certain APIs break. As
roc recently pointed out, pointer-events is another recent expansion of
the browser API which is going to get much harder to implement due to
the unchecked cross-site loading of <img>, and for sure result in that
cross-site images will work differently from same-site images.

Posted by Dion Almaer at 7:07 am
8 Comments

+++--
3.1 rating from 15 votes

8 Comments »

Comments feed TrackBack URI

Sorry, I don’t remember why PHP did so well. Would like to have my memory refreshed though…

Comment by igitur — November 10, 2008

Restrictions, restrictions, restrictions. That’s what we need, restrictions. It seems everything is about restrictions and security it should enforce, today. I don’t understand why we need this. So the audio and video tags have to be restricted, because else someone could access a video on a non official web site? Has Chris Double ever thought about the fact, that Firefox or Webkit are open source and every person with some programmings skills could compile a version without these restrictions?
Probably the world would be much more secure, if everyone lived in a cage and would never go out. Every time I go shopping, I risk to be pickpocketed. Everytime I drive my car, I risk to have a crash. Should be really give up our freedom for more and more security?

I don’t think so.

Comment by AndiSkater — November 10, 2008

Restrictions on video?, the streaming methods and media servers gives solutions enought for this issue…

I agree that some of the videos requires some security but those are only very specific cases.

I don’t think this has to be a front-end issue.

Comment by whoisyeco — November 10, 2008

In other news, the ‘anchor’ tag will also be modified to prevent cross site access. It is currently possible for an attacker to set up a link that redirects the user to ‘attacker.com’ which could be harmful. In future only internal links will be possible.

Comment by mblaney — November 10, 2008

AndiSkater, Chris Double is very aware that Firefox and others are open source and can be modified. In fact, Chris Double is not a fan of the access restrictions, even though he blogged about it. It’s my opinion it’ll be a big barrier to adoption of video and audio.

On the other hand I respect jonas and he has given this a lot of thought and I see his points. I don’t know of a good solution.

Comment by doublec — November 10, 2008

I think the big failure here is that Chris is pointing out the very failure in blocking XS functionality because it’s a never-ending spiral of tags that can be exploited. In order to maintain compatibility with existing sites, though, as Chris mentions, browsers must permit cross-site access to CSS and images.

Video tags won’t ever supplant existing formats (such as FLV) if there’s no way to cross-embed it. Think YouTube.

The better solution is something specific to do with the media itself; some way to explicitly permit embedding. Even if it’s just using the REFERER header at the server end to restrict serving of the file to requesters of the expected domains.

This is a security issue that should be handled by the media servers, not the web browsers.

Comment by Kit — November 10, 2008

That makes HTML5 useless. Flash doesn’t have such a limitation.

Comment by AdrenalinMd — November 10, 2008

security kills invention. i will accept the risk.

Comment by jayridge — November 10, 2008

Leave a comment

You must be logged in to post a comment.