@@ -55,6 +55,132 @@ Here is the security disclosure policy for Node.js |
55 | 55 | the release process above to ensure that the disclosure is handled in a |
56 | 56 | consistent manner. |
57 | 57 |
|
| 58 | +## The Node.js threat model |
| 59 | + |
| 60 | +In the Node.js threat model, there are trusted elements such as the |
| 61 | +underlying operating system. Vulnerabilities that require the compromise |
| 62 | +of these trusted elements are outside the scope of the Node.js threat |
| 63 | +model. |
| 64 | + |
| 65 | +For a vulnerability to be eligible for a bug bounty, it must be a |
| 66 | +vulnerability in the context of the Node.js threat model. In other |
| 67 | +words, it cannot assume that a trusted element (such as the operating |
| 68 | +system) has been compromised. |
| 69 | + |
| 70 | +Being able to cause the following through control of the elements that Node.js |
| 71 | +does not trust is considered a vulnerability: |
| 72 | + |
| 73 | +* Disclosure or loss of integrity or confidentiality of data protected through |
| 74 | + the correct use of Node.js APIs. |
| 75 | +* The unavailability of the runtime, including the unbounded degradation of its |
| 76 | + performance. |
| 77 | + |
| 78 | +If Node.js loads configuration files or runs code by default (without a |
| 79 | +specific request from the user), and this is not documented, it is considered a |
| 80 | +vulnerability. |
| 81 | +Vulnerabilities related to this case may be fixed by a documentation update. |
| 82 | + |
| 83 | +**Node.js does NOT trust**: |
| 84 | + |
| 85 | +1. The data from network connections that are created through the use of Node.js |
| 86 | + APIs and which is transformed/validated by Node.js before being passed to the |
| 87 | + application. This includes: |
| 88 | + * HTTP APIs (all flavors) client and server APIs. |
| 89 | + * DNS APIs. |
| 90 | +2. Consumers of data protected through the use of Node.js APIs (for example |
| 91 | + people who have access to data encrypted through the Node.js crypto APIs). |
| 92 | +3. The file content or other I/O that is opened for reading or writing by the |
| 93 | + use of Node.js APIs (ex: stdin, stdout, stderr). |
| 94 | + |
| 95 | +In other words, if the data passing through Node.js to/from the application |
| 96 | +can trigger actions other than those documented for the APIs, there is likely |
| 97 | +a security vulnerability. Examples of unwanted actions are polluting globals, |
| 98 | +causing an unrecoverable crash, or any other unexpected side effects that can |
| 99 | +lead to a loss of confidentiality, integrity, or availability. |
| 100 | + |
| 101 | +**Node.js trusts everything else**. As some examples this includes: |
| 102 | + |
| 103 | +1. The developers and infrastructure that runs it. |
| 104 | +2. The operating system that Node.js is running under and its configuration, |
| 105 | + along with anything under control of the operating system. |
| 106 | +3. The code it is asked to run including JavaScript and native code, even if |
| 107 | + said code is dynamically loaded, e.g. all dependencies installed from the |
| 108 | + npm registry. |
| 109 | + The code run inherits all the privileges of the execution user. |
| 110 | +4. Inputs provided to it by the code it is asked to run, as it is the |
| 111 | + responsibility of the application to perform the required input validations. |
| 112 | +5. Any connection used for inspector (debugger protocol) regardless of being |
| 113 | + opened by command line options or Node.js APIs, and regardless of the remote |
| 114 | + end being on the local machine or remote. |
| 115 | +6. The file system when requiring a module. |
| 116 | + See <https://nodejs.org/api/modules.html#all-together>. |
| 117 | + |
| 118 | +Any unexpected behavior from the data manipulation from Node.js Internal |
| 119 | +functions are considered a vulnerability. |
| 120 | + |
| 121 | +In addition to addressing vulnerabilities based on the above, the project works |
| 122 | +to avoid APIs and internal implementations that make it "easy" for application |
| 123 | +code to use the APIs incorrectly in a way that results in vulnerabilities within |
| 124 | +the application code itself. While we don’t consider those vulnerabilities in |
| 125 | +Node.js itself and will not necessarily issue a CVE we do want them to be |
| 126 | +reported privately to Node.js first. |
| 127 | +We often choose to work to improve our APIs based on those reports and issue |
| 128 | +fixes either in regular or security releases depending on how much of a risk to |
| 129 | +the community they pose. |
| 130 | + |
| 131 | +### Examples of vulneratibities |
| 132 | + |
| 133 | +#### Improper Certificate Validation (CWE-295) |
| 134 | + |
| 135 | +* Node.js provides APIs to validate handling of Subject Alternative Names (SANs) |
| 136 | + in certficates used to connect to a TLS/SSL endpoint. If certificates can be |
| 137 | + crafted which result in incorrect validation by the Node.js APIs that is |
| 138 | + considered a vulnerability. |
| 139 | + |
| 140 | +#### Inconsistent Interpretation of HTTP Requests (CWE-444) |
| 141 | + |
| 142 | +* Node.js provides APIs to accept http connections. Those APIs parse the |
| 143 | + headers received for a connection and pass them on to the application. |
| 144 | + Bugs in parsing those headers which can result in request smuggling are |
| 145 | + considered vulnerabilities. |
| 146 | + |
| 147 | +#### Missing Cryptographic Step (CWE-325) |
| 148 | + |
| 149 | +* Node.js provides APIs to encrypt data. Bugs that would allow an attacker |
| 150 | + to get the orginal data without requiring the encryption key are |
| 151 | + considered vulnerabilities. |
| 152 | + |
| 153 | +#### External Control of System or Configuration Setting (CWE-15) |
| 154 | + |
| 155 | +* If Node.js automatically loads a configuration file which is not documented |
| 156 | + and modification of that configuration can affect the confidentiality of |
| 157 | + data protected using the Node.js APIs this is considered a vulnerability. |
| 158 | + |
| 159 | +### Examples of non-vulneratibities |
| 160 | + |
| 161 | +#### Malicious Third-Party Modules (CWE-1357) |
| 162 | + |
| 163 | +* Code is trusted by Node.js, therefore any scenario that requires a malicious |
| 164 | + third-party module cannot result in a vulnerability in Node.js. |
| 165 | + |
| 166 | +#### Prototype Pollution Attacks (CWE-1321) |
| 167 | + |
| 168 | +* Node.js trusts the inputs provided to it by application code. |
| 169 | + It is up to the application to sanitize appropriately, therefore any scenario |
| 170 | + that requires control over user input is not considered a vulnerability. |
| 171 | + |
| 172 | +#### Uncontrolled Search Path Element (CWE-427) |
| 173 | + |
| 174 | +* Node.js trusts the file system in the environment accessible to it. |
| 175 | + Therefore, it is not a vulnerability if it accesses/loads files from any path |
| 176 | + that is accessible to it. |
| 177 | + |
| 178 | +#### External Control of System or Configuration Setting (CWE-15) |
| 179 | + |
| 180 | +* If Node.js automatically loads a configuration file which is documented |
| 181 | + no scenario that requires modification of that configuration file is |
| 182 | + considered a vulnerability. |
| 183 | + |
58 | 184 | ## Receiving security updates |
59 | 185 |
|
60 | 186 | Security notifications will be distributed via the following methods. |
|