Improper Control of Resource Identifiers ('Resource Injection')ID: 99 | Date: (C)2012-05-14 (M)2022-10-10 |
Type: weakness | Status: DRAFT |
Abstraction Type: Base |
Description
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 DescriptionThis may enable an attacker to access or modify otherwise protected system
resources.
Likelihood of Exploit: High
Applicable PlatformsLanguage Class: All
Time Of Introduction
- Architecture and Design
- Implementation
Related Attack Patterns
Common Consequences
Scope | Technical Impact | Notes |
---|
ConfidentialityIntegrity | Read application
dataModify application
dataRead files or
directoriesModify 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 MethodsNone
Potential Mitigations
Phase | Strategy | Description | Effectiveness | Notes |
---|
Implementation | 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. | | |
Relationships
Related CWE | Type | View | Chain |
---|
CWE-99 ChildOf CWE-896 | Category | CWE-888 | |
Demonstrative Examples (Details)
- 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.
- 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 DefinitionsA weakness where the code path has:1. start statement that accepts input followed by2. a statement that allocates a System Resource using name where the
input is part of the name3. end statement that accesses the System Resource wherea. the name of the System Resource violates protection
Black Box Definitions None
Taxynomy Mappings
Taxynomy | Id | Name | Fit |
---|
7 Pernicious Kingdoms | | Resource Injection | |
References:None