Posted
by
Soulskill
on Friday September 17, 2010 @12:45PM
from the new-armor-with-new-holes dept.

Trailrunner7 writes "Every technology innovation has its coming out party, and Google Inc.'s recent 'dancing balls' logo experiment was widely interpreted as a high-impact debut for HTML5. But web security experts are warning that the sprawling new web standard may favor functionality over security, enabling a new generation of powerful web-based attacks. They agree that there are security enhancements in HTML5, but all expressed the same concern: that the new specification will greatly increase the 'attack surface' of HTML — providing more avenues by which malicious code can be delivered through the web. 'HTML5 has an enormous amount of functionality. The (specification) is just huge,' said Jeremiah Grossman of security firm WhiteHat. The breadth of the new specification gives him concern. 'I know that we're still finding vulnerabilities in HTML4,' Grossman said."

One of my favorite things about Flash is that it's easy to block and control. There's times when I want the functionality Flash is providing - but most times, I'd rather pretend that I don't have it installed. I was rather rudely reminded of this the other day when I installed Flash on my Android phone. I was all happy until I started browsing around. Until I get NoScript on my Android, Flash has been removed.

With this in mind, I'm wondering what level of control we might have over HTML5.

That's not possible in the current spec. The browser has no idea that a canvas is even being used for animation, let alone when an animation has completed. Well, OK, a simple heuristic of "if this canvas is being repeatedly updated, it's an animation" is possible. But the problem is you still don't know when an animation has looped once.

The best thing that can be done is to refuse to update a canvas after it's been updated once.

So then people start removing and replacing the canvas element... Or use video instead... Or start using the audio APIs...

Really, a lot of the new APIs are really cool from a web developer "whiz-bang" point of view, but the HTML5 spec authors don't seem to give a damn about actually providing control to the user. Rather it's the whole "it's MY content, you MUST view it MY WAY!!!" stance yet again.

On the other hand, there's the thing where you can't full screen video in HTML5 because evil web page authors might some how trick people into typing their password into a video. Yet you can full screen Flash - they seem to have come up with a solution (the "press ESC to exit full screen" banner) so it's not like there's absolutely no way to protect users.

So who knows what the HTML5 developers are thinking, because the inability to full screen HTML5 video makes it a complete non-starter versus Flash video. Especially if you want to share HD video.

I'm sorry, but why should full-screen be part of the API? It is a browser UI feature. Firefox 3.6 supports it, other browsers are at least planning support for it. If you do not like the UI for it in the browser you use, use a different browser or submit a bug report. It is a browser issue, not an HTML5 issue.

Go ahead. Explain to someone that in order to watch a video full screen they will need to either:

1. Context-click the video and choose the "Full Screen" option, assuming there is one. This only works when using the browser's built-in video controls, I think.

2. Click on the "expand" button to expand the video to take up the entire tab, and then use your browser's Full Screen feature, which is probably F11 except when it's something else. Or if you're using Safar

Rather it's the whole "it's MY content, you MUST view it MY WAY!!!" stance yet again.

There is a cure for that attitude - for the same reason that Facebook pretty much wiped MySpace off the map, or the way Google turned Yahoo! into a has-been: Keep it clean and user-friendly, keep the ads un-intrusive, or face instant death in the face of superior (cleaner, less intrusive) products.

One of my favorite things about Flash is that it's easy to block and control. There's times when I want the functionality Flash is providing - but most times, I'd rather pretend that I don't have it installed. I was rather rudely reminded of this the other day when I installed Flash on my Android phone. I was all happy until I started browsing around. Until I get NoScript on my Android, Flash has been removed.

In the Android browser settings, you can set it so that plug-ins will only show a placeholder until the plug-in is activated for a particular page. It basically gives you Flashblock functionaility, except activating one flash doc on a page will activate them all.

As I posted elsewhere here (but modded down into oblivion because fanboys will be fanboys), all I have to say is thanks Apple.

All because you wanted to be greedy. Fanboys kept saying it was because of "the superior experience," but it really was so that Apple got a cut from one buying 30 Rock from ITunes instead of being able to stream it from Hulu via flash.

