HTML 5.0
On good authority I was told to take a good hard look at the newly proposed HTML 5.0 spec that’s floating around the WHATWG. Firstly my eyes went to the new video and audio tags which are meant to help users deal with the apparently confusing nature of the fact that we have img tags instead of just using embed for everything. Personally I think that’s just a horrible idea that’s going to break a lot of blacklists out there and potentially open more security holes depending if the scriptable video objects are allowed, but there you have it.
Anyway, so then my eyes glanced across the new iframe spec and lo and behold I saw a miracle. Someone over at the WHATWG was really paying attention. Firstly, there’s a new parameter called sandbox which is similar in many respects to IE’s proprietary security=”restricted” parameter but with more granular controls. That’s not necessarily a good thing if you don’t like being framed, but it does give websites more control over what happens to their site once they frame a site that turns out to be bad.
But more importantly there is another new parameter called seamless which will allow a page of the same origin domain to iframe a page without having all the usability issues (double scroll bars, _self targets and so on) of the original iframe model. That’s great news for websites that want to frame and control a page on their own domain (a la content restrictions) without all the crazy usability issues with iframes. There’s some other security concerns with allowing content to be accessible on your site - there needs to be some tag to disallow rendering unless it’s embedded within an iframe to prevent someone from calling the malicious child frame directly. However, this is a big step forward in the right direction.
August 16th, 2008 at 11:50 am
RSnake what do you think on the issues I’ve highlighted in this paper?
http://trivero.secdiscover.com/html5whitepaper.pdf
What ways WHATWG and W3C should attempt to make even more secure their new client-side storage solutions?
August 17th, 2008 at 11:06 pm
Actually, the purpose of audio and video tags is to have a standardized way of embedding audio and video without having to rely on the presence (and quirks) of plugins and codecs. Could you explain your concerns here in more detail? If the blacklist is looking for the string “embed”, won’t it be broken by a slightly obfuscated document.write already?
August 18th, 2008 at 6:39 am
@Wladimir - when I talked to the person who first brought this to my attention about video and audio he said you will still require codecs, so we may be getting mixed messages. If what you’re saying is true, that would be nice for the consumer, but I don’t get how that would really work in reality, given how many different encoding methods there really are, unless they are trying to compete with the stand alone video players out there. And no, blacklists won’t be broken by obfuscated document.write unless they already allowed JavaScript in the first place. Not that I’ve ever thought blacklists were a good idea, but for some reason otherwise smart people still use them regularly.
August 18th, 2008 at 8:06 am
@Ameft that was a good paper. The areas of abuse is mostly around the implementation from what I can see, but you did a nice job explaining it. The troubling part for consumers is how do they remove it/opt out of it in the browser, if they don’t feel comfortable with it?
August 18th, 2008 at 8:46 am
While not specifically about the video and audio tags themselves, this FAQ on the Vorbis site has many useful details: http://www.w3.org/QA/2007/12/when_will_html_5_support_soone.html Reading that page along with http://www.w3.org/html/wg/html5/#video and http://www.w3.org/html/wg/html5/#audio and even the Wikipedia article here http://en.wikipedia.org/wiki/HTML_5.0#Ogg_controversy all seem to point to video and audio being supported natively for the browser with some sort of built-in codec. Audio does mention use of a ‘codecs’ tag which would tell the browser what codec to use to play embedded audio. The goal (I think) is to have a format that a person could stick on the Internet for audio and video like you can with any standard image. Stick it in a simple self-hosted HTML page and have other folks be able to access it without the need for an external program or potential external licensing problems.
August 18th, 2008 at 11:48 am
There is much discussion around what codecs should be supported. Originally Ogg Vorbis and Theora were listed as mandatory, then they were removed due to concerns about submarine patents. In Firefox 3.1 these formats will be supported nevertheless, I guess other browsers will add support soon as well. So Ogg should be the common denominator. I am not sure whether current Firefox nightlies can already use other codecs installed in the OS but I think that was planned as well.
I understood where you are going with blacklists - I was thinking along the lines of firewalls, but you were talking about HTML sanitizing in web applications.
August 18th, 2008 at 6:14 pm
@RSnake - Supposing I’ve got what you mean (here in Italy is 3 AM), the browsers should allow the user to disable the three storage techniques in some (easy) way but for the moment you can only disable database storage in Safari. So actually this is a trouble. The problem is that in the near future will become hard to surf on the Web x.0 without the storage techniques of HTML5, like now is hard to surf without cookies. In the end, the only way I see is to narrow down even more the attacks that allow the theft of client-side data, like XSS, CSRF and their variants. In this situation I can’t see something like HTTPOnly to protect you.
August 19th, 2008 at 7:52 am
@ameft - I can see that happening in the future, but probably not soon enough to make it a real problem for people who are paranoid. Typical consumers, however, are pretty much totally screwed at this point. They have no way to opt out, they don’t know how to clean it, and they don’t know that it exists. There’s no way to explain it to them in a straight forward way either. This leaves a lot of room for toolbars/add-ons that do this sort of cleaning for you, so users can install one thing and get the privacy that the browsers/websites don’t give you. Eventually that too will probably get rolled up into the browsers, but then there will be the next round of offline storage tools that it won’t cover and so on.
The cycle repeats itself because websites are always pushing browser manufacturers for new/interesting long term storage so they can get long term persistence out of the browser. Only with the advent of web2.0 was this really an interesting conversation, but I only see this growing with time. I agree, it’s a big issue and it’s not going away any time in the near future. Hopefully someone who reads this site will invent a plugin to remove all those tracking cookies/flash cookies/offline storage things all in one click. Until then, consider yourself tracked and your data slightly more at risk if anything sensitive is stored there.
August 19th, 2008 at 9:24 am
Maybe the development of that plugin (or a JS + AS script that will be cross-browser, but more uncomfortable..) could be my occupation in September.
August 20th, 2008 at 3:36 pm
Hm.. Seems your site strips out angle brackets AND tags? Can’t be too careful, eh? Re-posting without angle brackets - feel free to delete the above..
VIDEO will be scriptable but in a pretty limited way, AFAIK exposing a minimal API *from page to player* only and nowhere like the complexity of our current plugin solutions. I think VIDEO will improve security here - even if not blacklisted.