If a REST endpoint (http://example.com) reads the p query parameter and pass it along to another endpoint:


I will be able to exploit it by appending content after p: http://example.com?p=a%26admin=true, which will cause it to make a request to http://example.com/api2?p=a&admin=true (%26 is decoded to & by the server), which will result in an exploit if the /api2 endpoint reads the admin parameter.

However, if I use HTML Purifier on $_GET['p'], it will convert & into &, which will break the attack unless api2 reads amp;admin (which is not likely in practice).

Does that mean the escape of & into & will effectively prevent the exploit? Why does this page warn us to watch out for &HPP_TEST then?

  • I fail to understand the question. HTML Purifier is used to sanitize user provided HTML before it gets included in some HTML page in order to protect client against XSS or similar. HTTP parameter pollution is done by calling a specifically prepared URL in order to confuse parameter checking by the server. HTML purifying cannot be applied against HTTP parameter pollution simply because there is no HTML involved in the latter. – Steffen Ullrich Nov 17 at 9:02
  • Also, calling i.e. HTML purifier on some URL makes no sense since the URL is no HTML either. It might even garble the URL, i.e. transform query?foo=1&bar=2 to query?foo=1&bar=2 which will then result in parameter amp;bar=2 instead of bar=2 – Steffen Ullrich Nov 17 at 9:06
  • It's not called against the entire url, only the query parameter purify($_GET['p']), which effectively prevent against parameter pollution by ensuring additional parameters are not added when it's only expecting a single one. – Avery235 Nov 17 at 9:09
  • @SteffenUllrich I think you should make that an answer instead of a comment. – Jeroen - IT Nerdbox Nov 17 at 9:09

HTTP parameter pollution is the process of manipulating a URL in order to bypass parameter validation at the server or WAF. It is for example done by adding one parameter again, i.e. making the query string foo=1&bar=2 to foo=1&bar=2&bar=bad-value.

Note that a polluted URL is still a valid URL and that it might even be intended that way, for example by using web form with multiple input fields having the same field name. Because of this any kind of HTTP parameter pollution protection needs to know what kind of URL or parameters are actually expected.

The use case for HTML purifier is a completely different one: sanitize user-provided HTML before it gets included in some server generated HTML. A HTML purifier has has no idea of how the valid URL in the context of the application should look like and thus cannot help to protect against HTTP parameter pollution.

But using it could actually make the problem worse: for example if the query string of the URL has the parameters foo=1&bar=2 converting this to HTML will result in foo=1&bar=2 which will result in getting a parameter amp;bar=2 extracted instead of the expected bar=2.

  • There is another kind of parameter pollution as I highlighted in the post: foo=1%26bar=2, $_GET('foo') will read it as foo=1&bar=2 (bar=2 is unintended), but with purify($_GET('foo')) it'll be read as foo=1&bar=2, which is safe. – Avery235 Nov 17 at 9:25
  • @Avery235: A HTML purifier will not change foo=1%26bar=2 to foo=1&bar=2. If it would do this it would actually break the intended value for the parameter foo which is 1&bar=2, i.e. foo=%26a=1&bar=2 should result in foo being &a=1 and bar being 2 and not foo being empty, a being 1and bar being 2. There is a valid reason to URL-encode '&', namely to distinguish it from the parameter separator &. BTW, you might try your input here. – Steffen Ullrich Nov 17 at 9:44
  • That was not my claim. I'm saying the purifier will change foo=1&bar=2 into foo=1&bar=2. The extra bar=2 is injected by the attacker, but rendered harmless by the purifier (as it's now amp;bar=2). – Avery235 Nov 17 at 9:48
  • @Avery235: I know understand what you mean. You essentially misuse HTML purifier in order to convert & into something else in the hope that the result will not only break the parameter pollution (it does, at least if the parameter you expect does not start with amp; itself) but also not cause any harmful side effects due to some unexpected parameters (this depends on your specific application). Anyway, I think this is a misuse of what HTML purifier is intended. It would be much better just to check for an & in the parameter and in this case abort the processing due to invalid input. – Steffen Ullrich Nov 17 at 10:38
  • I don't intend to do this in an actual app. This is a school assignment in which we are asked to describe why there is a HPP vulnerability, which I believe there isn't due to the use of purify. Well I guess from an academic standpoint you could claim that the other endpoint might be specifically reading amp;bar... – Avery235 Nov 17 at 11:54

The reason OWASP warns to look for &HPP_TEST is because it is a symptom of CLIENT-SIDE hpp vulnerability. The attack you are describing is against SERVER-SIDE hpp. These are two entirely different things.

So what is client-side hpp? Consider if I send to you a link such as:


Now the site will generate html for that link. For example it might have <a> tags that depend on the parameters. If the site isn't vulnerable it might send back something harmless like

<a href="http://www.example.com/showMessage?name=avery%26action=delete">View</a>

But if the site is vulnerable it might instead send back html like either:

<a href="http://www.example.com/showMessage?name=avery&action=delete">View</a>

<a href="http://www.example.com/showMessage?name=avery&amp;action=delete">View</a>

So what's happened is the server has been manipulated into creating a link that has extra parameters. Now if you use www.example as you normally would, you might click on the link to find you've somehow been tricked into deleting your own data. OWASP is basically warning you to check if your server creates this sort of HTML from URL parameters.

As for if it is secure to use HTML purifier as a way to prevent against server-side hpp; I will say that yes it will work for your one case but it isn't that great a solution as it means you'll never be able to create any functions requiring more than one parameter. It is better to do proper URL encoding and input validation.

  • Sounds like a pretty redundant attack. You could have just sent me example.com/showMessage?name=avery&action=delete directly (instead of example.com?name=avery%26action=delete). – Avery235 Nov 17 at 11:48
  • The example is the simplest <a> tag to demonstrate the concept. The real danger is that it is easy to hide the fact that the website is compromised and because it is the user that initiates the action. This allows an attacker to bypass things such as authentication controls and CSRF protections. It's also possible to contaminate POST calls or other complicated client-sided ajax in which you can't just send a bad link directly. – AlphaD Nov 17 at 14:52
  • Anyway the point is the part of the OWASP docs you ask about is referring to client-side HPP. – AlphaD Nov 17 at 15:11

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.