Testing for HTTP Parameter pollution (OTG-INPVAL-004) - Revision history

Santosomar: Fixing broken link for the HPP Finder Chrome Plugin

2018-06-04T02:41:00Z

Fixing broken link for the HPP Finder Chrome Plugin

Nvhaver: /* Client-side HPP */

2014-12-01T17:22:51Z

‎Client-side HPP

Andrew Muller at 15:46, 31 July 2014

2014-07-31T15:46:20Z

Andrew Muller: Andrew Muller moved page Testing for HTTP Parameter pollution (OWASP-DV-004) to Testing for HTTP Parameter pollution (OTG-INPVAL-004)

2014-07-31T14:32:16Z

Andrew Muller moved page Testing for HTTP Parameter pollution (OWASP-DV-004) to Testing for HTTP Parameter pollution (OTG-INPVAL-004)

Jane O'Connor: Final edit

2014-05-18T10:21:49Z

Final edit

Luca Carettoni at 06:50, 26 August 2013

2013-08-26T06:50:24Z

Luca Carettoni at 06:26, 26 August 2013

2013-08-26T06:26:56Z

Show changes

Ben Walther at 15:19, 22 August 2013

2013-08-22T15:19:50Z

Ben Walther at 14:54, 22 August 2013

2013-08-22T14:54:39Z

Ben Walther at 17:09, 21 August 2013

2013-08-21T17:09:51Z

