Lesson plan

HTTP parameter pollution

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

Back to article

Article summary

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

Key claims

No claims recorded.

Discussion questions

  1. Summarise the article in your own words. Which single claim would you verify first, and why?
  2. Which claim in this article is most likely to be revised as the sources update? How would you check its current status?
  3. If two sources disagreed about one of these facts, what would you need in order to trust one over the other?

Bibliography

No sources recorded.

Key claims and bibliography are generated from the same tracked claims and sources as the article page.