English
Français
Light
Dark
System

Alert System

Stay informed at all times
Create an account Open a free account Login Manage your alerts

CAPEC-3

Using Leading 'Ghost' Character Sequences to Bypass Input Filters
MEDIUM
MEDIUM
Draft
2014-06-23 00:00 +00:00
2022-09-29 00:00 +00:00
CAPEC Mitre.org

Alerte pour un CAPEC

Stay informed of any changes for a specific CAPEC.
Alert management

Description

Some APIs will strip certain leading characters from a string of parameters. An adversary can intentionally introduce leading "ghost" characters (extra characters that don't affect the validity of the request at the API layer) that enable the input to pass the filters and therefore process the adversary's input. This occurs when the targeted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targeted API.

Informations

Execution Flow

1) Explore

[Survey the application for user-controllable inputs] Using a browser, an automated tool or by inspecting the application, an adversary records all entry points to the application.

Technique
  • Use a spidering tool to follow and record all links and analyze the web pages to find entry points. Make special note of any links that include parameters in the URL.
  • Use a proxy tool to record all user input entry points visited during a manual traversal of the web application.
  • Use a browser to manually explore the website and analyze how it is constructed. Many browsers' plugins are available to facilitate the analysis or automate the discovery.
  • Manually inspect the application to find entry points.

2) Experiment

[Probe entry points to locate vulnerabilities] The adversary uses the entry points gathered in the "Explore" phase as a target list and injects various leading 'Ghost' character sequences to determine how to application filters them.

Technique
  • Add additional characters to common sequences such as "../" to see how the application will filter them.
  • Try repeating special characters (?, @, #, *, etc.) at the beginning of user input to see how the application filters these out.

3) Exploit

[Bypass input filtering] Using what the adversary learned about how the application filters input data, they craft specific input data that bypasses the filter. This can lead to directory traversal attacks, arbitrary shell command execution, corruption of files, etc.

Prerequisites

The targeted API must ignore the leading ghost characters that are used to get past the filters for the semantics to be the same.

Skills Required

The ability to make an API request, and knowledge of "ghost" characters that will not be filtered by any input validation. These "ghost" characters must be known to not affect the way in which the request will be interpreted.

Mitigations

Use an allowlist rather than a denylist input validation.
Canonicalize all data prior to validation.
Take an iterative approach to input validation (defense in depth).

Related Weaknesses

CWE-ID Weakness Name
CWE-173 Improper Handling of Alternate Encoding
The product does not properly handle when an input uses an alternate encoding that is valid for the control sphere to which the input is being sent.
CWE-41 Improper Resolution of Path Equivalence
The product is vulnerable to file system contents disclosure through path equivalence. Path equivalence involves the use of special characters in file and directory names. The associated manipulations are intended to generate multiple names for the same object.
CWE-172 Encoding Error
The product does not properly encode or decode the data, resulting in unexpected values.
CWE-179 Incorrect Behavior Order: Early Validation
The product validates input before applying protection mechanisms that modify the input, which could allow an attacker to bypass the validation via dangerous inputs that only arise after the modification.
CWE-180 Incorrect Behavior Order: Validate Before Canonicalize
The product validates input before it is canonicalized, which prevents the product from detecting data that becomes invalid after the canonicalization step.
CWE-181 Incorrect Behavior Order: Validate Before Filter
The product validates data before it has been filtered, which prevents the product from detecting data that becomes invalid after the filtering step.
CWE-183 Permissive List of Allowed Inputs
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are explicitly allowed by policy because the inputs are assumed to be safe, but the list is too permissive - that is, it allows an input that is unsafe, leading to resultant weaknesses.
CWE-184 Incomplete List of Disallowed Inputs
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete, leading to resultant weaknesses.
CWE-20 Improper Input Validation
The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.
CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.
CWE-697 Incorrect Comparison
The product compares two entities in a security-relevant context, but the comparison is incorrect, which may lead to resultant weaknesses.
CWE-707 Improper Neutralization
The product does not ensure or incorrectly ensures that structured messages or data are well-formed and that certain security properties are met before being read from an upstream component or sent to a downstream component.

References

REF-1

Exploiting Software: How to Break Code
G. Hoglund, G. McGraw.

Submission

Name Organization Date Date Release
CAPEC Content Team The MITRE Corporation 2014-06-23 +00:00

Modifications

Name Organization Date Comment
CAPEC Content Team The MITRE Corporation 2015-11-09 +00:00 Updated Attack_Phases
CAPEC Content Team The MITRE Corporation 2015-12-07 +00:00 Updated Attack_Phases
CAPEC Content Team The MITRE Corporation 2017-01-09 +00:00 Updated Attack_Phases
CAPEC Content Team The MITRE Corporation 2017-05-01 +00:00 Updated Attack_Phases
CAPEC Content Team The MITRE Corporation 2017-08-04 +00:00 Updated Attack_Phases, Description Summary, Payload
CAPEC Content Team The MITRE Corporation 2018-07-31 +00:00 Updated Attack_Phases, Attacker_Skills_or_Knowledge_Required
CAPEC Content Team The MITRE Corporation 2020-07-30 +00:00 Updated Mitigations
CAPEC Content Team The MITRE Corporation 2021-06-24 +00:00 Updated Related_Weaknesses
CAPEC Content Team The MITRE Corporation 2022-02-22 +00:00 Updated Execution_Flow
CAPEC Content Team The MITRE Corporation 2022-09-29 +00:00 Updated Example_Instances

More information
Click on the button to the left (OFF), to authorize the inscription of cookie improving the functionalities of the site. Click on the button to the left (Accept all), to unauthorize the inscription of cookie improving the functionalities of the site.