Difference between revisions of "Double Encoding"

From OWASP
Jump to: navigation, search
(Reverting to last version not containing links to www.textorellirocaco.com)
 
(33 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
{{Template:Attack}}
 
{{Template:Attack}}
  
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
+
Last revision: '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 +
<br>
 +
[[Category:OWASP ASDR Project]]
  
 
==Description==
 
==Description==
 +
This attack technique consists of encoding user request parameters twice in hexadecimal format in order to bypass security controls or cause unexpected behavior from the application. It's possible because the webserver accepts and processes client requests in many encoded forms.
  
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. 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.
 
+
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.
+
Attackers can inject double encoding in pathnames or query strings to bypass the authentication schema and security filters in use by the 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.  
+
There are some common characters sets that are used in Web applications attacks. For example, [[Path Traversal]] attacks use “../” (dot-dot-slash) , while [[Cross-site Scripting (XSS)|XSS]] attacks use “<” and “>” characters. These characters give a 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:
+
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:
 
   
 
   
Hexadecimal encode of “../” represents "%2E%2E%2f"
+
* The hexadecimal encoding of “../” represents "%2E%2E%2f"
  
Then encoding the “%” represents "%25"
+
* Then encoding the “%” represents "%25"
 
+
Double encoding of “../” represents "%252E%252E%252F"
+
  
 +
* Double encoding of “../” represents "%252E%252E%252F"
  
 
==Risk Factors==
 
==Risk Factors==
 
+
TBD
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this attack likely or unlikely to actually happen
+
[[Category:FIXME|need content]]
* You can mention the likely technical impact of an attack
+
* The [business impact] of an attack is probably conjecture, leave it out unless you're sure
+
 
+
  
 
==Examples==
 
==Examples==
  
 
===Example 1 ===
 
===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-known vulnerability found in IIS versions 4.0 and 5.0, where an attacker could bypass an authorization schema and gain access to any file on the same drive as the web root directory due to an issue with the 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].  
  
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:  
+
In this scenario, the victim has a published executable directory (e.g. cgi) that’s stored on the same partition as the Windows system folder. An attacker could execute arbitrary commands on the web server by submitting the following URL:  
  
 
Original URL:
 
Original URL:
Line 47: Line 44:
  
 
===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 encoded URL can be used to perform an XSS attack in order to bypass a built-in XSS detection module. Depending on the implementation, the first decoding process is performed by HTTP protocol and the resultant encoded URL will bypass the XSS filter, since it has no mechanisms to improve detection. A simple example XSS would be:
  
 
  <script>alert('XSS')</script>
 
  <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:
+
This malicious code could be inserted into a vulnerable application,  resulting in an alert window with the message “XSS”. However, the web application can have a character filter which prohibits characters such as “< “, “>” and “/”, since they are used to perform web application attacks. The attacker could use a double encoding technique to bypass the filter and exploit the client’s session. The encoding process for this Java script is:
  
 
<table >
 
<table >
Line 88: Line 85:
  
 
  %253Cscript%253Ealert('XSS')%253C%252Fscript%253E
 
  %253Cscript%253Ealert('XSS')%253C%252Fscript%253E
 
  
 
==Related [[Threat Agents]]==
 
==Related [[Threat Agents]]==
 
+
* [[Internal software developer]]
[[:Category: Command Execution]]
+
 
+
  
 
==Related [[Attacks]]==
 
==Related [[Attacks]]==
 
+
* [[SQL Injection]]
*[[SQL Injection]]
+
* [[Cross-site Scripting (XSS)]]
*[[XSS Attacks]]
+
* [[Path Traversal]]
*[[Path Traversal]]
+
 
+
  
 
==Related [[Vulnerabilities]]==
 
==Related [[Vulnerabilities]]==
 
+
* TBD
[[:Category: Input Validation]]
+
 
+
 
+
  
 
==Related [[Controls]]==
 
==Related [[Controls]]==
 
+
* [[:Category:Input Validation]]
* [[Control 1]]
+
* [[Control 2]]
+
 
+
Note: contents of "Avoidance and Mitigation" and "Countermeasure" Sections should be placed here
+
 
+
  
 
==References==
 
==References==
 +
* 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-1945
 
 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0054
 
  
  
[[:Category:Input Validation]]
 
 
[[Category:Resource Manipulation]]
 
[[Category:Resource Manipulation]]
 
[[Category:Attack]]
 
[[Category:Attack]]
 
__NOTOC__
 
__NOTOC__

Latest revision as of 13:29, 27 May 2009

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


Last revision: 05/27/2009

Description

This attack technique consists of encoding user request parameters twice in hexadecimal format in order to bypass security controls or cause unexpected behavior from the application. It's possible because the webserver accepts and processes client requests in many encoded forms.

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.

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

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

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:

  • The hexadecimal encoding of “../” represents "%2E%2E%2f"
  • Then encoding the “%” represents "%25"
  • Double encoding of “../” represents "%252E%252E%252F"

Risk Factors

TBD

Examples

Example 1

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

In this scenario, the victim has a published executable directory (e.g. cgi) that’s stored on the same partition as the 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 encoded URL can be used to perform an XSS attack in order to bypass a built-in XSS detection module. Depending on the implementation, the first decoding process is performed by HTTP protocol and the resultant encoded URL will bypass the 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 an alert window with the message “XSS”. However, the web application can have a character filter which prohibits characters such as “< “, “>” and “/”, since they are used to perform web application attacks. The attacker could use a double encoding technique to bypass the filter and exploit the 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

Related Threat Agents

Related Attacks

Related Vulnerabilities

  • TBD

Related Controls

References