@@ Line 8: / Line 8: @@
-Current HTTP standards do not include guidance on how to interpret multiple input parameters with the same name. For instance, [http://www.ietf.org/rfc/rfc3986.txt RFC 3986] simply defines the term ''Query String'' as a series of field-value pairs and [http://www.ietf.org/rfc/rfc2396.txt  RFC 2396] defines classes of reversed and unreserved query string characters. Without a standard in place, web application components handle this edge case in a variety of ways (see the table below for details).
+Current HTTP standards do not include guidance on how to interpret multiple input parameters with the same name. For instance, [http://www.ietf.org/rfc/rfc3986.txt RFC 3986] simply defines the term ''Query String'' as a series of field-value pairs and [http://www.ietf.org/rfc/rfc2396.txt RFC 2396] defines classes of reversed and unreserved query string characters. Without a standard in place, web application components handle this edge case in a variety of ways (see the table below for details).
@@ Line 137: / Line 137: @@
 OWASP ZAP HPP Passive/Active Scanners [https://code.google.com/p/zap-extensions/wiki/V1Extensions]
-HPP Finder (Chrome Plugin) [https://chrome.google.com/webstore/detail/hpp-finder]
+HPP Finder (Chrome Plugin) [http://&#x20;https://chrome.google.com/webstore/detail/hpp-finder/nogojgcobcolombicplhimbbakkcmhio]
 == References ==

@@ Line 120: / Line 120: @@
 === Client-side HPP ===
 <br>
-Similarly to server-side HPP, manual testing is the only reliable technique to audit web applications in order to detect parameter pollution vulnerabilities affecting client-side components. While in the server-side variant the attacker leverages a vulnerable web application to access protected data or perform actions that either not permitted or not supposed to be executed, client-side attacks aim at subverting client-side components and technologies.
+Similarly to server-side HPP, manual testing is the only reliable technique to audit web applications in order to detect parameter pollution vulnerabilities affecting client-side components. While in the server-side variant the attacker leverages a vulnerable web application to access protected data or to perform actions that either not permitted or not supposed to be executed, client-side attacks aim at subverting client-side components and technologies.
@@ Line 132: / Line 132: @@
-In particular,  pay attention to responses having HPP vectors within <code>data</code>, <code>src</code>, <code>href</code> attributes or forms actions. Again, whether or not this default behavior reveals a potential vulnerability depends on the specific input validation, filtering and application business logic. In addition, it is important to notice that this vulnerability can also affect query string parameters used in XMLHttpRequest (XHR), runtime attribute creation and other plugin technologies (e.g. Adobe Flash’s flashvars variables).
+In particular, pay attention to responses having HPP vectors within <code>data</code>, <code>src</code>, <code>href</code> attributes or forms actions. Again, whether or not this default behavior reveals a potential vulnerability depends on the specific input validation, filtering and application business logic. In addition, it is important to notice that this vulnerability can also affect query string parameters used in XMLHttpRequest (XHR), runtime attribute creation and other plugin technologies (e.g. Adobe Flash’s flashvars variables).
 ==Tools==

@@ Line 2: / Line 2: @@
-== Brief Summary ==
+== Summary ==
 <br>
 Supplying multiple HTTP parameters with the same name may cause an application to interpret values in unanticipated ways. By exploiting these effects, an attacker may be able to bypass input validation, trigger application errors or modify internal variables values. As HTTP Parameter Pollution (in short ''HPP'') affects a building block of all web technologies, server and client side attacks exist.
 <br>
-== Description of the Issue ==
 Current HTTP standards do not include guidance on how to interpret multiple input parameters with the same name. For instance, [http://www.ietf.org/rfc/rfc3986.txt RFC 3986] simply defines the term ''Query String'' as a series of field-value pairs and [http://www.ietf.org/rfc/rfc2396.txt  RFC 2396] defines classes of reversed and unreserved query string characters. Without a standard in place, web application components handle this edge case in a variety of ways (see the table below for details).
@@ Line 76: / Line 76: @@
-== Black Box testing and example ==
+==How to Test==
-<br>
 Luckily, because the assignment of HTTP parameters is typically handled via the web application server, and not the application code itself, testing the response to parameter pollution should be standard across all pages and actions. However, as in-depth business logic knowledge is necessary, testing HPP requires manual testing. Automatic tools can only partially assist auditors as they tend to generate too many false positives. In addition, HPP can manifest itself in client-side and server-side components.
@@ Line 134: / Line 134: @@
 In particular,  pay attention to responses having HPP vectors within <code>data</code>, <code>src</code>, <code>href</code> attributes or forms actions. Again, whether or not this default behavior reveals a potential vulnerability depends on the specific input validation, filtering and application business logic. In addition, it is important to notice that this vulnerability can also affect query string parameters used in XMLHttpRequest (XHR), runtime attribute creation and other plugin technologies (e.g. Adobe Flash’s flashvars variables).
 == References ==
@@ Line 148: / Line 153: @@
 Automated Discovery of Parameter Pollution Vulnerabilities in Web Applications - Marco Balduzzi, Carmen Torrano Gimenez, Davide Balzarotti, Engin Kirda [http://www.iseclab.org/people/embyte/papers/hpp.pdf]

@@ Line 6: / Line 6: @@
 Supplying multiple HTTP parameters with the same name may cause an application to interpret values in unanticipated ways. By exploiting these effects, an attacker may be able to bypass input validation, trigger application errors or modify internal variables values. As HTTP Parameter Pollution (in short ''HPP'') affects a building block of all web technologies, server and client side attacks exist.
 <br>
 == Description of the Issue ==
-<br>
+Current HTTP standards do not include guidance on how to interpret multiple input parameters with the same name. For instance, [http://www.ietf.org/rfc/rfc3986.txt RFC 3986] simply defines the term ''Query String'' as a series of field-value pairs and [http://www.ietf.org/rfc/rfc2396.txt  RFC 2396] defines classes of reversed and unreserved query string characters. Without a standard in place, web application components handle this edge case in a variety of ways (see the table below for details).
-Current HTTP standards do not include guidance on how to interpret multiple input parameters with the same name. For instance, [http://www.ietf.org/rfc/rfc3986.txt RFC 3986] simply defines the term ''Query String'' as a series of field-value pairs and [http://www.ietf.org/rfc/rfc2396.txt  RFC 2396] defines classes of reversed and unreserved query string characters. Without a standard in place, web application components handle this edge case in a variety of ways (see the table below for details).
+By itself, this is not necessarily an indication of vulnerability. However, if the developer is not aware of the problem, the presence of duplicated parameters may produce an anomalous behavior in the application that can be potentially exploited by an attacker. As often in security, unexpected behaviors are a usual source of weaknesses that could lead to HTTP Parameter Pollution attacks in this case. To better introduce this class of vulnerabilities and the outcome of HPP attacks, it is interesting to analyze some real-life examples that have been discovered in the past.
 === Input Validation and filters bypass ===
 In 2009, immediately after the publication of the first research on HTTP Parameter Pollution, the technique received attention from the security community as a possible way to bypass web application firewalls.
 One of these flaws, affecting ''ModSecurity SQL Injection Core Rules'', represents a perfect example of the impedance mismatch between applications and filters.  The ModSecurity filter would correctly blacklist the following string: <code>select 1,2,3 from table</code>, thus blocking this example URL from being processed by the web server: <code>/index.aspx?page=select 1,2,3 from table</code>. However, by exploiting the concatenation of multiple HTTP parameters, an attacker could cause the application server to concatenate the string after the ModSecurity filter already accepted the input. As an example, the URL <code>/index.aspx?page=select 1&page=2,3</code> from table would not trigger the ModSecurity filter, yet the application layer would concatenate the input back into the full malicious string.
@@ Line 25: / Line 25: @@
 === Authentication bypass ===
 An even more critical HPP vulnerability was discovered in ''Blogger'', the popular blogging platform. The bug allowed malicious users to take ownership of the victim’s blog by using the following HTTP request:
@@ Line 33: / Line 32: @@
 security_token=attackertoken&blogID=attackerblogidvalue&blogID=victimblogidvalue&authorsList=goldshlager19test%40gmail.com(attacker email)&ok=Invite
 </code>
 The flaw resided in the authentication mechanism used by the web application, as the security check was performed on the first <code>blogID</code> parameter, whereas the actual operation used the second occurrence.
@@ Line 40: / Line 40: @@
 <br>
 The following table illustrates how different web technologies behave in presence of multiple occurrences of the same HTTP parameter.
 Given the URL and querystring: <code>http://example.com/?color=red&color=blue</code>
@@ Line 73: / Line 74: @@
 |}
 (source: [[Media:AppsecEU09_CarettoniDiPaola_v0.8.pdf]] )
-<br>
 == Black Box testing and example ==
 <br>
 Luckily, because the assignment of HTTP parameters is typically handled via the web application server, and not the application code itself, testing the response to parameter pollution should be standard across all pages and actions. However, as in-depth business logic knowledge is necessary, testing HPP requires manual testing. Automatic tools can only partially assist auditors as they tend to generate too many false positives. In addition, HPP can manifest itself in client-side and server-side components.
 === Server-side HPP ===
@@ Line 82: / Line 85: @@
 To test for HPP vulnerabilities, identify any form or action that allows user-supplied input. Query string parameters in HTTP GET requests are easy to tweak in the navigation bar of the browser. If the form action submits data via POST, the tester will need to use an intercepting proxy to tamper with the POST data as it is sent to the server.
 Having identified a particular input parameter to test, one can edit the GET or POST data by intercepting the request, or change the query string after the response page loads. To test for HPP vulnerabilities simply append the same parameter to the GET or POST data but with a different value assigned.
 For example: if testing the <code>search_string</code> parameter in the query string, the request URL would include that parameter name and value.
 <br><code>http://example.com/?search_string=kittens</code>
 <br>
 The particular parameter might be hidden among several other parameters, but the approach is the same; leave the other parameters in place and append the duplicate.
 <br>
@@ Line 95: / Line 100: @@
 <br>
 and submit the new request.
 Analyze the response page to determine which value(s) were parsed. In the above example, the search results may show <code>kittens</code>, <code>puppies</code>, some combination of both (<code>kittens,puppies</code> or <code>kittens~puppies</code> or <code>['kittens','puppies']</code>), may give an empty result, or error page.
 <br>
 This behavior, whether using the first, last, or combination of input parameters with the same name, is very likely to be consistent across the entire application. Whether or not this default behavior reveals a potential vulnerability depends on the specific input validation and filtering specific to a particular application. As a general rule: if existing input validation and other security mechanisms are sufficient on single inputs, and if the server assigns only the first or last polluted parameters, then parameter pollution does not reveal a vulnerability. If the duplicate parameters are concatenated, different web application components use different occurrences or testing generates an error, there is an increased likelihood of being able to use parameter pollution to trigger security vulnerabilities.
@@ Line 106: / Line 113: @@
 # Send a new request combining step (1) and (2). Again, save the HTTP response. E.g. <code>page?par1=val1&par1=HPP_TEST1</code>
 # Compare the responses obtained during all previous steps. If the response from (3) is different from (1) and the response from (3) is also different from (2), there is an impedance mismatch that may be eventually abused to trigger HPP vulnerabilities.
 Crafting a full exploit from a parameter pollution weakness is beyond the scope of this text. See the references for examples and details.
 === Client-side HPP ===
 <br>
 Similarly to server-side HPP, manual testing is the only reliable technique to audit web applications in order to detect parameter pollution vulnerabilities affecting client-side components. While in the server-side variant the attacker leverages a vulnerable web application to access protected data or perform actions that either not permitted or not supposed to be executed, client-side attacks aim at subverting client-side components and technologies.
-<br>
 To test for HPP client-side vulnerabilities, identify any form or action that allows user input and shows a result of that input back to the user. A search page is ideal, but a login box might not work (as it might not show an invalid username back to the user).
 Similarly to server-side HPP, pollute each HTTP parameter with <code>%26HPP_TEST</code> and look for ''url-decoded'' occurrences of the user-supplied payload:
@@ Line 120: / Line 131: @@
 * … and others
 In particular,  pay attention to responses having HPP vectors within <code>data</code>, <code>src</code>, <code>href</code> attributes or forms actions. Again, whether or not this default behavior reveals a potential vulnerability depends on the specific input validation, filtering and application business logic.
-In addition, it is important to notice that this vulnerability can also affect query string parameters used in XMLHttpRequest (XHR), runtime attribute creation and other plugin technologies (e.g. Adobe Flash’s flashvars variables).
+In particular,  pay attention to responses having HPP vectors within <code>data</code>, <code>src</code>, <code>href</code> attributes or forms actions. Again, whether or not this default behavior reveals a potential vulnerability depends on the specific input validation, filtering and application business logic. In addition, it is important to notice that this vulnerability can also affect query string parameters used in XMLHttpRequest (XHR), runtime attribute creation and other plugin technologies (e.g. Adobe Flash’s flashvars variables).
-−
 == References ==
 '''Whitepapers'''<br>

@@ Line 9: / Line 9: @@
 <br>
-Current HTTP standards do not include guidance on how to interpret multiple input parameters with the same name. For instance, [http://www.ietf.org/rfc/rfc3986.txt RFC 3986] simply defines the ''Query String'' as a series of field-value pairs and [http://www.ietf.org/rfc/rfc2396.txt  RFC 2396] defines classes of reversed and unreserved characters. Without a standard in place, web application components handle this edge case in a variety of ways (see the table below for details).
+Current HTTP standards do not include guidance on how to interpret multiple input parameters with the same name. For instance, [http://www.ietf.org/rfc/rfc3986.txt RFC 3986] simply defines the term ''Query String'' as a series of field-value pairs and [http://www.ietf.org/rfc/rfc2396.txt  RFC 2396] defines classes of reversed and unreserved query string characters. Without a standard in place, web application components handle this edge case in a variety of ways (see the table below for details).
 By itself, this is not necessarily an indication of vulnerability. However, if the developer is not aware of the problem, the presence of duplicated parameters may produce an anomalous behavior in the application that can be potentially exploited by an attacker. As often in security, unexpected behaviors are a usual source of weaknesses that could lead to HTTP Parameter Pollution attacks in this case.
-To better introduce this class of vulnerabilities and the outcome of HPP attacks, it is interesting to analyze some real-life vulnerabilities that have been discovered in the past.
+To better introduce this class of vulnerabilities and the outcome of HPP attacks, it is interesting to analyze some real-life examples that have been discovered in the past.
 === Input Validation and filters bypass ===
 <br>
-In 2009, immediately after the publication of the first research on HTTP Parameter Pollution, this technique received large attention from the security community as a possible way to bypass web application firewalls.
+In 2009, immediately after the publication of the first research on HTTP Parameter Pollution, the technique received attention from the security community as a possible way to bypass web application firewalls.
 One of these flaws, affecting ''ModSecurity SQL Injection Core Rules'', represents a perfect example of the impedance mismatch between applications and filters.  The ModSecurity filter would correctly blacklist the following string: <code>select 1,2,3 from table</code>, thus blocking this example URL from being processed by the web server: <code>/index.aspx?page=select 1,2,3 from table</code>. However, by exploiting the concatenation of multiple HTTP parameters, an attacker could cause the application server to concatenate the string after the ModSecurity filter already accepted the input. As an example, the URL <code>/index.aspx?page=select 1&page=2,3</code> from table would not trigger the ModSecurity filter, yet the application layer would concatenate the input back into the full malicious string.
@@ Line 34: / Line 34: @@
 </code>
-The flaw resided in the authentication mechanism used by the web application, as the validation was performed on the first parameter, whereas the actual operation used the second occurrence.
+The flaw resided in the authentication mechanism used by the web application, as the security check was performed on the first <code>blogID</code> parameter, whereas the actual operation used the second occurrence.
 <br>
@@ Line 76: / Line 76: @@
 == Black Box testing and example ==
 <br>
-Luckily, because the assignment of HTTP parameters is typically handled via the web application server, and not the application code itself, testing the response to parameter pollution should be standard across all pages and actions. However, as in-depth business logic knowledge is required, testing HPP requires manual testing and automatic tools can only partially assist auditors. In addition, HPP can manifest itself in client-side and server-side components.
+Luckily, because the assignment of HTTP parameters is typically handled via the web application server, and not the application code itself, testing the response to parameter pollution should be standard across all pages and actions. However, as in-depth business logic knowledge is necessary, testing HPP requires manual testing. Automatic tools can only partially assist auditors as they tend to generate too many false positives. In addition, HPP can manifest itself in client-side and server-side components.
 === Server-side HPP ===
@@ Line 98: / Line 98: @@
 Analyze the response page to determine which value(s) were parsed. In the above example, the search results may show <code>kittens</code>, <code>puppies</code>, some combination of both (<code>kittens,puppies</code> or <code>kittens~puppies</code> or <code>['kittens','puppies']</code>), may give an empty result, or error page.
 <br>
-This behavior, whether using the first, last, or combination of input parameters with the same name, is very likely to be consistent across the entire application. Whether or not this default behavior reveals a potential vulnerability depends on the specific input validation and filtering specific to a particular application. As a general rule: if existing input validation and other security mechanisms are sufficient on single inputs, and if the server assigns only the first or last polluted parameters, then parameter pollution does not reveal a vulnerability. If the duplicate parameters are concatenated, different web application components use different occurrences or testing generate an error, there is an increased likelihood of being able to use parameter pollution to trigger security vulnerabilities.
+This behavior, whether using the first, last, or combination of input parameters with the same name, is very likely to be consistent across the entire application. Whether or not this default behavior reveals a potential vulnerability depends on the specific input validation and filtering specific to a particular application. As a general rule: if existing input validation and other security mechanisms are sufficient on single inputs, and if the server assigns only the first or last polluted parameters, then parameter pollution does not reveal a vulnerability. If the duplicate parameters are concatenated, different web application components use different occurrences or testing generates an error, there is an increased likelihood of being able to use parameter pollution to trigger security vulnerabilities.
@@ Line 104: / Line 104: @@
 # Submit an HTTP request containing the standard parameter name and value, and record the HTTP response. E.g. <code>page?par1=val1</code>
 # Replace the parameter value with a tampered value, submit and record the HTTP response. E.g. <code>page?par1=HPP_TEST1</code>
-# Send a new request combining step (1) and (2). Again, record the HTTP responses. E.g. <code>page?par1=val1&par1=HPP_TEST1</code>
+# Send a new request combining step (1) and (2). Again, save the HTTP response. E.g. <code>page?par1=val1&par1=HPP_TEST1</code>
 # Compare the responses obtained during all previous steps. If the response from (3) is different from (1) and the response from (3) is also different from (2), there is an impedance mismatch that may be eventually abused to trigger HPP vulnerabilities.
@@ Line 111: / Line 111: @@
 === Client-side HPP ===
 <br>
-Similarly to server-side HPP, manual testing is the only reliable technique to audit web applications in order to detect parameter pollution vulnerabilities affecting client-side components. While in the server-side variant the attacker leverages a vulnerable web application to access protected data or perform actions that either not permitted or not supposed to be executed, client-side attacks aims at tampering client-side components and technologies.
+Similarly to server-side HPP, manual testing is the only reliable technique to audit web applications in order to detect parameter pollution vulnerabilities affecting client-side components. While in the server-side variant the attacker leverages a vulnerable web application to access protected data or perform actions that either not permitted or not supposed to be executed, client-side attacks aim at subverting client-side components and technologies.
 <br>
 To test for HPP client-side vulnerabilities, identify any form or action that allows user input and shows a result of that input back to the user. A search page is ideal, but a login box might not work (as it might not show an invalid username back to the user).

← Older revision	Revision as of 14:32, 31 July 2014
(No difference)

@@ Line 74: / Line 74: @@
 <br>
 <br>
-Analyze the response page to determine which value(s) were parsed. In the above example, the search results may show <code>kittens</code>, <code>puppies</code>, some combination of both (<code>kittens,puppies</code> or <code>kittens~puppies</code> or <code> ['kittens','puppies']), may give an empty result, or error page.
+Analyze the response page to determine which value(s) were parsed. In the above example, the search results may show <code>kittens</code>, <code>puppies</code>, some combination of both (<code>kittens,puppies</code> or <code>kittens~puppies</code> or <code>['kittens','puppies']</code>), may give an empty result, or error page.
 <br>
 This behavior, whether using the first, last, or combination of input parameters with the same name, is very likely to be consistent across the entire application. Whether or not this default behavior reveals a potential vulnerability depends on the specific input validation and filtering specific to a particular application. As a general rule: if existing input validation methods are sufficient on single inputs, and if the server assigns only the first or last polluted parameters, then parameter pollution does not reveal a vulnerability. If the duplicate parameters are concatenated or generate an error, there is an increased likelihood of being able to use parameter pollution to bypass regular input validation.
 <br>
 == References ==
 '''Whitepapers'''<br>
-...<br>
+HTTP Parameter Pollution - Luca Carettoni, Stefano di Paola - https://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf
 '''Tools'''<br>
 ...<br>

@@ Line 53: / Line 53: @@
 <br>
 == Black Box testing and example ==
-'''Testing for Topic X vulnerabilities:''' <br>
+<br>
-...<br>
+Luckily, because the assignment of HTTP parameters is typically handled via the web application server, and not the application code itself, testing the response to parameter pollution should be standard across all pages and actions.
-'''Result Expected:'''<br>
+<br>
-...<br><br>
+To test for vulnerability, identify any form or action that allows user input and shows a result of that input back to the user. A search page is ideal, but a login box might not work (as it might not show an invalid username back to the user). Query string parameters are easy to tweak in the navigation bar itself. If the form action submits data via POST, the tester will need to use an intercepting proxy to tamper with the POST data as it is sent to the server.
 == References ==
 '''Whitepapers'''<br>

@@ Line 18: / Line 18: @@
 <br>
+===Expected Behavior by Application Server===
 Given the URL and querystring: <code>http://example.com/?color=red&color=blue</code>
 {|