BT

Security vulnerabilities with HTML5 (WebSockets)?

by Mark Little on Mar 26, 2012 |

Despite not yet being an official standard, HTML5 has grown rapidly in terms of adoption and influence over the past few years. Whether it's the Web, mobile, or even SOA, everything seems to have a strategy for integrating with HTML5. However, HTML5 is more than just an update to the original markup language, as it encompasses other aspects such as JavaScript and WebSockets. We have heard a lot about WebSockets recently, including introductions to the technology and whether or not it has any impact on REST. However, recently Lori Macvittie makes the argument that WebSockets may result in a less secure Web as people trade off security for performance. As she points out by referring to a report from 2011, many people are used to doing that already and a survey found that ...

... while 91 percent of the respondents were not only making tradeoffs between security and performance, a full 81 percent were actually disabling security features.

But what has this to do with WebSockets? Well according to Lori, because WebSockets removes HTTP headers amongst other things this opens up vulnerabilities that existing virus and malware checkers require:

You know, things like CONTENT-TYPE. You know, the header that tells the endpoint what kind of content is being transferred, such as text/html and video/avi. One of the things anti-virus and malware scanning solutions are very good at is detecting anomalies in specific types of content. The problem is that without a MIME type, the ability to correctly identify a given object gets a bit iffy.

Of course relying on HTTP headers is no guarantee against malicious content, but as Lori mentions:

[...] generally speaking the application serving the [data] doesn’t lie about the type of data and it is a rare vulnerability that attempts to manipulate that value. After all, you want a malicious payload delivered via a specific medium, because that’s the cornerstone upon which many exploits are based – execution of a specific operation against a specific manipulated payload. That means you really need the endpoint to believe the content is of the type it thinks it is.

And Lori goes on to say that the extensibility aspect of WebSockets (subprotocol extension), which allows for additional wire formats and protocols to be defined, presents further problems that prevents firewalls from alleviating the problem:

[...] there’s no way to confidently know what is being passed over a WebSocket unless you “speak” the language used, which you may or may not have access to. The result of all this confusion is that security software designed to scan for specific signatures or anomalies within specific types of content can’t. They can’t extract the object flowing through a WebSocket because there’s no indication of where it begins or ends, or even what it is. The loss of HTTP headers that indicate not only type but length is problematic for any software – or hardware for that matter – that uses the information contained within to extract and process the data.

There have been reports of security flaws with WebSocket implementations and protocol before, just as there have been with other Web protocols through the years. And of course security in distributed systems predates HTML by several decades, especially over binary protocols. So it is possible to secure binary systems, but Lori's point seems to be that whilst we appear to be driving headlong towards a higher performing Web, we shouldn't ignore the facts that the vast majority of the Web infrastructure is based on HTTP and removing or replacing it should not be taken lightly, as things will invariably break or even worse. Since adopting WebSockets seems inevitable, is it time to step back and consider what a world based on it should look like, at least as far as security is concerned?

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

WebSocket Security is Strong by Peter Moskovits

I couldn't agree more that security is (as it should be) a critical concern for every enterprise.

It is, however, surprising to see the amount of fud spread about WebSockets. Enough to mention the "reports of security flaws" paragraph that brings up the proxy poisoning issue that was documented at the end of 2010. As a result of that paper, unlike Flash and Java that are still exposed to the same vulnerability, the WebSocket protocol did address the problem, and the RFC doesn't have this (or any other known) issue any more.

Facts over fud - against fear:
Here are two technical articles that everybody concerned about WebSocket security should read.
The first one is a general overview of WebSocket security - HTML5 WebSocket Security is Strong: blog.kaazing.com/2012/02/28/html5-websocket-sec...
The second one covers what a WebSocket server implementation, Kaazing, offers in addition [disclosure: I work for Kaazing]: Kaazing WebSocket Gateway Security is Strong: blog.kaazing.com/2012/02/29/kaazing-websocket-g...

Or, perhaps we should take another perspective? by Dejan Lekic

Just because antivirus software relies on headers does not mean WebSockets are less secure. - It is what security protocol(s) you apply on top of WebSockets that really matter.

The problem isn't WebSockets by Nathan Evans

... it's the archaic security systems.

You can often thwart such systems today just by using HTTPS, as they often badly configured anyway. A properly configured security system of this type would need to block HTTPS traffic, and basically everything else it can't understand. So the natural progression will be that WebSockets, particularly when operating in "binary" packet mode, get blocked by these security systems as well.

Re: WebSocket Security is Strong by Cameron Purdy

Peter,

It is, however, surprising to see the amount of fud spread about WebSockets. Enough to mention the "reports of security flaws" paragraph that brings up the proxy poisoning issue that was documented at the end of 2010. As a result of that paper, unlike Flash and Java that are still exposed to the same vulnerability ..


I'm not sure how you are clarifying anything, since instead of simply addressing the concerns, you started lobbing rocks at Java (the language? the libraries? the JVM? who knows?). When you talk about "proxy poisoning", are you referring to DNS-based attacks (which is how that term is normally used), or something else (post a link)?

Secondly, I don't personally see a lot of FUD against WebSockets. To the contrary, we have lots of requests to add support for HTML5 and WebSockets to Java EE, for example.

Peace,

Cameron Purdy | Oracle

Ugh by Cameron Purdy

You know, things like CONTENT-TYPE. You know, the header that tells the endpoint what kind of content is being transferred, such as text/html and video/avi. One of the things anti-virus and malware scanning solutions are very good at is detecting anomalies in specific types of content. The problem is that without a MIME type, the ability to correctly identify a given object gets a bit iffy.


Seriously? This is a technical argument? Support for anti-virus software? I've yet to find any anti-virus solutions that do anything to prevent viruses; they are all *@!?, and as medicine, they are worse than the disease.

Peace,

Cameron Purdy | Oracle

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT