mirror of
https://github.com/nodejs/node.git
synced 2025-08-15 13:48:44 +02:00
doc: fix minor grammar and style issues in SECURITY.md
PR-URL: https://github.com/nodejs/node/pull/53168 Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io> Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Moshe Atlow <moshe@atlow.co.il> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com> Reviewed-By: Ulises Gascón <ulisesgascongonzalez@gmail.com>
This commit is contained in:
parent
8c6d43cc4f
commit
a2446de50f
1 changed files with 21 additions and 22 deletions
43
SECURITY.md
43
SECURITY.md
|
@ -4,7 +4,7 @@
|
||||||
|
|
||||||
Report security bugs in Node.js via [HackerOne](https://hackerone.com/nodejs).
|
Report security bugs in Node.js via [HackerOne](https://hackerone.com/nodejs).
|
||||||
|
|
||||||
Normally your report will be acknowledged within 5 days, and you'll receive
|
Normally, your report will be acknowledged within 5 days, and you'll receive
|
||||||
a more detailed response to your report within 10 days indicating the
|
a more detailed response to your report within 10 days indicating the
|
||||||
next steps in handling your submission. These timelines may extend when
|
next steps in handling your submission. These timelines may extend when
|
||||||
our triage volunteers are away on holiday, particularly at the end of the
|
our triage volunteers are away on holiday, particularly at the end of the
|
||||||
|
@ -21,9 +21,9 @@ The Node.js project engages in an official bug bounty program for security
|
||||||
researchers and responsible public disclosures. The program is managed through
|
researchers and responsible public disclosures. The program is managed through
|
||||||
the HackerOne platform. See <https://hackerone.com/nodejs> for further details.
|
the HackerOne platform. See <https://hackerone.com/nodejs> for further details.
|
||||||
|
|
||||||
## Reporting a bug in a third party module
|
## Reporting a bug in a third-party module
|
||||||
|
|
||||||
Security bugs in third party modules should be reported to their respective
|
Security bugs in third-party modules should be reported to their respective
|
||||||
maintainers.
|
maintainers.
|
||||||
|
|
||||||
## Disclosure policy
|
## Disclosure policy
|
||||||
|
@ -41,20 +41,19 @@ Here is the security disclosure policy for Node.js
|
||||||
* A suggested embargo date for this vulnerability is chosen and a CVE (Common
|
* A suggested embargo date for this vulnerability is chosen and a CVE (Common
|
||||||
Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.
|
Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.
|
||||||
|
|
||||||
* On the embargo date, the Node.js security mailing list is sent a copy of the
|
* On the embargo date, a copy of the announcement is sent to the Node.js
|
||||||
announcement. The changes are pushed to the public repository and new builds
|
security mailing list. The changes are pushed to the public repository and new
|
||||||
are deployed to nodejs.org. Within 6 hours of the mailing list being
|
builds are deployed to nodejs.org. Within 6 hours of the mailing list being
|
||||||
notified, a copy of the advisory will be published on the Node.js blog.
|
notified, a copy of the advisory will be published on the Node.js blog.
|
||||||
|
|
||||||
* Typically the embargo date will be set 72 hours from the time the CVE is
|
* Typically, the embargo date will be set 72 hours from the time the CVE is
|
||||||
issued. However, this may vary depending on the severity of the bug or
|
issued. However, this may vary depending on the severity of the bug or
|
||||||
difficulty in applying a fix.
|
difficulty in applying a fix.
|
||||||
|
|
||||||
* This process can take some time, especially when coordination is required
|
* This process can take some time, especially when we need to coordinate with
|
||||||
with maintainers of other projects. Every effort will be made to handle the
|
maintainers of other projects. We will try to handle the bug as quickly as
|
||||||
bug in as timely a manner as possible; however, it's important that we follow
|
possible; however, we must follow the release process above to ensure that we
|
||||||
the release process above to ensure that the disclosure is handled in a
|
handle disclosure consistently.
|
||||||
consistent manner.
|
|
||||||
|
|
||||||
## The Node.js threat model
|
## The Node.js threat model
|
||||||
|
|
||||||
|
@ -91,12 +90,12 @@ Vulnerabilities related to this case may be fixed by a documentation update.
|
||||||
2. The data received from the remote end of outbound network connections
|
2. The data received from the remote end of outbound network connections
|
||||||
that are created through the use of Node.js APIs and
|
that are created through the use of Node.js APIs and
|
||||||
which is transformed/validated by Node.js before being passed
|
which is transformed/validated by Node.js before being passed
|
||||||
to the application EXCEPT in respect to payload length. Node.js trusts
|
to the application EXCEPT with respect to payload length. Node.js trusts
|
||||||
that applications make connections/requests which will avoid payload
|
that applications make connections/requests which will avoid payload
|
||||||
sizes that will result in a Denial of Service.
|
sizes that will result in a Denial of Service.
|
||||||
* HTTP APIs (all flavors) client APIs.
|
* HTTP APIs (all flavors) client APIs.
|
||||||
* DNS APIs.
|
* DNS APIs.
|
||||||
3. Consumers of data protected through the use of Node.js APIs (for example
|
3. 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).
|
people who have access to data encrypted through the Node.js crypto APIs).
|
||||||
4. The file content or other I/O that is opened for reading or writing by the
|
4. The file content or other I/O that is opened for reading or writing by the
|
||||||
use of Node.js APIs (ex: stdin, stdout, stderr).
|
use of Node.js APIs (ex: stdin, stdout, stderr).
|
||||||
|
@ -107,13 +106,13 @@ a security vulnerability. Examples of unwanted actions are polluting globals,
|
||||||
causing an unrecoverable crash, or any other unexpected side effects that can
|
causing an unrecoverable crash, or any other unexpected side effects that can
|
||||||
lead to a loss of confidentiality, integrity, or availability.
|
lead to a loss of confidentiality, integrity, or availability.
|
||||||
|
|
||||||
**Node.js trusts everything else**. As some examples this includes:
|
**Node.js trusts everything else**. Examples include:
|
||||||
|
|
||||||
1. The developers and infrastructure that runs it.
|
1. The developers and infrastructure that runs it.
|
||||||
2. The operating system that Node.js is running under and its configuration,
|
2. The operating system that Node.js is running under and its configuration,
|
||||||
along with anything under control of the operating system.
|
along with anything under control of the operating system.
|
||||||
3. The code it is asked to run including JavaScript and native code, even if
|
3. The code it is asked to run, including JavaScript and native code, even if
|
||||||
said code is dynamically loaded, e.g. all dependencies installed from the
|
said code is dynamically loaded, e.g., all dependencies installed from the
|
||||||
npm registry.
|
npm registry.
|
||||||
The code run inherits all the privileges of the execution user.
|
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
|
4. Inputs provided to it by the code it is asked to run, as it is the
|
||||||
|
@ -135,7 +134,7 @@ In addition to addressing vulnerabilities based on the above, the project works
|
||||||
to avoid APIs and internal implementations that make it "easy" for application
|
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
|
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
|
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
|
Node.js itself and will not necessarily issue a CVE, we do want them to be
|
||||||
reported privately to Node.js first.
|
reported privately to Node.js first.
|
||||||
We often choose to work to improve our APIs based on those reports and issue
|
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
|
fixes either in regular or security releases depending on how much of a risk to
|
||||||
|
@ -173,13 +172,13 @@ the community they pose.
|
||||||
|
|
||||||
#### Malicious Third-Party Modules (CWE-1357)
|
#### Malicious Third-Party Modules (CWE-1357)
|
||||||
|
|
||||||
* Code is trusted by Node.js, therefore any scenario that requires a malicious
|
* Code is trusted by Node.js. Therefore any scenario that requires a malicious
|
||||||
third-party module cannot result in a vulnerability in Node.js.
|
third-party module cannot result in a vulnerability in Node.js.
|
||||||
|
|
||||||
#### Prototype Pollution Attacks (CWE-1321)
|
#### Prototype Pollution Attacks (CWE-1321)
|
||||||
|
|
||||||
* Node.js trusts the inputs provided to it by application code.
|
* Node.js trusts the inputs provided to it by application code.
|
||||||
It is up to the application to sanitize appropriately, therefore any scenario
|
It is up to the application to sanitize appropriately. Therefore any scenario
|
||||||
that requires control over user input is not considered a vulnerability.
|
that requires control over user input is not considered a vulnerability.
|
||||||
|
|
||||||
#### Uncontrolled Search Path Element (CWE-427)
|
#### Uncontrolled Search Path Element (CWE-427)
|
||||||
|
@ -205,8 +204,8 @@ the community they pose.
|
||||||
|
|
||||||
* Corepack defaults to downloading the latest version of the software requested
|
* Corepack defaults to downloading the latest version of the software requested
|
||||||
by the user, or a specific version requested by the user. For this reason,
|
by the user, or a specific version requested by the user. For this reason,
|
||||||
Node.js releases won't be affected by such vulnerabilities, users are
|
Node.js releases won't be affected by such vulnerabilities. Users are
|
||||||
responsible to keep the software they use through Corepack up-to-date.
|
responsible for keeping the software they use through Corepack up-to-date.
|
||||||
|
|
||||||
## Assessing experimental features reports
|
## Assessing experimental features reports
|
||||||
|
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue