Difference between revisions of "Double Encoding"

From OWASP
Jump to: navigation, search
Line 2: Line 2:
  
 
==Description==
 
==Description==
 
 
This attack technique consists of encode user request parameters twice in hexadecimal format in order to bypass security controls or cause unexpected behavior from application.
 
This attack technique consists of encode user request parameters twice in hexadecimal format in order to bypass security controls or cause unexpected behavior from application.
  
Line 20: Line 19:
  
  
==Examples ==
+
==Severity==
 +
Medium to High
  
===Example 1 ===
+
==Likelihood of exploitation==
 +
High
  
 +
==Examples ==
  
 +
===Example 1 ===
 
This example presents an old well-know vulnerability found on IIS versions 4.0 and 5.0, where an attacker could bypass authorization schema and gain access to any file on the same drive as the web root directory due an issue on decoding mechanism. For more details about folder traversal vulnerability, see [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-0333  CVE 2001-0333].  
 
This example presents an old well-know vulnerability found on IIS versions 4.0 and 5.0, where an attacker could bypass authorization schema and gain access to any file on the same drive as the web root directory due an issue on decoding mechanism. For more details about folder traversal vulnerability, see [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-0333  CVE 2001-0333].  
  
Line 40: Line 43:
  
 
===Example 2 ===
 
===Example 2 ===
 
 
A double encoding URL can be used to exploit XSS attack in order to bypass a built-in XSS detection module. Depending on implementation, the first decoding process is performed by HTTP protocol and the resultant encoded URL will bypass XSS filter, since it has no mechanisms to improve detection. A simple example XSS would be:
 
A double encoding URL can be used to exploit XSS attack in order to bypass a built-in XSS detection module. Depending on implementation, the first decoding process is performed by HTTP protocol and the resultant encoded URL will bypass XSS filter, since it has no mechanisms to improve detection. A simple example XSS would be:
  
Line 78: Line 80:
  
 
</table>
 
</table>
 
  
 
Finally, the malicious double encoding code is:
 
Finally, the malicious double encoding code is:
Line 85: Line 86:
  
 
==External References ==
 
==External References ==
 
 
More examples about double encoding attacks can be found in:  
 
More examples about double encoding attacks can be found in:  
  
 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1945  
 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1945  
 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0054
 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0054
 
==Severity==
 
 
==Likelihood of exploit==
 
  
 
==Related Threats==
 
==Related Threats==
 
[[:Category: Command Execution]]
 
[[:Category: Command Execution]]
 
  
 
==Related Attacks==
 
==Related Attacks==
Line 103: Line 98:
 
*[[XSS Attacks]]
 
*[[XSS Attacks]]
 
*[[Path Traversal]]
 
*[[Path Traversal]]
 
  
 
==Related Vulnerabilities==
 
==Related Vulnerabilities==
Line 113: Line 107:
 
[[:Category:Input Validation]]
 
[[:Category:Input Validation]]
  
[[Category: Resource Manipulation]]
+
[[Category:Resource Manipulation]]
 
[[Category:Attack]]
 
[[Category:Attack]]

Revision as of 11:32, 5 November 2007

This is an Attack. To view all attacks, please see the Attack Category page.


Description

This attack technique consists of encode user request parameters twice in hexadecimal format in order to bypass security controls or cause unexpected behavior from application.

By using double encoding it’s possible to bypass security filters that only decode user input once, being the second decoding process executed by backend platform or modules that properly handle encoded data but don't have the corresponding security checks in place.

Attackers can inject double encoding in pathnames or query strings to bypass authentication schema and security filters in use by web application.

There are some common characters sets that are used in Web applications attacks. For example, in directory traversal attacks, it uses “../” (dot-dot-slash) , while in XSS attacks, it uses “<” and “>” characters. These characters give hexadecimal representation that differs from normal data.

For example, “../” (dot-dot-slash) characters represents %2E%2E%2f in hexadecimal representation. When the % symbol is encoded again, its representation in hexadecimal code is %25. The resultant from double encoding process ”../”(dot-dot-slash) would be %252E%252E%252F:

Hexadecimal encode of “../” represents "%2E%2E%2f"
Then encoding the “%” represents "%25"
Double encoding of “../” represents "%252E%252E%252F"


Severity

Medium to High

Likelihood of exploitation

High

Examples

Example 1

This example presents an old well-know vulnerability found on IIS versions 4.0 and 5.0, where an attacker could bypass authorization schema and gain access to any file on the same drive as the web root directory due an issue on decoding mechanism. For more details about folder traversal vulnerability, see CVE 2001-0333.

In this scenario, the victim has an published executable directory (e.g. cgi) that’s stored on the same partition of Windows system folder. An attacker could execute arbitrary commands on the web server by submitting the following URL:

Original URL:

http://victim/cgi/../../winnt/system32/cmd.exe?/c+dir+c:\

However, the application uses a security check filter that refuses requests containing characters like “../”. By double encoding the URL, it’s possible to bypass security the filter:

Double encoded URL:

http://victim/cgi/%252E%252E%252F%252E%252E%252Fwinnt/system32/cmd.exe?/c+dir+c:\ 

Example 2

A double encoding URL can be used to exploit XSS attack in order to bypass a built-in XSS detection module. Depending on implementation, the first decoding process is performed by HTTP protocol and the resultant encoded URL will bypass XSS filter, since it has no mechanisms to improve detection. A simple example XSS would be:

<script>alert('XSS')</script>

This malicious code could be inserted into a vulnerable application, resulting in a alert window with message “XSS”. However the web application can have a character filter such as “< “, “>” and “/”, since they are used to perform web application attacks. The attacker could use double encoding technique to bypass the filter and exploit client’s session. The encoding process for this Java script is:

Char Hex encode Then encoding '%' Double encode
“<” “%3C” “%25” “%253C”
“/” “%2F” “%25” “%252F”
“>” “%3E” “%25” “%253E”

Finally, the malicious double encoding code is:

%253Cscript%253Ealert('XSS')%253C%252Fscript%253E

External References

More examples about double encoding attacks can be found in:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1945 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0054

Related Threats

Category: Command Execution

Related Attacks

Related Vulnerabilities

Category: Input Validation

Related Countermeasures

Category:Input Validation