Engine.IO-client versions 1.3.0 and 1.3.1 represent incremental updates to a crucial library for real-time communication, designed for building robust and scalable applications. Both versions share a core set of dependencies, including WebSocket support via 'ws', debugging tools via 'debug', and various utilities for parsing and managing data like 'parseqs', 'parseuri', and 'parsejson'. They also rely on 'xmlhttprequest' for cross-origin requests and 'engine.io-parser' for handling the engine.io protocol. Development dependencies such as 'mocha' for testing, 'express' for creating server environments, and 'browserify' for bundling indicate a focus on comprehensive testing and broad compatibility.
The key difference lies in their release dates, with version 1.3.1 released approximately a week after 1.3.0. This suggests that 1.3.1 likely includes bug fixes, minor improvements, or security patches addressing issues discovered in the initial 1.3.0 release. For developers selecting a version, 1.3.1 is generally recommended due to the higher likelihood of stability and resolved issues. However, reviewing the specific changelog or commit history between the two versions is crucial to understand the exact changes and ensure compatibility with existing code. While both versions provide a solid foundation for real-time client-server communication, prioritizing the newer release offers increased confidence in its reliability and security.
All the vulnerabilities related to the version 1.3.1 of the package
Insecure Defaults Allow MITM Over TLS in engine.io-client
Affected versions of engine.io-client do not verify certificates by default, and as such may be vulnerable to Man-in-the-Middle attacks.
The vulnerability is related to the way that node.js handles the rejectUnauthorized setting. If the value is something that evaluates to false, such as undefined or null, certificate verification will be disabled.
Update to version 1.6.9 or later.
If you are unable to upgrade, ensure all calls to socket.io to have a rejectedUnauthorized: true flag.
Remote Memory Disclosure in ws
Versions of ws prior to 1.0.1 are affected by a remote memory disclosure vulnerability.
In certain rare circumstances, applications which allow users to control the arguments of a client.ping() call will cause ws to send the contents of an allocated but non-zero-filled buffer to the server. This may disclose sensitive information that still exists in memory after previous use of the memory for other tasks.
var ws = require('ws')
var server = new ws.Server({ port: 9000 })
var client = new ws('ws://localhost:9000')
client.on('open', function () {
console.log('open')
client.ping(50) // this sends a non-zeroed buffer of 50 bytes
client.on('pong', function (data) {
console.log('got pong')
console.log(data) // Data from the client.
})
})
Update to version 1.0.1 or greater.
DoS due to excessively large websocket message in ws
Affected versions of ws do not appropriately limit the size of incoming websocket payloads, which may result in a denial of service condition when the node process crashes after receiving a large payload.
Update to version 1.1.1 or later.
Alternatively, set the maxpayload option for the ws server to a value smaller than 256MB.
Denial of Service in ws
Affected versions of ws can crash when a specially crafted Sec-WebSocket-Extensions header containing Object.prototype property names as extension or parameter names is sent.
const WebSocket = require('ws');
const net = require('net');
const wss = new WebSocket.Server({ port: 3000 }, function () {
const payload = 'constructor'; // or ',;constructor'
const request = [
'GET / HTTP/1.1',
'Connection: Upgrade',
'Sec-WebSocket-Key: test',
'Sec-WebSocket-Version: 8',
`Sec-WebSocket-Extensions: ${payload}`,
'Upgrade: websocket',
'\r\n'
].join('\r\n');
const socket = net.connect(3000, function () {
socket.resume();
socket.write(request);
});
});
Update to version 3.3.1 or later.
debug Inefficient Regular Expression Complexity vulnerability
A vulnerability classified as problematic has been found in debug-js debug up to 3.0.x. This affects the function useColors of the file src/node.js. The manipulation of the argument str leads to inefficient regular expression complexity. Upgrading to version 3.1.0 is able to address this issue. The name of the patch is c38a0166c266a679c8de012d4eaccec3f944e685. It is recommended to upgrade the affected component. The identifier VDB-217665 was assigned to this vulnerability. The patch has been backported to the 2.6.x branch in version 2.6.9.
Regular Expression Denial of Service in debug
Affected versions of debug are vulnerable to regular expression denial of service when untrusted user input is passed into the o formatter.
As it takes 50,000 characters to block the event loop for 2 seconds, this issue is a low severity issue.
This was later re-introduced in version v3.2.0, and then repatched in versions 3.2.7 and 4.3.1.
Version 2.x.x: Update to version 2.6.9 or later. Version 3.1.x: Update to version 3.1.0 or later. Version 3.2.x: Update to version 3.2.7 or later. Version 4.x.x: Update to version 4.3.1 or later.
parse-uri Regular expression Denial of Service (ReDoS)
An issue in parse-uri v1.0.9 allows attackers to cause a Regular expression Denial of Service (ReDoS) via a crafted URL.
async function exploit() {
const parseuri = require("parse-uri");
// This input is designed to cause excessive backtracking in the regex
const craftedInput = 'http://example.com/' + 'a'.repeat(30000) + '?key=value';
const result = await parseuri(craftedInput);
}
await exploit();
Regular Expression Denial of Service in parsejson
Affected versions of parsejson are vulnerable to a regular expression denial of service when parsing untrusted user input.
The parsejson package has not been functionally updated since it was initially released.
Additionally, it provides functionality which is natively included in Node.js, and therefore the native JSON.parse() should be used, for both performance and security reasons.