HTTP parameter pollution: Difference between revisions

Revision as of 17:21, 12 July 2020

Latest revision as of 16:44, 5 September 2023

(30 intermediate revisions by 12 users not shown)

Line 1:

{{short description|Web security vulnerability}}

'''HTTP Parameter Pollution''' or HPP in short is a vulnerability that occurs due to passing of multiple parameters having same name. There is no RFC standard on what should be done when passed multiple parameters. This vulnerability was first discovered in 2009. <!-- by whom, if anyone knows they can update --><ref name="owasp_hpp">{{cite web|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|title=WSTG - Latest:Testing for HTTP Parameter Pollution}}</ref>. HPP could be used for cross channel pollution, bypassing CSRF protection and WAF input validation checks.<ref>{{cite web|url=http://www.madlab.it/slides/BHEU2011/whitepaper-bhEU2011.pdf|title=HTTP Parameter Pollution Vulnerabilities in Web Applications|date=2011}}</ref>

{{HTTP}}

'''HTTP Parameter Pollution''' ('''HPP''') is a [[web application]] [[Vulnerability (computing)|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.{{Sfn|Balduzzi|Torrano-Gimenez|Carmen|Kirda|2011|p=2}} 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.{{Sfn|Balduzzi|Torrano-Gimenez|Carmen|Kirda|2011|p=2}} 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.{{Sfn|Balduzzi|Torrano-Gimenez|Carmen|Kirda|2011|p=2}}

There is no [[Request for Comments|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 [[Web application firewall|WAF]] input validation checks.<ref>{{cite web|url=http://www.madlab.it/slides/BHEU2011/whitepaper-bhEU2011.pdf|title=HTTP Parameter Pollution Vulnerabilities in Web Applications|date=2011}}</ref>

==Behaviour==

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"

|+ 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==

===Client-side===

* First Order / Reflected HPP<ref name="owasp_hpp_paper">{{cite web|url=https://owasp.org/www-pdf-archive/AppsecEU09_CarettoniDiPaola_v0.8.pdf|title=HTTP Parameter Pollution|author1=Luca Carettoni |author2=Stefano Di Paola }}</ref>

* Second Order / Stored HPP<ref name="owasp_hpp_paper" />

* Third Order / DOM HPP<ref name="owasp_hpp_paper" />

===Server-side===

* Standard HPP<ref name="owasp_hpp_paper" />

* Second Order HPP<ref name="owasp_hpp_paper" />

==Prevention==

Proper input validation and awareness about web technology on HPP is protection against HTTP Parameter Pollution.<ref>{{cite web|url=https://www.acunetix.com/blog/whitepaper-http-parameter-pollution|title=How to Detect HTTP Parameter Pollution Attacks}}</ref>

==See Alsoalso==

*[[HTTP response splitting]]

*[[HTTP request smuggling]]

==See Also==

*[[HTTP_response_splitting]]

== References ==

{{reflist}}

<references/>

[[Category:Hypertext Transfer Protocol]]

[[Category:Internet security]]

[[Category:Computer security exploits]]

== Bibliography ==

* {{Cite conference|last1=Balduzzi|first1=Marco|last2=Torrano-Gimenez|first2=Carmen|last3=Balzarotti|first3=Davide|last4=Kirda|first4=Engin|date=2011|title=Automated Discovery of Parameter Pollution Vulnerabilities in Web Applications|url=https://www.researchgate.net/publication/221655534|conference=Proceedings of the Network and Distributed System Security Symposium, NDSS 2011|ref=CITEREFBalduzziTorrano-GimenezCarmenKirda2011|via=[[ResearchGate]]}}

{{Web-stub}}