Red Hat Security Advisory: nodejs:22 security update

1. Requirements

   Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.

2. Architecture and Design

   Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.

3. Architecture and Design

   Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended.

OWASP Cheat Sheets

• Abuse Case (opens in a new tab)

OWASP ASVS 4.0.3

• V8.1.4 (opens in a new tab)
• V13.4.1 (opens in a new tab)
• V11.1.4 (opens in a new tab)

Attack patterns

• XML Ping of the Death (opens in a new tab)
• Exponential Data Expansion (opens in a new tab)
• Serialized Data Parameter Blowup (opens in a new tab)
• Serialized Data with Nested Payloads (opens in a new tab)
• Oversized Serialized Data Payloads (opens in a new tab)

From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

1. Architecture and Design · Libraries or Frameworks

   Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

2. Implementation · Architecture and Design

   Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages.

3. Architecture and Design · Implementation · Attack Surface Reduction

   Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide…

OWASP Cheat Sheets

• Cross Site Scripting Prevention (opens in a new tab)
• DOM based XSS Prevention (opens in a new tab)
• Injection Prevention (opens in a new tab)
• Abuse Case (opens in a new tab)
• Deserialization (opens in a new tab)

OWASP ASVS 4.0.3

• V5.3.3 (opens in a new tab)
• V1.5.1 (opens in a new tab)

Attack patterns

• XSS Using MIME Type Mismatch (opens in a new tab)
• DOM-Based XSS (opens in a new tab)
• Reflected XSS (opens in a new tab)
• Stored XSS (opens in a new tab)
• Cross-Site Scripting (XSS) (opens in a new tab)

From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

1. Implementation

   Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended).

2. Implementation

   Handle exceptions internally and do not display errors containing potentially sensitive information to a user.

3. Implementation · Attack Surface Reduction

   Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible.

OWASP Cheat Sheets

• Error Handling (opens in a new tab)
• Logging (opens in a new tab)

OWASP ASVS 4.0.3

• V8.3.4 (opens in a new tab)
• V14.3.3 (opens in a new tab)
• V7.3.3 (opens in a new tab)

Attack patterns

• Fuzzing for application mapping (opens in a new tab)
• Padding Oracle Crypto Attack (opens in a new tab)
• Query System for Information (opens in a new tab)
• Blind SQL Injection (opens in a new tab)

From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

1. Architecture and Design · Input Validation

   Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

2. Implementation · Input Validation

   Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

3. Implementation · Input Validation

   Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174).

OWASP Cheat Sheets

• OWASP Authentication (opens in a new tab)

OWASP ASVS 4.0.3

• V2.8.5 (opens in a new tab)
• V2.8.4 (opens in a new tab)
• V9.2.3 (opens in a new tab)

From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

1. Architecture and Design

   Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.

2. System Configuration

   Set backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process.

3. Implementation

   Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.

OWASP Cheat Sheets

• File Upload (opens in a new tab)

OWASP ASVS 4.0.3

• V12.1.1 (opens in a new tab)

Attack patterns

• Regular Expression Exponential Blowup (opens in a new tab)

From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

1. Implementation

   Do not use user-controlled data for loop conditions.

2. Implementation

   Perform input validation.

OWASP Cheat Sheets

• XML Security (opens in a new tab)
• Mass Assignment (opens in a new tab)

OWASP ASVS 4.0.3

• V13.3.1 (opens in a new tab)
• V5.1.4 (opens in a new tab)
• V5.1.3 (opens in a new tab)

From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

1. Architecture and Design

   When the set of filenames is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt".

2. Architecture and Design · Operation

   Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict all access to files within a particular directory.

3. Architecture and Design

   For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks…

OWASP Cheat Sheets

• XML Security (opens in a new tab)
• Mass Assignment (opens in a new tab)
• Secure Design Principles (opens in a new tab)

OWASP ASVS 4.0.3

• V12.3.2 (opens in a new tab)
• V13.3.1 (opens in a new tab)
• V5.1.4 (opens in a new tab)

Attack patterns

• Subverting Environment Variable Values (opens in a new tab)
• Leverage Alternate Encoding (opens in a new tab)
• Using Slashes and URL Encoding Combined to Bypass Validation Logic (opens in a new tab)
• URL Encoding (opens in a new tab)
• Manipulating Web Input to File System Calls (opens in a new tab)

From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

1. Requirements

   Use a language that is not susceptible to these issues. However, be careful of null byte interaction errors (CWE-626) with lower-level constructs that may be written in a language that is susceptible.

2. Implementation

   Ensure that all string functions used are understood fully as to how they append null characters. Also, be wary of off-by-one errors when appending nulls to the end of strings.

3. Implementation

   If performance constraints permit, special code can be added that validates null-termination of string buffers, this is a rather naive and error-prone solution.

OWASP Cheat Sheets

• XML Security (opens in a new tab)
• Mass Assignment (opens in a new tab)

OWASP ASVS 4.0.3

• V13.3.1 (opens in a new tab)
• V5.1.4 (opens in a new tab)
• V5.1.3 (opens in a new tab)

From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

1. Implementation

   The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check.

2. Implementation

   When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement.

3. Architecture and Design

   Limit the interleaving of operations on files from multiple processes.

OWASP Cheat Sheets

• Abuse Case (opens in a new tab)

OWASP ASVS 4.0.3

• V1.11.3 (opens in a new tab)
• V11.1.6 (opens in a new tab)
• V1.11.2 (opens in a new tab)

Attack patterns

• Leveraging Race Conditions via Symbolic Links (opens in a new tab)
• Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions (opens in a new tab)

From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

1. Architecture and Design · Implementation

   Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.

2. Implementation

   If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.

OWASP Cheat Sheets

• Transport Layer Protection (opens in a new tab)
• TLS Cipher String (opens in a new tab)
• OWASP Authentication (opens in a new tab)

OWASP ASVS 4.0.3

• V9.2.1 (opens in a new tab)
• V1.9.2 (opens in a new tab)
• V2.8.5 (opens in a new tab)

Attack patterns

• Creating a Rogue Certification Authority Certificate (opens in a new tab)
• Signature Spoofing by Improper Validation (opens in a new tab)

From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

1. Architecture and Design · Operation

   Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

2. Architecture and Design · Separation of Privilege

   Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.

OWASP ASVS 4.0.3

• V8.3.8 (opens in a new tab)
• V13.4.2 (opens in a new tab)
• V7.2.2 (opens in a new tab)

Attack patterns

• Web Server Logs Tampering (opens in a new tab)

From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

1. Architecture and Design

   Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place.

2. Architecture and Design

   Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, or; uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.

3. Architecture and Design

   Ensure that protocols have specific limits of scale placed on them.

OWASP Cheat Sheets

• File Upload (opens in a new tab)

OWASP ASVS 4.0.3

• V12.1.1 (opens in a new tab)

Attack patterns

• XML Ping of the Death (opens in a new tab)
• Regular Expression Exponential Blowup (opens in a new tab)
• Sustained Client Engagement (opens in a new tab)

From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).