HTTP parameter pollution: Difference between revisions

Revision as of 17:49, 12 July 2020

Latest revision as of 16:44, 5 September 2023

(19 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 [[Request_for_Comments|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 [[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>

{{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>

When passed multiple parameters with same name, here is how backend behaves

{| class="wikitable"

|+ Behaviour when "param" is passed the values "val1" & "val2"

|+ Behaviour

|-

! Technology !! Parsing result !! Example

Line 12 ⟶ 17:

| ASP/IIS || All occurrences concatenated with a comma || param=val1,val2

|-

| PHP/Apache || Last occurenceoccurrence only || param=val2

|-

| PHP/Zeus || Last occurenceoccurrence only || param=val2

|-

| JSP, Servlet/Apache Tomcat || First occurenceoccurrence only || param=val1

|-

| JSP, Servlet/Oracle Application Server || First occurenceoccurrence only || param=val1

|-

| JSP, Servlet/Jetty || First occurenceoccurrence only || param=val1

|-

| IBM Lotus Domino ||Last occurrence only || param=val2

|-

| IBM HTTP Server || First occurenceoccurrence only || param=val1

|-

| mod_perl,libapreq2/Apache|| First occurenceoccurrence only || param=val1

|-

| Perl CGI/Apache || First occurenceoccurrence only || param=val1

|-

| mod_wsgi (Python)/Apache || First occurenceoccurrence only || param=val1

|-

| Python/Zope || All occurencesoccurrences in list(array) || param=['val1','val2']

|}

<ref name="owasp_hpp" />

==Types==

===Client Sided HPP<ref name="owasp_hpp" />-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|authorsauthor1=Luca Carettoni and |author2=Stefano Di Paola }}</ref>

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

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

===Server Sided HPP<ref name-side="owasp_hpp" />==

* 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 response splitting]]

*[[HTTP request smuggling]]

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