So instead of being able to use Flashblock to block malware and only view video when we chose (and not having multiple video ads/misc b

AFAICS it is already at least partially. I can whitelist for example ogg@domain.net/.../video.ogg or Font@domain.net with NoScript. But I couldn't find this for audio. But since Firefox's HTML5 audio player requires JS it can be easily blocked as well.

But I'm really sick of hearing about HTML5. Maybe it's because every other day I see/hear a high level exec coming around and going crazy with statements like "HTML5 IS THE FUTURE WE HAVE TO BE ON IT. RIGHT NOW." Then I have to spend an hour explaining why it's not even currently usable for any serious enterprise application, and how the spec is not yet solidified.

Standards are important but without fancy technology buzzwords I don't think the IT department would ever get funding.

You're probably right. The downside is you end up hiring people based on their "qualifications" that consist of listing a buzzword on their resume. Or when some marketing guy gets it stuck in their head and thinks they know how to do your job. Or when your site becomes a mess because someone in management insists that you include all these buzzword "technologies" in order to be on the "cutting edge".

Just because a spec isn't finalized doesn't mean some of the feature haven't been implemented. You can find what's been implemented [html5readiness.com] and just maybe, impress your boss.

The web page you linked is an example of what can go wrong with HTML5 in the wrong hands: it ends up just like Flash in the wrong hands has ended up for years. Not only does it use mystery meat navigation [webpagesthatsuck.com], but it also takes literally four seconds from when I move the pointer to when another wedge of the graph lights up. I'm using the latest release version of Firefox (3.6.10) on Windows XP.

You don't know what you're talking about. There's no mystery-meat on that page. The only navigation are clearly labeled text links.

And just because your particular browser sucks at rendering the interactive graph doesn't make it a bad page. The whole point of the graphic is to illustrate browser support for HTML5 in a compelling way. And how better than to make that display actually use and encourage HTML5

FF is the weakest of the current browsers when it comes to javascript and canvas speeds. Safari and Chr

Implementing stuff before the spec is finalized. That just seems weird.:P:)

A proper spec isn't finalized until a reference implementation is ready. One of the reasons that some of the HTML 4.01 features never entered wide use is that absolutely nothing supported them correctly for years after HTML 4.01 became a W3C Recommendation. Take the <col> and <colgroup> elements for example; those still aren't consistent even in browsers that do support them.

That is the slowest, clunkiest, most visually confusing, least responsive, and perhaps most overall depressing site I've been to this year. God, if I showed that to my boss arguing for html5 we'd get knocked clear back to plaintext. Maybe it's my browser, but Firefox 3.6 is a fair chunk of market share.

And as another person said, this is exactly the kind of thing that happened with Flash -- making fancy gizmos just because we can. This is why we programmers aren't let outside where the normal people play

Really, it seems like one of the (very) few HTML5 things that work across browsers is the contenteditable attribute, which Internet Explorer has implemented since I believe version 6, and was widely condemned at the time by the "purists" as it wasn't part of the "official" HTML 4 spec.

Just like the innerHTML attribute, MS implemented something that wasn't in the spec, got slagged to hell for it, and then had it copied by all the other browsers playing catchup.

At least this is a new kind of article, though, rather than the same old "HTML5 will replace Flash, Java, CPUs and give everyone blowjobs!" article that they usually have. And this is a serious concern, too: HTML already has an attack surface as big as all outdoors. I'm not saying that HTML is useless or should be replaced or anything, but security should be designed in from the beginning and the HTML5 spec is no exception.

I can't really complain about an open technology gaining momentum. So if it's those pointed haired bosses pushing for it, who cares if they fully get it.

Is a spec for this sort of thing ever really complete? Parts of it often are, and the early adopters taking advantage of those parts are the only reason this stuff moves forward. In fact, by using the technology early, you are helping to determine which features are most important and which ones need to be rethought.

Then I have to spend an hour explaining why it's not even currently usable for any serious enterprise application, and how the spec is not yet solidified.

Yeah, and then you make the off-handed observation that you can do all of this stuff in Flash, and that this sort of thing (video + audio) is easy and is Flash's bread-and-butter, and, oh yeah, it's also worked for the past decade, and then you get modded down into oblivion because nobody wants to hear the bitter truth when there's fresh Flavor-Ade to be d

I have a fairly recent machine, and that buckyball thing bogged my cpu too.
I googled around that day and found lots of people complaining. Aparently for Chrome it wasn't a problem, but Firefox users were hosed.
You'd think they would test it for multiple browsers at Google, before pushing it to one of the most used pages of the web...

I have to agree with your sentiment - I often feel that my hardware is playing catchup. Fortunately, I have just discovered a browser [wikipedia.org] that seems to cope well with all these new fancy gimmicks.

I'll echo the comment about getting a more modern machine. My 6 year old Opteron had no problems with dancing balls. I paused a second, looking for dancing boobs, but the computer didn't even blink. FFS, get a modern computer - today they run in multiple GIGAhertz. Ditch that 133 mhz machine. And, add some frigging MEMORY!! Yeah, there really is a use for more than 640k of memory. And, finally, upgrade to a real operating system and a real browser. Dump Windows 95 and IE4. FFS, get with the times!

