|
1 | | -If you believe you have found a security issue in the software in this |
2 | | -repository, please consult https://github.com/nodejs/node/blob/HEAD/SECURITY.md. |
| 1 | +# Security |
| 2 | + |
| 3 | +## Reporting a vulnerability in undici |
| 4 | + |
| 5 | +Report security bugs in undici via |
| 6 | +[GitHub Security Advisories](https://github.com/nodejs/undici/security/advisories/new) |
| 7 | +or [HackerOne](https://hackerone.com/nodejs). |
| 8 | + |
| 9 | +Your report will normally be acknowledged within 5 days, and you will receive |
| 10 | +a more detailed response within 10 days indicating the next steps in handling |
| 11 | +your submission. These timelines may extend when our triage volunteers are |
| 12 | +away, particularly at the end of the year. |
| 13 | + |
| 14 | +After the initial reply to your report, the security team will endeavor to keep |
| 15 | +you informed of the progress being made towards a fix and full announcement, |
| 16 | +and may ask for additional information or guidance surrounding the reported |
| 17 | +issue. |
| 18 | + |
| 19 | +## Disclosure policy |
| 20 | + |
| 21 | +* The security report is received and assigned a primary handler. The problem |
| 22 | + is validated against all supported versions of undici. Once confirmed, a list |
| 23 | + of all affected versions is determined. Code is audited to find any potential |
| 24 | + similar problems. Fixes are prepared for all supported releases. These fixes |
| 25 | + are not committed to the public repository but rather held locally pending |
| 26 | + the announcement. |
| 27 | + |
| 28 | +* Because undici is bundled into Node.js, security releases are often |
| 29 | + coordinated with the Node.js project to avoid leaving Node.js users |
| 30 | + vulnerable. As a result, fixed versions of undici are published to npm |
| 31 | + before the corresponding CVE is disclosed, since the CVE will only be |
| 32 | + published after the coordinated Node.js release. This delay is typically |
| 33 | + a few days but can take up to a week. |
| 34 | + |
| 35 | +## The undici threat model |
| 36 | + |
| 37 | +Undici is an HTTP client library for Node.js. Its threat model is derived from |
| 38 | +and aligned with the [Node.js threat model](https://github.com/nodejs/node/blob/HEAD/SECURITY.md#the-nodejs-threat-model). |
| 39 | + |
| 40 | +### What constitutes a vulnerability |
| 41 | + |
| 42 | +Being able to cause the following through control of the elements that undici |
| 43 | +does not trust is considered a vulnerability: |
| 44 | + |
| 45 | +* Disclosure or loss of integrity or confidentiality of data protected through |
| 46 | + the correct use of undici APIs. |
| 47 | +* The unavailability of the runtime, including the unbounded degradation of its |
| 48 | + performance. |
| 49 | + |
| 50 | +#### Denial of Service (DoS) vulnerabilities |
| 51 | + |
| 52 | +For a behavior to be considered a DoS vulnerability, the proof of concept must |
| 53 | +meet the following criteria: |
| 54 | + |
| 55 | +* The API is being correctly used. |
| 56 | +* The API is public and documented. |
| 57 | +* The behavior is significant enough to cause a denial of service quickly |
| 58 | + or in a context not controlled by the application developer (for example, |
| 59 | + HTTP parsing). |
| 60 | +* The behavior is directly exploitable by an untrusted source without requiring |
| 61 | + application mistakes. |
| 62 | +* The behavior cannot be reasonably mitigated through standard operational |
| 63 | + practices (like process recycling). |
| 64 | +* The attack demonstrates |
| 65 | + [asymmetric resource consumption](https://cwe.mitre.org/data/definitions/405.html), |
| 66 | + where the attacker expends significantly fewer resources than what is required |
| 67 | + by the client to process the attack. |
| 68 | + |
| 69 | +**Undici does NOT trust**: |
| 70 | + |
| 71 | +* Data received from the remote end of HTTP connections (both inbound responses |
| 72 | + and server-sent data) that is parsed or transformed by undici before being |
| 73 | + passed to the application. This includes: |
| 74 | + * HTTP response headers and status lines. |
| 75 | + * HTTP response bodies when processed by undici (e.g., chunked transfer |
| 76 | + decoding, content-encoding). |
| 77 | + * WebSocket frames received from a server. |
| 78 | + * Server-Sent Events (EventSource) data received from a server. |
| 79 | +* TLS certificate validation performed by undici on behalf of the application. |
| 80 | + |
| 81 | +**Undici trusts**: |
| 82 | + |
| 83 | +* The application code that uses its APIs, including all configuration, |
| 84 | + options, and callbacks provided by the application. |
| 85 | +* The operating system and its network stack. |
| 86 | +* The Node.js runtime undici is running on. |
| 87 | +* Dependencies installed by the application. |
| 88 | +* The DNS resolution results provided by the operating system or configured |
| 89 | + resolvers. |
| 90 | + |
| 91 | +In other words, if untrusted data passing through undici to the application |
| 92 | +can trigger actions other than those documented for the APIs, there is likely |
| 93 | +a security vulnerability. Examples of unwanted actions are polluting globals, |
| 94 | +causing an unrecoverable crash, or any other unexpected side effects that can |
| 95 | +lead to a loss of confidentiality, integrity, or availability. |
| 96 | + |
| 97 | +### Examples of vulnerabilities |
| 98 | + |
| 99 | +#### Improper Certificate Validation (CWE-295) |
| 100 | + |
| 101 | +* Undici provides TLS connections to HTTPS endpoints. If certificates can be |
| 102 | + crafted that result in incorrect validation by undici, that is considered |
| 103 | + a vulnerability. |
| 104 | + |
| 105 | +#### Inconsistent Interpretation of HTTP Responses (CWE-444) |
| 106 | + |
| 107 | +* Undici parses HTTP responses received from servers. Bugs in parsing response |
| 108 | + headers or transfer encoding which can result in response smuggling or |
| 109 | + desynchronization are considered vulnerabilities. |
| 110 | + |
| 111 | +#### HTTP Request Smuggling (CWE-444) |
| 112 | + |
| 113 | +* Bugs that allow crafting requests that are interpreted differently by undici |
| 114 | + and an upstream server, leading to request smuggling, are considered |
| 115 | + vulnerabilities. |
| 116 | + |
| 117 | +#### CRLF Injection in Request Headers (CWE-93) |
| 118 | + |
| 119 | +* If untrusted input passed to undici APIs (such as header values or URLs) |
| 120 | + can inject additional headers or corrupt the HTTP request stream, that is |
| 121 | + considered a vulnerability. |
| 122 | + |
| 123 | +### Examples of non-vulnerabilities |
| 124 | + |
| 125 | +#### Malicious Third-Party Modules (CWE-1357) |
| 126 | + |
| 127 | +* Application code and its dependencies are trusted by undici. Any scenario |
| 128 | + that requires a malicious third-party module cannot result in a vulnerability |
| 129 | + in undici. |
| 130 | + |
| 131 | +#### Prototype Pollution Attacks (CWE-1321) |
| 132 | + |
| 133 | +* Undici trusts the inputs provided to it by application code. It is up to the |
| 134 | + application to sanitize appropriately. Any scenario that requires control |
| 135 | + over user input passed directly by the application is not considered a |
| 136 | + vulnerability in undici. |
| 137 | + |
| 138 | +#### Uncontrolled Resource Consumption on Outbound Connections (CWE-400) |
| 139 | + |
| 140 | +* If undici is asked to connect to a remote site and the response payload is |
| 141 | + large enough to impact performance or cause the runtime to run out of |
| 142 | + resources, that is not considered a vulnerability. Applications are |
| 143 | + responsible for setting appropriate limits on response sizes. |
| 144 | + |
| 145 | +#### Application Misconfiguration |
| 146 | + |
| 147 | +* Issues arising from incorrect or insecure use of undici APIs (such as |
| 148 | + disabling TLS verification, ignoring errors, or passing unsanitized user |
| 149 | + input to request options) are the application's responsibility, not |
| 150 | + vulnerabilities in undici. |
| 151 | + |
| 152 | +## Receiving security updates |
| 153 | + |
| 154 | +Security notifications will be distributed via |
| 155 | +[GitHub Security Advisories](https://github.com/nodejs/undici/security/advisories). |
| 156 | + |
| 157 | +## Comments on this policy |
| 158 | + |
| 159 | +If you have suggestions on how this process could be improved, please open an |
| 160 | +issue on the [nodejs/undici](https://github.com/nodejs/undici/issues) |
| 161 | +repository or file a pull request. |
0 commit comments