Oops! HTML5 Does It Again

#HTML5 #infosec A multitude of security-related solutions rely upon the ability to extract and examine mime-objects from web-content. HTML5 may significantly impair their ability to do so.

The trade off between security and performance has long been a known issue across IT organizations. One of the first things to go when performance is unacceptable is a security solution. This isn’t just an IT phenomenon either; consider how many of us have disabled endpoint security solutions like anti-virus scanners to improve performance?

Our refusal to be slowed down by what may seem to some as extraneous security is what eventually led IT security professionals to revise their strategies and enforce such scans on inbound content in the network. Network-attached security scanning solutions have long been a staple of inbound e-mail and has found increasing use as a means to scan inbound web-content, as well, as an attempt to eliminate potential malware from having access to the corporate network.

IT Organizations That Trade Security for Performance Deserve Neither

A new [at the time of publication, July 2011] survey of 487 IT professionals that was conducted by Crossbeam, a provider of high-performance security gateways, finds 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.

HTML and soon, if we believe the predictions HTML5, is the lingua franca of Internet communication. Oh, applications may speak JSON under the covers, but in the end it’s just data to be displayed to the user which means HTML(5).

What does that mean for anti-virus and malware web scanners? Well, if one of the features of HTML5 being leveraged is WebSockets, a lot. Otherwise, not much. At least not yet.

You see, WebSockets accidentally trades performance for security.

OOPS

One of the things WebSockets does to dramatically improve performance is eliminate all those pesky HTTP headers. 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. Bits and bytes are bytes and bytes, and while you could certainly infer the type based on format “tells” within the actual data, how would you really know? Sure, the HTTP headers could by lying, but generally speaking the application serving the object 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.

But couldn’t you just use the URL? Nope – there is no URL associated with objects via a WebSocket. There is also no standard application information that next-generation firewalls can use to differentiate the content; developers are free to innovate and create their own formats and micro-formats, and undoubtedly will. And trying to prevent its use is nigh-unto impossible because of the way in which the upgrade handshake is performed – it’s all over HTTP, and stays HTTP. One minute the session is talking understandable HTTP, the next they’re whispering in Lakota, a traditionally oral-only language which neatly illustrates the overarching point of this post thus far: 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.

WEDGE NETWORKS

Wedge Networks, whose name you may never before heard even though you might have had content scrubbed by their devices and not known it, has a solution to the problem of disaggregating web objects without requiring specific identification by HTTP headers, thus solving this problem and several other similar ones where protocols lack the means to definitively identify specific content by type.

WedgeOS - Network Data Processor Architecture

The WedgeOS Network Data Processor ("NDP") is the proprietary architecture that allows content inspection at Gigabit speeds without impacting network performance. The WedgeOS NDP architecture revolutionized Web Security Appliances with the introduction of BeSecure. BeSecure is capable of intercepting and actively scanning all internet traffic for malicious content as it enters the network.

What they meant to say was “we do deep content inspection on streaming traffic and are able to accurately identify – and subsequently extract – MIME objects at line rate and then scan them for bad stuff you don’t want on your network.” Content comes into their device (and it’s off-the shelf hardware, I’m told), MIME objects are disaggregated regardless of transport or application protocol, shoved down a high-speed internal bus into which are plugged a variety of security scanning functions, and then shoved back out the other side, assuming all was well. Policies enable the ability to determine exactly what happens if there are anomalies or malicious code discovered.

Wedge Networks has partnered with a number of well-known and industry leading security scanning solutions and brought them together into a single device. Applying the old “crack the packet only once” doctrine, the device is able to perform its scans as fast as objects can traverse its internal bus.

The devices deploys in either proxy or transparent mode, with the latter being most popular simply due to the mitigation of disruption that can come with inserting a proxy-based solution into an established network.

Let’s assume for a moment that a Wedge Networks device really does accomplish all this – at line rate. I can’t know, I don’t evaluate products in lab environments any more, so I can take their word for it. But let’s assume it does. That opens a wide variety of possibilities – both inbound and outbound – for protecting web applications and customers alike, and not just for HTML5.

Assuming no degradation of overall performance, the ability to detect and prevent delivery of malware that may have been surgically inserted into your database or CMS via XSS or SQLi would be a boon, if only to let you know it happened much sooner and provide the time necessary to redress the infection. Nearly every rational organization scans inbound e-mail for potential risks, but very few (if any) scan outbound. We all know why – the belief that performance is more important than security, especially when consumer dollars are on the line. If Wedge Networks can do as it promises and not impede performance while still providing a valuable security service, well, that might be something to think about.