Name Double Encoding
Summary The adversary utilizes a repeating of the encoding process for a set of characters (that is, character encoding a character encoding of a character) to obfuscate the payload of a particular request. This may allow the adversary to bypass filters that attempt to detect illegal characters or strings, such as those that might be used in traversal or injection attacks. Filters may be able to catch illegal encoded strings, but may not catch doubly encoded strings. For example, a dot (.), often used in path traversal attacks and therefore often blocked by filters, could be URL encoded as %2E. However, many filters recognize this encoding and would still block the request. In a double encoding, the % in the above URL encoding would be encoded again as %25, resulting in %252E which some filters might not catch, but which could still be interpreted as a dot (.) by interpreters on the target.
Prerequisites The target's filters must fail to detect that a character has been doubly encoded but its interpreting engine must still be able to convert a doubly encoded character to an un-encoded character. The application accepts and decodes URL string request. The application performs insufficient filtering/canonicalization on the URLs.
Solutions Assume all input is malicious. Create a white list that defines all valid input to the software system based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system. Test your decoding process against malicious input. Be aware of the threat of alternative method of data encoding and obfuscation technique such as IP address encoding. 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. 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. Regular expression can be used to match safe URL patterns. However, that may discard valid URL requests if the regular expression is too restrictive. 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).
Related Weaknesses
CWE ID Description
CWE-20 Improper Input Validation
CWE-21 DEPRECATED: Pathname Traversal and Equivalence Errors
CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
CWE-171 DEPRECATED: Cleansing, Canonicalization, and Comparison Errors
CWE-172 Encoding Error
CWE-173 Improper Handling of Alternate Encoding
CWE-177 Improper Handling of URL Encoding (Hex Encoding)
CWE-181 Incorrect Behavior Order: Validate Before Filter
CWE-183 Permissive List of Allowed Inputs
CWE-184 Incomplete List of Disallowed Inputs
CWE-692 Incomplete Denylist to Cross-Site Scripting
CWE-697 Incorrect Comparison
Back to Top