Red Hat Security Advisory: Red Hat Developer Hub 1.9.9 release

1. Implementation

   For any pointers that could have been modified or provided from a function that can return NULL, check the pointer for NULL before use. When working with a multithreaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the check, and unlock when it has finished.

2. Requirements

   Select a programming language that is not susceptible to these issues.

3. Implementation

   Check the results of all functions that return a value and verify that the value is non-null before acting upon it.

OWASP Cheat Sheets

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

OWASP ASVS 4.0.3

• V11.1.7 (opens in a new tab)

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

1. Operation

   If possible, prohibit the use of DTDs or use an XML parser that limits the expansion of recursive DTD entities.

2. Implementation

   Before parsing XML files with associated DTDs, scan for recursive entity declarations and do not continue parsing potentially explosive content.

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

• Exponential Data Expansion (opens in a new tab)

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

1. Implementation · Operation

   If there is a known list of applications, IP, hostname, and/or domains to which the product is allowed to communicate, then use allowlists to ensure that outgoing requests are restricted to these known entities. The allowlists could be in the application code or possibly enforced by firewalls or network segmentation.

2. Implementation · Operation

   If the product is expected to be able to connect to arbitrary IP addresses or domains, consider using a denylist that includes private network addresses, internal domain names, etc. The denylist could be in the application code or possibly enforced by firewalls or network segmentation.

3. 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.

OWASP Cheat Sheets

• Server Side Request Forgery Prevention (opens in a new tab)
• Unvalidated Redirects and Forwards (opens in a new tab)
• Cross Site Scripting Prevention (opens in a new tab)
• DOM based XSS Prevention (opens in a new tab)
• Authorization (opens in a new tab)

OWASP ASVS 4.0.3

• V12.6.1 (opens in a new tab)
• V5.2.6 (opens in a new tab)

Attack patterns

• Server Side Request Forgery (opens in a new tab)

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

1. Requirements

   Specify which data in the software should be regarded as sensitive. Consider which types of users should have access to which types of data.

2. Implementation

   Ensure that any possibly sensitive data specified in the requirements is verified with designers to ensure that it is either a calculated risk or mitigated elsewhere.

3. System Configuration

   Setup default error messages so that unexpected errors do not disclose sensitive information.

OWASP Cheat Sheets

• Error Handling (opens in a new tab)
• Logging (opens in a new tab)
• Authorization (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

• Choosing Message Identifier (opens in a new tab)
• Exploiting Incorrectly Configured SSL/TLS (opens in a new tab)
• WiFi MAC Address Tracking (opens in a new tab)
• WiFi SSID Tracking (opens in a new tab)
• Cellular Broadcast Message Request (opens in a new tab)

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

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).

OWASP Cheat Sheets

• File Upload (opens in a new tab)

OWASP ASVS 4.0.3

• V12.1.1 (opens in a new tab)

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

1. Implementation · Enforcement by Conversion

   If the number to be used is always expected to be positive, change the variable type from signed to unsigned or size_t.

2. Implementation · Input Validation

   If the number to be used could have a negative value based on the specification (thus requiring a signed value), but the number should only be positive to preserve code correctness, then include a check to ensure that the value is positive.

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

1. Implementation

   Ensure that an end condition will be reached under all logic conditions. The end condition may include checking against the depth of recursion and exiting with an error if the recursion goes too deep. The complexity of the end condition contributes to the effectiveness of this action.

2. Implementation

   Increase the stack size.

Attack patterns

• 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

   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 · Enforcement by Conversion

   If only decimal-based values are expected in the application, conditional checks should be created in a way that prevent octal or hexadecimal strings from being checked.

2. Implementation · Input Validation

   If various numerical bases do need to be supported, check for leading values indicating the non-decimal base you wish to support (such as 0x for hex) and convert the numeric strings to integers of the respective base. Reject any other alternative-base string that is not intentionally supported by the application.

3. Implementation · Input Validation

   If regular expressions are used to validate IP addresses, ensure that they are bounded using ^ and $ to prevent base-prepended IP addresses from being matched.

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

1. Architecture and Design · Implementation

   It is highly recommended to use a true random number generator (TRNG) to ensure the security of encryption schemes. Hardware-based TRNGs generate unpredictable, unbiased, and independent random numbers because they employ physical phenomena, e.g., electrical noise, as sources to generate random numbers.

OWASP Cheat Sheets

• Forgot Password (opens in a new tab)
• Transport Layer Protection (opens in a new tab)
• User Privacy Protection (opens in a new tab)
• Password Storage (opens in a new tab)
• Cryptographic Storage (opens in a new tab)

OWASP ASVS 4.0.3

• V2.3.1 (opens in a new tab)
• V2.6.2 (opens in a new tab)
• V2.7.6 (opens in a new tab)

Attack patterns

• Cryptanalysis (opens in a new tab)

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

1. Implementation · Input Validation

   Developers should anticipate that delimiters will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

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 · Output Encoding

   While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments.

OWASP Cheat Sheets

• Abuse Case (opens in a new tab)
• Deserialization (opens in a new tab)
• Server Side Request Forgery Prevention (opens in a new tab)
• Unvalidated Redirects and Forwards (opens in a new tab)
• Cross Site Scripting Prevention (opens in a new tab)

OWASP ASVS 4.0.3

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

Attack patterns

• Command Delimiters (opens in a new tab)

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

1. Implementation

   Use a web server that employs a strict HTTP parsing procedure, such as Apache.

2. Implementation

   Use only SSL communication.

3. Implementation

   Terminate the client session after each request.

OWASP Cheat Sheets

• REST Assessment (opens in a new tab)
• REST Security (opens in a new tab)
• Cross-Site Request Forgery Prevention (opens in a new tab)
• Secure Design Principles (opens in a new tab)

OWASP ASVS 4.0.3

• V13.2.5 (opens in a new tab)

Attack patterns

• HTTP Response Smuggling (opens in a new tab)
• HTTP Request Smuggling (opens in a new tab)

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

1. Requirements

   Programming languages and supporting technologies might be chosen which are not subject to these issues.

2. Implementation

   Utilize an appropriate mix of allowlist and denylist parsing to filter equivalent special element syntax from all input.

OWASP Cheat Sheets

• Abuse Case (opens in a new tab)
• Deserialization (opens in a new tab)
• Injection Prevention (opens in a new tab)
• SQL Injection Prevention (opens in a new tab)
• Injection Prevention in Java (opens in a new tab)

OWASP ASVS 4.0.3

• V1.5.1 (opens in a new tab)

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

1. 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.

OWASP Cheat Sheets

• Abuse Case (opens in a new tab)
• Deserialization (opens in a new tab)
• Injection Prevention (opens in a new tab)
• SQL Injection Prevention (opens in a new tab)
• Injection Prevention in Java (opens in a new tab)

OWASP ASVS 4.0.3

• V1.5.1 (opens in a new tab)

Attack patterns

• XML Injection (opens in a new tab)
• XPath Injection (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. 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.

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 · 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. 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.

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).