The recently published article by eSecurity Planet, HTML5 WebSockets Identified As Security Risk raises a few interesting questions.
“WebSockets can be used for lots of things, but they shouldn’t be used for all items on a web page.”
The post makes a good point about using the WebSocket standard for what it’s good at, rather than leveraging it for everything. HTTP is the best transport mechanism for static Web resources (HTML, CSS, JavaScript, images, etc.), providing very efficient caching mechanisms. WebSocket, on the other hand, is ideal for dynamic and transactional data that feeds into your applications.
“We think that user capacity may be an issue with WebSockets if it’s not implemented in the right way”
The current trend of Web applications creates more and more demand for rich, engaging, and interactive user experiences. Solutions based on HTTP (Ajax, Comet) are costly to implement and often run into scalability and performance issues for large scale deployments. The WebSocket standard was created to address the limitations inherent in HTTP for these kinds of applications; simply because HTTP wasn’t designed for such use cases. Therefore, WebSocket architectures will provide more capacity, better scalability, and performance, than what can be achieved using existing techniques. Of course, badly implemented solutions cannot live up to these expectations — WebSocket on its own doesn’t give it for free — but it is definitely possible with SEDA-like architectures (Staged Event Driven Architecture), such as non-blocking I/O (NIO). This is proven by some implementations out there, supported by more and more scalability and performance benchmarks.
“So if a server is not accepting connections fast enough, then you shouldn’t try and open a new connection before the previous one was accepted,” Shekyan said. “That would prevent DoS (Denial of Service) attacks.”
The DoS concerns against WebSocket servers may seem valid at first sight, but given that the WebSocket handshake starts off with an HTTP request, the existing HTTP/IP measures already in place will be able to cut off these connection requests and stop them from ever reaching the intended WebSocket server in the first place. And even if the DoS requests reach the WebSocket server, WebSocket server vendors can and should implement login modules and authorization mechanisms to address it. Kaazing WebSocket Gateway, for example, offers multiple security layers to protect against different types of attack vectors.
In real-life deployments, intermediaries can sometimes interfere with WebSocket communication. The good news is that proven techniques from the HTTP world, such as TLS/SSL, can be applied to WebSockets as well, preventing intermediaries from inspecting the encrypted traffic. Needless to say, it’s hard to disagree with the article’s point:
“[Firewall and IPS network security device] vendors should really start at looking at handling the WebSockets protocol.”
In the last few years the W3C and IETF bodies have invested tremendous effort into WebSocket security, ensuring that it doesn’t expose vulnerabilities. If a standard is not implemented correctly, there’s of course a chance that the implementation has vulnerabilities. However, that doesn’t make the standard insecure, it’s just that implementation. We, at Kaazing take security extremely seriously and our products have gone through rigorous testing at some of the world’s largest financial institutions and 3rd party security testing companies, such as Veracode.
If interested in further details on WebSocket security in general, check out the HTML5 WebSocket Security is Strong article for security measures any WebSocket deployment can employ today. For details on more enterprise strength security, you can read the Kaazing WebSocket Gateway Security is Strong post.