From 11b5dfb8e7b407c5050a83b1b7f2f1cdf28fe914 Mon Sep 17 00:00:00 2001 From: RafaelGSS Date: Fri, 28 Oct 2022 10:36:05 -0300 Subject: [PATCH] doc: add Node.js Threat Model Co-authored-by: Michael Dawson Co-authored-by: Facundo Tuesca Co-authored-by: Ulises Gascon Co-authored-by: Thomas Gentilhomme --- SECURITY.md | 80 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 80 insertions(+) diff --git a/SECURITY.md b/SECURITY.md index 57943ce969e20b..402a4ef267b7e7 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -53,6 +53,86 @@ Here is the security disclosure policy for Node.js the release process above to ensure that the disclosure is handled in a consistent manner. +## What does Node.js trust/not trust + +Being able to cause a negative outcome in a way that requires control of the +elements that are trusted by Node.js is not considered a vulnerability in +Node.js. + +Being able to cause the following through control of the elements that Node.js +does not trust is considered a vulnerability: + +* Disclosure or loss of integrity or confidentiality of data protected through + the correct use of Node.js APIs. +* The unavailability of the runtime, including the unbounded degradation of its + performance. + +If Node.js loads configuration files or runs code by default (without a +specific request from the user), and this is not documented, it is considered a +vulnerability. +Vulnerabilities related to this case may be fixed by a documentation update. + +**Node.js does NOT trust** + +1. The data from network connections that are created through the use of Node.js + APIs and which is transformed/validated by Node.js before being passed to the + application. This includes: + * HTTP APIs (all flavors) client and server APIs. + * DNS APIs. +2. Consumers of data protected through the use of Node.js APIs (for example + people who have access to data encrypted through the Node.js crypto apis). +3. The file content or other IO that is opened for reading or writing by the use + of Node.js APIs (ex: stdin, stdout, stderr). In other words, Node.js doesn’t + interpret buffers unless explicitly set by the user. + +**Node.js trusts everything else**. As some examples this includes: + +1. The developers and infrastructure that runs it. +2. The operating system that Node.js is running under and its configuration, + along with anything under control of the operating system. +3. The code it is asked to run including JavaScript and native code, even if + said code is dynamically loaded. The code run inherits all the privileges of + the execution user. +4. Inputs provided to it by the code it is asked to run, as it is the + responsibility of the application to perform the required input validations. +5. Any connection used for inspector (debugger protocol) regardless of being + opened by command line options or Node.js APIs, and regardless of the remote + end being on the local machine or remote. +6. The file system when requiring a module. + See . + +Any unexpected behavior from the data manipulation from Node.js Internal +functions are considered a vulnerability. + +In addition to addressing vulnerabilities based on the above, the project works +to avoid APIs and internal implementations that make it “easy” for application +code to use the APIs incorrectly in a way that results in vulnerabilities within +the application code itself. While we don’t consider those vulnerabilities in +Node.js itself and will not necessarily issue a CVE we do want them to be +reported privately to Node.js first. +We often choose to work to improve our APIs based on those reports and issue +fixes either in regular or security releases depending on how much of a risk to +the community they pose. + +### Some examples of applying this thread model include: + +#### Malicious Third-Party Modules (CWE-1357) + +* Code is trusted by Node.js, therefore any scenario that requires a malicious + third-party module cannot result in a vulnerability in Node.js. + +#### Prototype Pollution Attacks (CWE-1321) + +* Node.js trusts the inputs provided to it by application code. + It is up to the application to sanitize appropriately, therefore any scenario + that requires control over user input is not considered a vulnerability. + +#### Uncontrolled Search Path Element (CWE-427) + +* Node.js trusts the file system in the environment accessible to it. + Therefore, it is not a vulnerability if it accesses/loads files from any path + that is accessible to it. + ## Receiving security updates Security notifications will be distributed via the following methods.