Double Encoding - Revision history

Andrew Smith at 14:54, 11 November 2014

2014-11-11T14:54:03Z

Andrew Smith at 14:51, 11 November 2014

2014-11-11T14:51:12Z

MediaWiki spam cleanup: Reverting to last version not containing links to www.textorellirocaco.com

2009-05-27T18:29:54Z

Reverting to last version not containing links to www.textorellirocaco.com

MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp

2009-05-27T16:00:09Z

Reverting to last version not containing links to s1.shard.jp

Deleted user at 12:07, 26 May 2009

2009-05-26T12:07:38Z

Deleted user at 17:58, 22 May 2009

2009-05-22T17:58:28Z

KirstenS at 12:41, 7 April 2009

2009-04-07T12:41:21Z

KirstenS: /* Description */

2009-02-15T19:13:46Z

‎Description

KirstenS at 19:13, 15 February 2009

2009-02-15T19:13:22Z

KirstenS: /* Related Attacks */

2008-09-18T12:35:02Z

‎Related Attacks

← Older revision		Revision as of 14:54, 11 November 2014
Line 1:		Line 1:
−	{{~~Template:Attack~~}}	+	{{stub}}

	Last revision: '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''		Last revision: '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

← Older revision		Revision as of 14:51, 11 November 2014
Line 107:		Line 107:

	[[Category:Resource Manipulation]]		[[Category:Resource Manipulation]]
−	~~[[Category:Attack]]~~
	__NOTOC__		__NOTOC__

@@ Line 1: / Line 1: @@
 {{Template:Attack}}
@@ Line 9: / Line 8: @@
 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.
+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 [[Cross-site Scripting (XSS)|XSS]] attacks use â<â and â>â characters. These characters give a 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 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:
+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"
+* 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==
@@ Line 32: / Line 31: @@
 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 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:
+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:
@@ Line 38: / Line 37: @@
   <nowiki>http://victim/cgi/../../winnt/system32/cmd.exe?/c+dir+c:\</nowiki>
-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:
+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:
@@ Line 49: / Line 48: @@
   <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:
+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 >
@@ Line 61: / Line 60: @@
 <tr>
-<td colspan=30> â<â </td>
+<td colspan=30> “<” </td>
-<td colspan=40> â%3Câ </td>
+<td colspan=40> “%3C” </td>
-<td colspan=50%> â%25â </td>
+<td colspan=50%> “%25” </td>
-<td colspan=50%> â%253Câ </td>
+<td colspan=50%> “%253C” </td>
 </tr>
 <tr>
-<td colspan=30> â/â </td>
+<td colspan=30> “/” </td>
-<td colspan=40> â%2Fâ </td>
+<td colspan=40> “%2F” </td>
-<td colspan=50%> â%25â  </td>
+<td colspan=50%> “%25”  </td>
-<td colspan=50%> â%252Fâ </td>
+<td colspan=50%> “%252F” </td>
 </tr>
 <tr>
-<td colspan=30> â>â </td>
+<td colspan=30> “>” </td>
-<td colspan=40> â%3Eâ </td>
+<td colspan=40> “%3E” </td>
-<td colspan=50%> â%25â  </td>
+<td colspan=50%> “%25”  </td>
-<td colspan=50%> â%253Eâ </td>
+<td colspan=50%> “%253E” </td>
 </tr>

@@ Line 1: / Line 1: @@
 http://www.textorellirocaco.com
 {{Template:Attack}}
@@ Line 51: / Line 9: @@
 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.
+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 [[Cross-site Scripting (XSS)|XSS]] attacks use Ã¢ÂÂ<Ã¢ÂÂ and Ã¢ÂÂ>Ã¢ÂÂ characters. These characters give a 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 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:
+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"
+* 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==
@@ Line 74: / Line 32: @@
 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 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:
+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:
@@ Line 80: / Line 38: @@
   <nowiki>http://victim/cgi/../../winnt/system32/cmd.exe?/c+dir+c:\</nowiki>
-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:
+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:
@@ Line 91: / Line 49: @@
   <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:
+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 >
@@ Line 103: / Line 61: @@
 <tr>