Post that under your real user name, then. Until then *you* stfu. Any machine that got bogged down by that animation needs some serious tuneup work done. There's a 1.8ghz Skt754 Sempron here w/2GB ram running Vista that didn't get bogged down by it. So you're either full of shit or haven't bothered cleaning out the cruft in your comp in some time.

He has a point though, I personally love most of the new HTML5 features, but if every site starts piling on canvas animations, videos and audio it'll be annoying as hell.

I'd like to see this stuff become optional (on a browser basis and not site-by-site), perhaps don't start playing (or loading) a video/audio/canvas element until the user explicitly clicks play (with an option to pre-load but not autoplay for those with no bandwidth limits but who still don't want annoying unwanted video/sounds).

Unlike Flash, HTML5 animations are not really modular. It's trivial to disable all Flash and individually enable the one Flash applet on the page that you actually want (if there is one). With HTML5, all of the animations in a page are run from the same JavaScript execution context. Unless the author split the scripts up into different source files, it's very hard for the browser to untangle them. With Flash, every script associated with a canvas is bundled with that canvas and run in a separate context.

HTML5 is still under initial development. Flash has been around for years. Of course, Flash is the more mature technology. The point of HTML5 is to develop an open standard alternative with comparable functionality (including security). That isn't going to happen over night, and, as with any product, it will take some time to stabilize, mature, and become secure.

The reason HTML5 is important is the open standard aspect of it. Flash is ubiquitous on the web, but we are all at the mercy of a company a

.except when a Flash page behaves the same way. See Pandora for example: it's one big applet

Typically, only media players (such as Pandora) and corporate brochureware (such as Pop-Tarts.com) act that way. Other sites have accessibility concerns [wikipedia.org] that preclude putting the whole site in an SWF.

web security experts are warning that the sprawling new web standard may favor functionality over security, enabling a new generation of powerful web-based attacks.

MS will Embrace and Extend, but not Extinguish the potential for security holes.
Apple will probably do much the same, but might do the enhanced functionality bit also.
The BSD and *nix variants will only take on the functionality, most foolishly (using MBA "forced-upgrade-income" definition).

So are the majority of the HTML5 "demos" being touted as the future of the web.

I was exploring some "HTML5 demos" the other day... bunches of timed PNGs on layers, controlled by js. The only HTML5 tag in most of them was an &ltaudio> tag, and amusingly enough they had fallback tags to the <object> we all know and love.

Presumably the world will be a much better place when we have separate audio and video tags as opposed to that outmoded, messy object tag that does EXACTLY THE SAME THING. Ah, pr

When HTML spec is extended that obviously increases the attack surface since popular browsers will have to support it. But in time it may replace a number of other technologies (Flash comes to mind), that -combined- may have a larger attack surface. And since displaying HTML is the core function of a browser, implementations are likely to be pretty solid compared to some add-ons.

So you'd have to look forward, and compare [average setup now] with [average setup in XX years from now]. If that comparison turns out positive, HTML5 is a move in the right direction.

How are the "concerns" over HTML5 any different than any other platform? Flash, ASP, javascript, etc have all had and continue to have vulnerabilities. The only way to stay 100% safe is to stay off the internet. Did anyone expect people who make their living by addressing both real and imagined security risks to not comment with an angle that puffed up their importance in the net ecosystem?

How are the "concerns" over HTML5 any different than any other platform? Flash, ASP, javascript, etc have all had and continue to have vulnerabilities. The only way to stay 100% safe is to stay off the internet. Did anyone expect people who make their living by addressing both real and imagined security risks to not comment with an angle that puffed up their importance in the net ecosystem?

Actually this is a very very important point. You can't compare the potential security risk betwenn HTML5 and HTML4. You have to compare it with HTML4 plus all the plugins it can potentially replace (like, say, Flash).

My biggest concern, as others have pointed out, are using things like canvas elements over top of content to display ads and whatnot. But then, really, it will just be like the new features of any previous HTML/Javascript spec. There will be a lot of annoyances and some features used in re

Is that the more core to the spec it is, the less you can do to mitigate it. With Flash there's a simple solution: Block it. You can use a plugin like Flashblock that allows you to run it only as needed, you can set it to only run on some sites, or you can shut it off entirely. It is easy to restrict access to it when ti isn't needed and thus increase security.

I seem to remember a while back some assholes suggesting that content and presentation should (sorry, they insisted MUST) be separated. While some of us fought it tooth and nail, the masses of buzzword obsessed PHBs won, with their demands that every page be W3C compliant, meaning web designers would strip 99% of the markup out to a separate CSS file to hide it where the validator wouldn't find it.

So now we have a generation of web designers (the last 5 years batches, I'd guess

The article points out no specific flaws. It just says that HTML is growing, therefore the chance of a hole (the "attack surface") also is growing.

Choose your poison. The same can be said about writing an app for an operating system. "Windows/Mac OS/Linux has an enormous amount of functionality. Therefore I'm concerned that there could be a lot of vulnerabilities."

Yes.

But the growth of the browser will not simply add to the overall size of the computer. Because of a big browser, you may have a smaller operating system. This is the idea behind Chrome OS.

It is not a perfectly equal replacement. If the browser grows 15 MB, that does not mean the operating system will shrink 15 MB. But one thing that is better about putting a feature in the browser is that more eyes are on it. There will be a lot more users who try to write a program in JavaScript than against even the Windows, even the iPhone, API. HTML 5 will bring about a lot more software developers and a lot more software development.

So you really need to buy their security solutions! NOW! Meanwhile, Goodyear tires said to really safe on the road (and to keep your CHILDREN! safe) you should get new tires every 5000 miles, and the Head & Shoulders folks claim washing your hair three times a day will avoid a stinky head. And the government said they taking blood and tissue samples at the airport will protect us from engineer^H^H^H^H^H^H terrorists ever more so.

We should therefore not take it face value, but dismissing it entirely because it comes from a security firm is just as stupid. This is Slashdot, lets discuss this on technical merit of the arguments, not on some notion of politics.

The Modern Techie will now by definition reject all new technology no matter what advancements are in it. While adopting any new technology will have tradeoffs the modern will hold on to whatever tradeoff negative effect and call it a horrible plan. Any new tech is now a threat to their way of life and no longer a new interesting field to study...

Let me start out by reminding everyone that when Netscape came up with Cookies, everyone thought they were fine. Now, thanks to 1 pixel images and other tracking methods, cookies are the key to online companies aggregating bits of "anonymous" data into an identifiable profile of a person. Does Google know only as much about you as you would like? In fact, they know far more about you than you would expect, even if you don't use GMail.

The single biggest shot across the bow to privacy in HTML5 is the ping attribute [w3.org]. It may seem innocuous at first glance, but according to MozillaZine [mozillazine.org], it sends an HTTP POST request to each url. Why not GET instead?

This will allow Google, Alexa, FaceBook, or any "partner" to track users, if a site implements ping, easier than ever before. Some say trackers will migrate away from redirect URLs, but I say they will do both, if only to sop up every last piece of data they can.

I can see ping being used as a stealth DDOS attack, if enough malicious links can be distributed. Some content provider web API gets hacked, thousands of sites load up links (via AJAX) that ping slashdot.org, and Slashdot goes down. Will ping implementations be smart enough to reduce the list of URLs down to unique values? How many times does ping="slashdot.org slashdot.org/foo slashdot.org/comments.pl slashdot.org/article.pl" actually hit the poor, unsuspecting server? There's no apparent limit to how many URLs can be stuffed into a single ping, either.

I'm sure the black hats will think of other ways to exploit this. I agree that tools are neither evil nor good, but this is ripe for unintended consequences.

It looks like that option was included with the intention the browsers implementing the feature would have a method to disable it's usage. I'm guessing if it gets crazy then major players will ship with it disabled, or maybe include some sort of same domain policy for pings (ping domain has to match referrer or href). I'm not too scared, and this would work much better than JS versions of the same thing.

The single biggest shot across the bow to privacy in HTML5 is the ping attribute [w3.org]. It may seem innocuous at first glance, but according to MozillaZine [mozillazine.org], it sends an HTTP POST request to each url. Why not GET instead?

Why does it matter if its a GET or POST? I mean, why would you want GET? More chances that the URL will contain sensitive data that gets logged in more places. My webservers log GETs with all their encoded data by default, but the only thing I know about posts in the

I also don't get the hangup with ping using POST. It's just a word that shows up in the HTTP dialog. According to HTTP spec, POST would make more sense for this, since you're essentially publishing tracking information to a site.

Something doesn't have to be Turing Complete to be a danger. True, not being TC may reduce the options available to hackers, but does not eliminate them. Even some images and documents were able to exploit bugs by taking advantage of a hole in some graphics renderers (browsers) whereby certain pixel combinations triggered a bug that allowed the rest of the image's bytes to "flow" into memory, where the render engine starts executing them as if they were machine code. It's similar to a buffer-overflow exploi

Browsers, IM tools, Skype, and other such tools should ALWAYS run under very restrictive permission levels. I don't need my browser writing anywhere on my computer except for maybe one folder (usually). I don't need it changing the registry. I don't need it to be able to unsandboxed execute code.

So keep it isolated using permissions. That is the the last line of defense against malicious sites.

I'm not an expert of any kind, but my general concern with the web has been growing as static documents have become applications. It's the same reason I don't like the idea of javascript in PDFs. I like the idea of a static document that doesn't do anything, but is merely viewable. Yes, yes, I know that it's possible for malformed documents to trigger exploits in the document viewer, but that seems like it should be more rare and easy to protect against.

At you upgrade HTML to make web applications more and more powerful, it seems likely to me (from a non-expert standpoint) that you're increasing the variety of security concerns we need to worry about. There's a part of me that wishes we had two different things: a web browser that allowed for safe passive viewing of relatively static content, and an application that supported an application framework similar to current web applications.

I'm a security expert of some kind, but you are of course spot on. The more flexibility you have, the bigger the attack service. And things like a scripting language may add a lot of flexibility. Of course, there are ways to mitigate the risk. Having sites run in there own sandbox (including the scripts) for instance. Or having plugins run in their own process, so they don't have direct access to browser data.

The current set of web-browsers and web standards do make a pretty brittle system. I've always wond

the new specification will greatly increase the 'attack surface' of HTML -- providing more avenues by which malicious code can be delivered through the web. 'HTML5 has an enormous amount of functionality. The (specification) is just huge

If HTML was an API, not only security would be handled much more easily, but the functionality could be enhanced and extended much faster...

The point that security researchers have been trying (for years) to get across to developers and companies alike is that ALL software/protocols/standards/whatever should be developed with security in mind from the beginning. Granted, even with secure coding practices and rigorous application security testing, there will always be some vulnerability that gets overlooked by the developer or discovered by an attacker. The thing is that most companies tend to put functionality and featur

Unfortunately, most people want feature over security. Many people don't even think about security for themselves and only complains when it bites them in the ass. "What do you mean I shouldn't write my PIN on my debit card? You should just have made your system more secure!"

if an idiot developer wants to make an application in an insecure way, the platform can not stop them.

I find your statement ambiguous. Did you mean that in the sense of the web browser as an application and a device's operating system as a platform? Or did you mean it in the case of a web app as an application and the web browser as a platform? The article, as I understand it, is about the latter sense.

if the platform implements something insecurely, then relying on that implementation is not building a secure application... it doesn't mean that a secure application can not be built on that platform.

As far as I know, formal verification [wikipedia.org] of the security of a computer program as large as a platform is nowhere near prime time. This means you can't be sure that any platform implements every necessary feature 100% securely, and relying on any implementation is not building a secure application, unless perhaps your application requires so few platform features that it would work in HTML 1.0.

You misread the summary; the article is not about an idiot developer building an insecure application that compromises the developer's server's security. It's about malicious developers building seemingly benign websites that compromise a user's home computer

Effectively there is a need for web browsers to isolate different parts of the page from each other.

A look into what Netscape had earlier with "Data Tainting" and also the "Same Origin Policy" should be considered, which would limit the interaction between content with different origin.

Another catch is the thread based model in applications (mostly a problem for C and C++ applications) instead of a process based model where interprocess communication has to be defined stricter. Any coding mistake in a threa

And yet again, you still miss the point. The article states that the scope of HTML5 is so huge, that it will be difficult for browser developers to fully secure their browser against exploits. The scope of HTML5 makes securing the browsers more difficult, and as a counter point, they compare it against HTML4, which was far simpler, but exploits are still being found to this day.

This in no way suggests that HTML5 sucks or is evil, it is just something that people need to consider.

1. System has ability to delete your files.
2. System loads file from the Internet. File from the Internet contains
instructions.
3. System is designed to accept delete() instructions
from users, but not from files downloaded from the Internet.

My idea for quite some time is that in the long run, all file
formats become programming languages. A web page should have always
been regarded as an application that is sandboxed by the browser, even
before we started building apps with

I was just using file delete as an example of
something that a system must be able to do; but that
you don't want being done at the request of an
arbitrary application.

Perhaps window creation
would have been a better example. I don't know how HTML5
is put together. I would hope that creation of new
windows outside the frame of the existing browser
(ie, popups) would be easy enough to trap in the browser
and subject to permissions.

A browser has to be capable of creating popups at
the request of the user (o