Resource Injection

ID

javascript.resource_injection

Severity

high

Resource

Injection

Language

JavaScript

Tags

CWE:99, NIST.SP.800-53, OWASP:2021:A3, PCI-DSS:6.5.1

Description

Improper control of resource identifiers ('Resource Injection').

Rationale

Resource Injection occurs when an attacker is able to manipulate inputs that are concatenated with paths, queries, or resource identifiers in such a way that unintended resources are accessed. The main risk is unauthorized access, data leakage, and potential modification or destruction of resources.

The following is a JavaScript example of a resource injection vulnerability:

const path = process.argv[2]; // any externally-controlled input

// FLAW: vulnerable to resource injection,
// attacker may choose a different server or even port with a crafted input
const wssWebSocket = new WebSocket(`wss://websocket.example.org${path}`);

The external input could be something like .hackers.com:1234/malware_bazaar to control the server and port and get the web socket connected to an unintended resource.

Remediation

The most common way to prevent resource injection vulnerabilities is to sanitize user input before using it in resource construction: Ensure that resource identifiers are strictly validated against a whitelist of known safe values. This prevents arbitrary input from being interpreted as a valid identifier.

If whitelisting is not possible, use a strict blacklist to limit the range of allowed identifiers.

Additional precautions include:

  • Privilege Segregation: Run resource access code under the least privilege principle. Design the application to minimize the access scope for sensitive resources.

  • Logging and Alerting: Implement comprehensive logging and alerting to monitor resource access, making clear which resources are accessed. This helps in early detection of suspicious activities or misuse.

  • Static Code Analysis: Utilize SAST tools with detectors that specifically check for untrusted input in resource construction. Regular scans will help identify new vulnerabilities introduced in your code base.

The following is an example of sanitization using whitelist on the input:

let path = process.argv[2];

// FIXED: the path must be '/SOME_WORD'
const path_pattern = /^\/[a-zA-Z][a-zA-Z0-9_]*$/;

if( path_pattern.test(path) ) {
    let ws = new WebSocket(`wss://websocket.example.org${path}`);
} else {
    // handle validation error
    validation_error('Invalid path', path);
    let ws = new WebSocket('wss://websocket.example.org/default');
}

Configuration

The detector has the following configurable parameters:

  • sources, that indicates the source kinds to check.

  • neutralizations, that indicates the neutralization kinds to check.

Unless you need to change the default behavior, you typically do not need to configure this detector.

References