-<td colspan=30> Ã¢ÂÂ<Ã¢ÂÂ </td>
+<td colspan=30> â<â </td>
-<td colspan=40> Ã¢ÂÂ%3CÃ¢ÂÂ </td>
+<td colspan=40> â%3Câ </td>
-<td colspan=50%> Ã¢ÂÂ%25Ã¢ÂÂ </td>
+<td colspan=50%> â%25â </td>
-<td colspan=50%> Ã¢ÂÂ%253CÃ¢ÂÂ </td>
+<td colspan=50%> â%253Câ </td>
 </tr>
 <tr>
-<td colspan=30> Ã¢ÂÂ/Ã¢ÂÂ </td>
+<td colspan=30> â/â </td>
-<td colspan=40> Ã¢ÂÂ%2FÃ¢ÂÂ </td>
+<td colspan=40> â%2Fâ </td>
-<td colspan=50%> Ã¢ÂÂ%25Ã¢ÂÂ  </td>
+<td colspan=50%> â%25â  </td>
-<td colspan=50%> Ã¢ÂÂ%252FÃ¢ÂÂ </td>
+<td colspan=50%> â%252Fâ </td>
 </tr>
 <tr>
-<td colspan=30> Ã¢ÂÂ>Ã¢ÂÂ </td>
+<td colspan=30> â>â </td>
-<td colspan=40> Ã¢ÂÂ%3EÃ¢ÂÂ </td>
+<td colspan=40> â%3Eâ </td>
-<td colspan=50%> Ã¢ÂÂ%25Ã¢ÂÂ  </td>
+<td colspan=50%> â%25â  </td>
-<td colspan=50%> Ã¢ÂÂ%253EÃ¢ÂÂ </td>
+<td colspan=50%> â%253Eâ </td>
 </tr>

@@ Line 1: / Line 1: @@
 http://www.textorellirocaco.com
 {{Template:Attack}}
@@ Line 9: / Line 51: @@
 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.
+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 [[Cross-site Scripting (XSS)|XSS]] attacks use â<â and â>â characters. These characters give a 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 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:
+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"
+* 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==
@@ Line 32: / Line 74: @@
 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 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:
+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:
@@ Line 38: / Line 80: @@
   <nowiki>http://victim/cgi/../../winnt/system32/cmd.exe?/c+dir+c:\</nowiki>
-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:
+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:
@@ Line 49: / Line 91: @@
   <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:
+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 >
@@ Line 61: / Line 103: @@
 <tr>
-<td colspan=30> â<â </td>
+<td colspan=30> Ã¢ÂÂ<Ã¢ÂÂ </td>
-<td colspan=40> â%3Câ </td>
+<td colspan=40> Ã¢ÂÂ%3CÃ¢ÂÂ </td>
-<td colspan=50%> â%25â </td>
+<td colspan=50%> Ã¢ÂÂ%25Ã¢ÂÂ </td>
-<td colspan=50%> â%253Câ </td>
+<td colspan=50%> Ã¢ÂÂ%253CÃ¢ÂÂ </td>
 </tr>
 <tr>
-<td colspan=30> â/â </td>
+<td colspan=30> Ã¢ÂÂ/Ã¢ÂÂ </td>
-<td colspan=40> â%2Fâ </td>
+<td colspan=40> Ã¢ÂÂ%2FÃ¢ÂÂ </td>
-<td colspan=50%> â%25â  </td>
+<td colspan=50%> Ã¢ÂÂ%25Ã¢ÂÂ  </td>
-<td colspan=50%> â%252Fâ </td>
+<td colspan=50%> Ã¢ÂÂ%252FÃ¢ÂÂ </td>
 </tr>
 <tr>
-<td colspan=30> â>â </td>
+<td colspan=30> Ã¢ÂÂ>Ã¢ÂÂ </td>
-<td colspan=40> â%3Eâ </td>
+<td colspan=40> Ã¢ÂÂ%3EÃ¢ÂÂ </td>
-<td colspan=50%> â%25â  </td>
+<td colspan=50%> Ã¢ÂÂ%25Ã¢ÂÂ  </td>
-<td colspan=50%> â%253Eâ </td>
+<td colspan=50%> Ã¢ÂÂ%253EÃ¢ÂÂ </td>
 </tr>

@@ Line 4: / Line 4: @@
 <br>
 [[Category:OWASP ASDR Project]]
 ==Description==

@@ Line 93: / Line 93: @@
 ==Related [[Attacks]]==
 * [[SQL Injection]]
-* [[Cross-site scripting]]
+* [[Cross-site Scripting (XSS)]]
 * [[Path Traversal]]