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.
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, 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]
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]
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.
In the following PHP program, the value of /* Security filter *//* Exit if user input contains directory traversal sequence */if (strstr($path, "../") or strstr($path, "..\\")) /* 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));$_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.../../../../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.
In the following PHP program, the value of /* 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;$_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.<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.