[Forgot Password]
Login  Register Subscribe












Paid content will be excluded from the download.

Download | Alert*
view XML

Improper Control of Resource Identifiers ('Resource Injection')

ID: 99Date: (C)2012-05-14   (M)2019-06-19
Type: weaknessStatus: DRAFT
Abstraction Type: Base


The software receives input from an upstream component, but it does not restrict or incorrectly restricts the input before it is used as an identifier for a resource that may be outside the intended sphere of control.

Extended Description

This may enable an attacker to access or modify otherwise protected system resources.

Likelihood of Exploit: High

Applicable Platforms
Language Class: All

Time Of Introduction

  • Architecture and Design
  • Implementation

Related Attack Patterns

Common Consequences

ScopeTechnical ImpactNotes
Read application data
Modify application data
Read files or directories
Modify files or directories
An attacker could gain access to or modify sensitive data or system resources. This could allow access to protected files or directories including configuration files and files containing sensitive information.

Detection Methods

Potential Mitigations

Input Validation
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist 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.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). A blacklist is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.


Related CWETypeViewChain
CWE-99 ChildOf CWE-896 Category CWE-888  

Demonstrative Examples   (Details)

  1. The following Java code uses input from an HTTP request to create a file name. The programmer has not considered the possibility that an attacker could provide a file name such as "../../tomcat/conf/server.xml", which causes the application to delete one of its own configuration files.
  2. The following code uses input from the command line to determine which file to open and echo back to the user. If the program runs with privileges and malicious users can create soft links to the file, they can use the program to read the first part of any file on the system.

White Box Definitions
A weakness where the code path has:
1. start statement that accepts input followed by
2. a statement that allocates a System Resource using name where the input is part of the name
3. end statement that accesses the System Resource where
a. the name of the System Resource violates protection

Black Box Definitions

Taxynomy Mappings

7 Pernicious Kingdoms  Resource Injection


© SecPod Technologies