iaing1000
asked on
How to fix this security issue, possibly using URL encoding: CLIENT-SIDE HTTP PARAMETER POLLUTION (REFLECTED)
Hi,
As part of a security certification process we’re going through we’re required to fix this particular security issue with our website. The text, in the bold headed two paragraphs below, is that provided to us from the company doing the testing:
Client-side HTTP parameter pollution (reflected): Client-side HTTP parameter pollution (HPP) vulnerabilities arise when an application embeds user input in URLs in an unsafe manner. An attacker can use this vulnerability to construct a URL that, if visited by another application user, will modify URLs within the response by inserting additional query string parameters and sometimes overriding existing ones. This may result in links and forms having unexpected side effects. For example, it may be possible to modify an invitation form using HPP so that the invitation is delivered to an unexpected recipient. The security impact of this issue depends largely on the nature of the application functionality. Even if it has no direct impact on its own, an attacker may use it in conjunction with other vulnerabilities to escalate their overall severity.
Recommendation: Ensure that user input is URL-encoded before it is embedded in a URL.
Now, the only user input getting put into the URL would seem to be that from the results of searches (there’s a search box on each page). If I look for ‘Cheese’ the URL reads https://www.<oursitename>/?s=Cheese or if I search for ‘Bacon Roll’ it’d be https://www.<oursitename>/?s=Bacon+Ro
I’m still something of a newbie to web development & WP and we’ve been given this site to manage (background is SQL Server and Application development) and such I may be wrong that this is the issue, although I don’t see where else user input is coming from aside from the search box submissions. We’ve got through 23 of the 24 highlighted issues — variously edits to files such as httpd.conf, web-config.php, update to latest WP & plugins, SSL/TLS protocol changes and similar plus some edits to a functions.php file for a plugin we use and also the introduction of 2FA. This is the very last hurdle!!!
Thanks in advance
Iain
As part of a security certification process we’re going through we’re required to fix this particular security issue with our website. The text, in the bold headed two paragraphs below, is that provided to us from the company doing the testing:
Client-side HTTP parameter pollution (reflected): Client-side HTTP parameter pollution (HPP) vulnerabilities arise when an application embeds user input in URLs in an unsafe manner. An attacker can use this vulnerability to construct a URL that, if visited by another application user, will modify URLs within the response by inserting additional query string parameters and sometimes overriding existing ones. This may result in links and forms having unexpected side effects. For example, it may be possible to modify an invitation form using HPP so that the invitation is delivered to an unexpected recipient. The security impact of this issue depends largely on the nature of the application functionality. Even if it has no direct impact on its own, an attacker may use it in conjunction with other vulnerabilities to escalate their overall severity.
Recommendation: Ensure that user input is URL-encoded before it is embedded in a URL.
Now, the only user input getting put into the URL would seem to be that from the results of searches (there’s a search box on each page). If I look for ‘Cheese’ the URL reads https://www.<oursitename>/?s=Cheese or if I search for ‘Bacon Roll’ it’d be https://www.<oursitename>/?s=Bacon+Ro
I’m still something of a newbie to web development & WP and we’ve been given this site to manage (background is SQL Server and Application development) and such I may be wrong that this is the issue, although I don’t see where else user input is coming from aside from the search box submissions. We’ve got through 23 of the 24 highlighted issues — variously edits to files such as httpd.conf, web-config.php, update to latest WP & plugins, SSL/TLS protocol changes and similar plus some edits to a functions.php file for a plugin we use and also the introduction of 2FA. This is the very last hurdle!!!
Thanks in advance
Iain
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi, thanks for getting back on this.
It appears this issue is highlighted only for posts where comments are switched on (i.e. seen in the 'Discussions' screen option when editing). Once submitted the comment is posted awaiting moderation and the URL changes to something like:
www.<oursitename>/#comment
Totally agree with the fact that URL encoding itself shouldn't make any difference to whether things can be changed or nto, which is why the recommendation has puzzled me! Also, this is all in order to acheive CHECK certification rather than a PCI thing.
So, one answer is to switch comments off completely for all posts although it's likely they'll be requested to remain. What's the most secure way to handle comments, and what about the recommended URL-encoding of the resultant URL when the comment is posted?
Thanks again
Iain
It appears this issue is highlighted only for posts where comments are switched on (i.e. seen in the 'Discussions' screen option when editing). Once submitted the comment is posted awaiting moderation and the URL changes to something like:
www.<oursitename>/#comment
Totally agree with the fact that URL encoding itself shouldn't make any difference to whether things can be changed or nto, which is why the recommendation has puzzled me! Also, this is all in order to acheive CHECK certification rather than a PCI thing.
So, one answer is to switch comments off completely for all posts although it's likely they'll be requested to remain. What's the most secure way to handle comments, and what about the recommended URL-encoding of the resultant URL when the comment is posted?
Thanks again
Iain
Again, even with that URL, there is no security concern as long as your server-side script does nothing with the querystring. When a query string is preceded by a hash as in #comment-23 it is treated as a jump point, meaning that when the page loads it will automatically scroll to the element on the page with an ID of comment-23
<div id="comment-23" class="comment">
This is a comment
</div>
The data is not being used as input, so should be of no concern.
<div id="comment-23" class="comment">
This is a comment
</div>
The data is not being used as input, so should be of no concern.
ASKER
Apologies this question just seems to have been left hanging! Long long story but I wasn't in work for a while for an operation (all good now thankfully!) - funny thing is I'd not had a reminder from EE, and I've been back a while now. Just happened across this while looking for something else entirely.
ASKER
Thanks - just clearing up some old questions.
In the end we resolved this by way of explanation and our own custom summary with which the certification people were happy.
In the end we resolved this by way of explanation and our own custom summary with which the certification people were happy.
It seems a bit of a strange issue, because even if your querystring is URL encoded, it can still be changed just as easily as if it wasn't URL encoded. The real security concern is not doing any server-side sanitising / error checking with the query string.