Double encoding

From HandWiki
Short description: Attack technique for bypassing security measures

Double encoding is the act of encoding data twice in a row using the same encoding scheme. It is usually used as an attack technique to bypass authorization schemes or security filters that intercept user input. In double encoding attacks against security filters, characters of the payload that are treated as illegal by those filters are replaced with their double-encoded form.

Double URI-encoding is a special type of double encoding in which data is URI-encoded twice in a row. It has been used to bypass authorization schemes and security filters against code injection, directory traversal, cross-site scripting (XSS) and SQL injection.

Description

In double encoding, data is encoded twice in a row using the same encoding scheme, that is, double-encoded form of data X is Encode(Encode(X)) where Encode is an encoding function.[1]

Double encoding is usually used as an attack technique to bypass authorization schemes or security filters that intercept user input.[2] In double encoding attacks against security filters, characters of the payload that are treated as illegal by those filters are replaced with their double-encoded form.[3] Security filters might treat data X and its encoded form as illegal.[4] However, it is still possible for Encode(Encode(X)), which is the double-encoded form of data X, to not to be treated as illegal by security filters and hence pass through them, but later on, the target system might use the double-decoded form of Encode(Encode(X)), which is X, something that the filters would have been treated as illegal.[5]

Double URI-encoding

Double URI-encoding, also referred to as double percent-encoding, is a special type of double encoding in which data is URI-encoded twice in a row.[6] In other words, double-URI-encoded form of data X is URI-encode(URI-encode(X)).[7] For example for calculating double-URI-encoded form of <, first < is URI-encoded as %3C which then in turn is URI-encoded as %253C, that is, double-URI-encode(<) = URI-encode(URI-encode(<)) = URI-encode(%3C) = %253C.[8] As another example, for calculating double-URI-encoded form of ../, first ../ is URI-encoded as %2E%2E%2F which then in turn is URI-encoded as %252E%252E%252F, that is, double-URI-encode(../) = URI-encode(URI-encode(../)) = URI-encode(%2E%2E%2F) = %252E%252E%252F.[9]

Double URI-encoding is usually used as an attack technique against web applications and web browsers to bypass authorization schemes and security filters that intercept user input.[10][11] For example because . and its URI-encoded form %2E are used in some directory traversal attacks, they are usually treated as illegal by security filters.[12] However, it is still possible for %252E, which is the double-URI-encoded form of ., to not to be treated as illegal by security filters and hence pass through them, but later on, when the target system is building the path related to the directory traversal attack it might use the double-URI-decoded form of %252E, which is ., something that the filters would have been treated as illegal.[13]

Double URI-encoding attacks have been used to bypass authorization schemes and security filters against code injection, directory traversal, XSS and SQL injection.[14]

Prevention

Decoding some user input twice using the same decoding scheme, once before a security measure and once afterwards, may allow double encoding attacks to bypass that security measure.[15] Thus, to prevent double encoding attacks, all decoding operations on user input should occur before authorization schemes and security filters that intercept user input.[16]

Examples

PHP

In PHP programming language, data items in $_GET and $_REQUEST are sufficiently URI-decoded and thus programmers should avoid calling the urldecode function on them.[17] Calling the urldecode function on data that has been read from $_GET or $_REQUEST causes the data to be URI-decoded once more than it should and hence may open possibility for double URI-encoding attacks.

Directory traversal

In the following PHP program, the value of $_GET["file"] is used to build the path of the file to be sent to the user. This opens the possibility for directory traversal attacks that incorporate their payload into the HTTP GET parameter file. As a security filter against directory traversal attacks, this program searches the value it reads from $_GET["file"] for directory traversal sequences and exits if it finds one. However, after this filter, the program URI-decodes the data that it has read from $_GET["file"], which makes it vulnerable to double URI-encoding attacks. 

<?php
/* Note that $_GET is already URI-decoded */
$path = $_GET["file"];

/* Security filter */
/* Exit if user input contains directory traversal sequence */
if (strstr($path, "../") or strstr($path,  "..\\"))
{
    exit("Directory traversal attempt detected.");
}

/* URI-decode user input once again */
$path = urldecode($path);

/* Build file path to be sent using user input */
echo htmlentities(file_get_contents("uploads/" . $path));

This filter prevents payloads such as ../../../../etc/passwd and its URI-encoded form %2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2Fetc%2Fpasswd. However, %252E%252E%252F%252E%252E%252F%252E%252E%252F%252E%252E%252Fetc%252Fpasswd, which is the double-URI-encoded form of ../../../../etc/passwd, will bypass this filter. When double-URI-encoded payload %252E%252E%252F%252E%252E%252F%252E%252E%252F%252E%252E%252Fetc%252Fpasswd is used, the value of $_GET["file"] will be %2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2Fetc%2Fpasswd which doesn't contain any directory traversal sequence and thus passes through the filter and will be given to the urldecode function which returns ../../../../etc/passwd, resulting in a successful attack.

