| Name |
Using Slashes in Alternate Encoding |
|
| Likelyhood of attack |
Typical severity |
| High |
High |
|
| Summary |
This attack targets the encoding of the Slash characters. An attacker would try to exploit common filtering problems related to the use of the slashes characters to gain access to resources on the target host. Directory-driven systems, such as file systems and databases, typically use the slash character to indicate traversal between directories or other container components. For murky historical reasons, PCs (and, as a result, Microsoft OSs) choose to use a backslash, whereas the UNIX world typically makes use of the forward slash. The schizophrenic result is that many MS-based systems are required to understand both forms of the slash. This gives the attacker many opportunities to discover and abuse a number of common filtering problems. The goal of this pattern is to discover server software that only applies filters to one version, but not the other. |
| Prerequisites |
The application server accepts paths to locate resources. The application server does insufficient input data validation on the resource path requested by the user. The access right to resources are not set properly. |
| Execution Flow |
| Step |
Phase |
Description |
Techniques |
| 1 |
Experiment |
The attacker has access to a resource path and required to use slashes as resource delimiter. |
|
| 2 |
Experiment |
The attacker tries variation and combination of the slashes characters in different encoding format. |
|
| 3 |
Experiment |
The attacker found an unfiltered combination which maps to a valid path and accesses unauthorized resources (directories, files, etc.) |
|
|
| Solutions | Any security checks should occur after the data has been decoded and validated as correct data format. Do not repeat decoding process, if bad character are left after decoding process, treat the data as suspicious, and fail the validation process. Refer to the RFCs to safely decode URL. When client input is required from web-based forms, avoid using the "GET" method to submit data, as the method causes the form data to be appended to the URL and is easily manipulated. Instead, use the "POST method whenever possible. There are tools to scan HTTP requests to the server for valid URL such as URLScan from Microsoft (http://www.microsoft.com/technet/security/tools/urlscan.mspx) Be aware of the threat of alternative method of data encoding and obfuscation technique such as IP address encoding. (See related guideline section) Test your path decoding process against malicious input. In the case of path traversals, use the principle of least privilege when determining access rights to file systems. Do not allow users to access directories/files that they should not access. Assume all input is malicious. Create an allowlist that defines all valid input to the application based on the requirements specifications. Input that does not match against the allowlist should not be permitted to enter into the system. |
| Related Weaknesses |
|
CWE ID
|
Description
|
| CWE-20 |
Improper Input Validation |
| CWE-21 |
|
| CWE-22 |
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') |
| CWE-73 |
External Control of File Name or Path |
| CWE-74 |
Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') |
| CWE-171 |
|
| CWE-173 |
Improper Handling of Alternate Encoding |
| CWE-180 |
Incorrect Behavior Order: Validate Before Canonicalize |
| CWE-181 |
Incorrect Behavior Order: Validate Before Filter |
| CWE-185 |
Incorrect Regular Expression |
| CWE-200 |
Exposure of Sensitive Information to an Unauthorized Actor |
| CWE-697 |
Incorrect Comparison |
| CWE-707 |
Improper Neutralization |
|
| Related CAPECS |
|
CAPEC ID
|
Description
|
| CAPEC-267 |
An adversary leverages the possibility to encode potentially harmful input or content used by applications such that the applications are ineffective at validating this encoding standard. |
|