Loader-utils is a vital package for webpack loader development, offering utilities to simplify common tasks. Comparing version 1.1.0 with the preceding stable version, 1.0.4, reveals several key differences beneficial for developers. Both iterations share core dependencies like json5, useful for parsing JSON5, big.js for arbitrary-precision decimal arithmetic, and emojis-list providing a list of emojis. They also maintain consistent development dependencies including testing frameworks (mocha, istanbul), linting tools (eslint, eslint-plugin-node) and code coverage reporting (coveralls).
The primary distinction lies in the introduction of standard-version as a devDependency in version 1.1.0. This suggests an enhanced commitment to standardized versioning and release management, automatically managing CHANGELOG.md generation based on commit history. This improvement, while not directly impacting runtime behavior, streamlines the development workflow and ensures consistent and automated release cycles. Furthermore the release date of version 1.1.0 is two days after version 1.0.4, indicating a frequent release cycle.
Developers choosing loader-utils gain access to a robust set of tools addressing common loader needs. The library simplifies tasks such as parsing query parameters for loaders, escaping strings for use in JavaScript and generating unique names based on content. Using the library, developers can boost their productivity by sidestepping redundant code and ensure optimal compatibility with the webpack ecosystem. The adoption of standard-version in version 1.1.0 signals a dedication to maintainability and predictable releases, making it a reliable choice for building high-quality webpack loaders.
All the vulnerabilities related to the version 1.1.0 of the package
Prototype pollution in webpack loader-utils
Prototype pollution vulnerability in function parseQuery in parseQuery.js in webpack loader-utils prior to version 2.0.3 via the name variable in parseQuery.js.
loader-utils is vulnerable to Regular Expression Denial of Service (ReDoS) via url variable
A Regular expression denial of service (ReDoS) flaw was found in Function interpolateName in interpolateName.js in webpack loader-utils 2.0.0 via the url variable in interpolateName.js. A badly or maliciously formed string could be used to send crafted requests that cause a system to crash or take a disproportional amount of time to process. This issue has been patched in versions 1.4.2, 2.0.4 and 3.2.1.
loader-utils is vulnerable to Regular Expression Denial of Service (ReDoS)
A regular expression denial of service (ReDoS) flaw was found in Function interpolateName in interpolateName.js in webpack loader-utils via the resourcePath variable in interpolateName.js. A badly or maliciously formed string could be used to send crafted requests that cause a system to crash or take a disproportional amount of time to process. This issue has been patched in versions 1.4.2, 2.0.4 and 3.2.1.
Prototype Pollution in JSON5 via Parse Method
The parse method of the JSON5 library before and including version 2.2.1 does not restrict parsing of keys named __proto__, allowing specially crafted strings to pollute the prototype of the resulting object.
This vulnerability pollutes the prototype of the object returned by JSON5.parse and not the global Object prototype, which is the commonly understood definition of Prototype Pollution. However, polluting the prototype of a single object can have significant security impact for an application if the object is later used in trusted operations.
This vulnerability could allow an attacker to set arbitrary and unexpected keys on the object returned from JSON5.parse. The actual impact will depend on how applications utilize the returned object and how they filter unwanted keys, but could include denial of service, cross-site scripting, elevation of privilege, and in extreme cases, remote code execution.
This vulnerability is patched in json5 v2.2.2 and later. A patch has also been backported for json5 v1 in versions v1.0.2 and later.
Suppose a developer wants to allow users and admins to perform some risky operation, but they want to restrict what non-admins can do. To accomplish this, they accept a JSON blob from the user, parse it using JSON5.parse, confirm that the provided data does not set some sensitive keys, and then performs the risky operation using the validated data:
const JSON5 = require('json5');
const doSomethingDangerous = (props) => {
if (props.isAdmin) {
console.log('Doing dangerous thing as admin.');
} else {
console.log('Doing dangerous thing as user.');
}
};
const secCheckKeysSet = (obj, searchKeys) => {
let searchKeyFound = false;
Object.keys(obj).forEach((key) => {
if (searchKeys.indexOf(key) > -1) {
searchKeyFound = true;
}
});
return searchKeyFound;
};
const props = JSON5.parse('{"foo": "bar"}');
if (!secCheckKeysSet(props, ['isAdmin', 'isMod'])) {
doSomethingDangerous(props); // "Doing dangerous thing as user."
} else {
throw new Error('Forbidden...');
}
If the user attempts to set the isAdmin key, their request will be rejected:
const props = JSON5.parse('{"foo": "bar", "isAdmin": true}');
if (!secCheckKeysSet(props, ['isAdmin', 'isMod'])) {
doSomethingDangerous(props);
} else {
throw new Error('Forbidden...'); // Error: Forbidden...
}
However, users can instead set the __proto__ key to {"isAdmin": true}. JSON5 will parse this key and will set the isAdmin key on the prototype of the returned object, allowing the user to bypass the security check and run their request as an admin:
const props = JSON5.parse('{"foo": "bar", "__proto__": {"isAdmin": true}}');
if (!secCheckKeysSet(props, ['isAdmin', 'isMod'])) {
doSomethingDangerous(props); // "Doing dangerous thing as admin."
} else {
throw new Error('Forbidden...');
}