Jump to content

HTTP parameter pollution: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
 
Line 8: Line 8:
When they are passed multiple parameters with the same name, here is how various back ends behave.<ref name="owasp_hpp">{{cite web|title=WSTG - Latest:Testing for HTTP Parameter Pollution|url=https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution}}</ref>
When they are passed multiple parameters with the same name, here is how various back ends behave.<ref name="owasp_hpp">{{cite web|title=WSTG - Latest:Testing for HTTP Parameter Pollution|url=https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution}}</ref>
{| class="wikitable"
{| class="wikitable"
|+ Behaviour when "param" is passed the values "val1" & "val2"
|+ Behaviour

|-
|-
! Technology !! Parsing result !! Example
! Technology !! Parsing result !! Example

Latest revision as of 16:44, 5 September 2023

HTTP Parameter Pollution (HPP) is a web application vulnerability exploited by injecting encoded query string delimiters in already existing parameters. The vulnerability occurs if user input is not correctly encoded for output by a web application.[1] This vulnerability allows the injection of parameters into web application-created URLs. It was first brought forth to the public in 2009 by Stefano di Paola and Luca Carettoni, in the conference OWASP EU09 Poland.[1] The impact of such vulnerability varies, and it can range from "simple annoyance" to complete disruption of the intended behavior of a web application. Overriding HTTP parameters to alter a web application's behavior, bypassing input and access validation checkpoints, as well as other indirect vulnerabilities, are possible consequences of a HPP attack.[1]

There is no RFC standard on what should be done when it has passed multiple parameters. HPP could be used for cross channel pollution, bypassing CSRF protection and WAF input validation checks.[2]

Behaviour

[edit]

When they are passed multiple parameters with the same name, here is how various back ends behave.[3]

Behaviour when "param" is passed the values "val1" & "val2"
Technology Parsing result Example
ASP.NET/IIS All occurrences concatenated with a comma param=val1,val2
ASP/IIS All occurrences concatenated with a comma param=val1,val2
PHP/Apache Last occurrence only param=val2
PHP/Zeus Last occurrence only param=val2
JSP, Servlet/Apache Tomcat First occurrence only param=val1
JSP, Servlet/Oracle Application Server First occurrence only param=val1
JSP, Servlet/Jetty First occurrence only param=val1
IBM Lotus Domino Last occurrence only param=val2
IBM HTTP Server First occurrence only param=val1
mod_perl,libapreq2/Apache First occurrence only param=val1
Perl CGI/Apache First occurrence only param=val1
mod_wsgi (Python)/Apache First occurrence only param=val1
Python/Zope All occurrences in list(array) param=['val1','val2']

Types

[edit]

Client-side

[edit]
  • First Order / Reflected HPP[4]
  • Second Order / Stored HPP[4]
  • Third Order / DOM HPP[4]

Server-side

[edit]
  • Standard HPP[4]
  • Second Order HPP[4]

Prevention

[edit]

Proper input validation and awareness about web technology on HPP is protection against HTTP Parameter Pollution.[5]

See also

[edit]

References

[edit]
  1. ^ a b c Balduzzi et al. 2011, p. 2.
  2. ^ "HTTP Parameter Pollution Vulnerabilities in Web Applications" (PDF). 2011.
  3. ^ "WSTG - Latest:Testing for HTTP Parameter Pollution".
  4. ^ a b c d e Luca Carettoni; Stefano Di Paola. "HTTP Parameter Pollution" (PDF).
  5. ^ "How to Detect HTTP Parameter Pollution Attacks".

Bibliography

[edit]