XSS

In the following PHP program, the value of $_GET["name"] is used to build a message to be shown to the user. This opens the possibility for XSS attacks that incorporate their payload into the HTTP GET parameter name. As a security filter against XSS attacks, this program sanitizes the value it reads from $_GET["name"] via the htmlentities function. However, after this filter, the program URI-decodes the data that it has read from $_GET["name"], which makes it vulnerable to double URI-encoding attacks. 

<?php
/* Note that $_GET is already URI-decoded */
$name = $_GET["name"];

/* Security filter */
/* Sanitize user input via htmlentity */
$name = htmlentities($name);

/* URI-decode user input once again */
$name = urldecode($name);

/* Build message to be shown using user input */
echo "Hello " . $name;

This filter prevents payloads such as <script>alert(1)</script> and its URI-encoded form %3Cscript%3Ealert%281%29%3C%2Fscript%3E. However, %253Cscript%253Ealert%25281%2529%253C%252Fscript%253E, which is the double-URI-encoded form of <script>alert(1)</script>, will bypass this filter. When double-URI-encoded payload %253Cscript%253Ealert%25281%2529%253C%252Fscript%253E is used, the value of $_GET["name"] will be %3Cscript%3Ealert%281%29%3C%2Fscript%3E which doesn't contain any illegal character and thus passes through the htmlentities function without any change and will be given to the urldecode function which returns <script>alert(1)</script>, resulting in a successful attack.

Sources

References

  1. ↑ CAPEC 2022, Description. "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."
  2. ↑ CAPEC 2022, Description,Execution Flow. "This[double encoding] 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 [...] For instance, by double encoding certain characters in the URL (e.g. dots and slashes) an adversary may try to get access to restricted resources on the web server or force browse to protected pages (thus subverting the authorization service). An adversary can also attempt other injection style attacks using this attack pattern: command injection, SQL injection, etc."
  3. ↑ CAPEC 2022, Description,Execution Flow. "This[double encoding] 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. [...] Try double-encoding for parts of the input in order to try to get past the filters."
  4. ↑ OWASP 2022, Description. "By using double encoding it’s possible to bypass security filters that only decode user input once."
  5. ↑ OWASP 2022, Description. "By using double encoding it’s possible to bypass security filters that only decode user input once. The second decoding process is executed by the backend platform or modules that properly handle encoded data, but don’t have the corresponding security checks in place."
  6. ↑ Prasad 2016, p. 11. "Double percent encoding is the same as percent encoding with a twist that each character is encoded twice instead of once."
  7. ↑ Prasad 2016, p. 11. "Double percent encoding is the same as percent encoding with a twist that each character is encoded twice instead of once."
  8. ↑ Prasad 2016, p. 11. "So if I had to encode < using double encoding, I'll first encode it into its percent-encoded format, which is %3c and then again percent encode the % character. The result of this will be %253c."
  9. ↑ OWASP 2022, Description. "For example, ../ (dot-dot-slash) characters represent %2E%2E%2F in hexadecimal representation. When the % symbol is encoded again, its representation in hexadecimal code is %25. The result from the double encoding process ../ (dot-dot-slash) would be %252E%252E%252F"
  10. ↑ Prasad 2016, p. 11. "This technique[double percent encoding] comes in pretty handy when attempting to evade filters which attempt to blacklist certain encoded characters"
  11. ↑ CAPEC 2022, Execution Flow. "For instance, by double encoding certain characters in the URL (e.g. dots and slashes) an adversary may try to get access to restricted resources on the web server or force browse to protected pages (thus subverting the authorization service). An adversary can also attempt other injection style attacks using this attack pattern: command injection, SQL injection, etc."
  12. ↑ CAPEC 2022, Description. "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."
  13. ↑ CAPEC 2022, Description. "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."
  14. ↑ CWE 2022, Observed Examples.
  15. ↑ CWE 2022, Description. "The software decodes the same input twice, which can limit the effectiveness of any protection mechanism that occurs in between the decoding operations."
  16. ↑ CWE 2022, Potential Mitigations. "Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180)."
  17. ↑ PHP 2022, Notes. "Warning: The superglobals $_GET and $_REQUEST are already decoded. Using urldecode() on an element in $_GET or $_REQUEST could have unexpected and dangerous results."

External links



Retrieved from "https://handwiki.org/wiki/index.php?title=Double_encoding&oldid=2649270"