4

I'm currently running vulnerability scans against my application, which is based on Drupal. One "High" vulnerability is HTTP Parameter Pollution (HPP), and it has to do with pages that make use of drupal's theme_pager().

I know that it could indeed be (and probably is) a false-positive, but I need to be able to understand why it isn't a vulnerability so that I can remediate the scanning report. I'm hoping that someone with more security experience than I can help.

The found vulnerability is as follows (I'll use drupal.org in this example):

The actual scan output was as follows:

Vulnerability description This script is possibly vulnerable to HTTP Parameter Pollution > attacks.

HPP attacks consist of injecting encoded query string delimiters into other existing parameters. If the web application does not properly sanitize the user input, a malicious user can compromise the logic of the application to perform either clientside or server-side attacks.

This vulnerability affects /. Discovered by: Scripting (HTTP_Parameter_Pollution.script).

Attack details

Path Fragment input / was set to qui&n950086=v982658 Parameter precedence: last occurrence Affected link: /search/node/qui?page=1&n950086=v982658 Affected parameter: page=1

Request GET /search/node/qui%26n950086%3dv982658

So my question is two-fold: Should this be considered a false-positive? How is Drupal protecting itself from HPP?

Thanks!

Improve this question
6
  • 1
    Personally I'd say this is not so much a false positive as a reminder that you might be vulnerable through URL parameters, and that your application should handle query strings properly. If data from query strings is properly sanitised on the server-side I don't see how you could use this method to orchestrate an attack. The app should be smart enough not to be affected by a rogue foo=bar in the URL
    – Clive ♦
    Commented Jun 7, 2013 at 0:06
  • What scanner? One of my clients does scans and I have never run across this.
    – mpdonadio ♦
    Commented Jun 7, 2013 at 0:32
  • 1
    drupal already turns www.yourhost.com/foo/bar?baz=bing internally into www.yourhost.com/?q=foo/bar&baz=bing so unless some malicious module writer has written a backdoor into your system if $_GET['baz']=='bing' I'm with @clive on this one, it's not an issue, your app should be fine with any parameters it doesn't already acknowledge.
    – Jimajamma
    Commented Jun 7, 2013 at 0:35
  • I did notice that www.yourhost.com/node/1?q=node/2 will take you to node/2 but at least this will be obvious and not necessarily gaining any ability to be malicious (imho).
    – Jimajamma
    Commented Jun 7, 2013 at 0:41
  • 2
    @Jimajamma - that's because php scans the query string from left to right to create $_GET array. Later overrides earlier and last one goes. Personally I would much prefer it to scan right to left, but that's something we would need to either hack into PHP itself or at least into Drupal's very index.php
    – Mołot
    Commented Jun 7, 2013 at 6:51

2 Answers 2

Reset to default
3

Simple answer: no, theme_pager() isn't vulnerable to this kind of attack.

The pager functions only use the page parameter and don't make use of any other. As far as Drupal core goes, that argument is used only in the context of a PDO-prepared database query, and so any effort at malicious manipulation of that page parameter will simply fail.

As with anything, careless use of theme_pager() outside of the proper API - e.g. using the associated preparatory functions manually without properly prepared database queries - can result in unwanted side-effects. But the function and its associates aren't inherently insecure, and from a core perspective are used safely.

Improve this answer
11
  • Have you investigated the other aspect mentioned in the HPP article, where a second page variable is present in the URL?
    – mpdonadio ♦
    Commented Jun 7, 2013 at 0:58
  • @MPD - second variable may be used to direct to another / nonexistent page, but that's all. It cannot poison database in any way. As far as I understand core, it leaves parsing variables like that to php (and, amybe, mod_rewrite). I agree support for duplicated variable is next to nonexistent in PHP, but it's not something that may lead to data loss or theft. Or am I getting your comment wrong?
    – Mołot
    Commented Jun 7, 2013 at 6:47
  • @MPD yep, but as yet I haven't been able to come up with an explanation as to why that's a vulnerability. What malicious action or exposure of private information could this vulnerability actually cause? I'm almost positive this is just a non-issue cooked up by Acunetix to make it look like their scanner has more clout than others'
    – Clive ♦
    Commented Jun 7, 2013 at 6:58
  • @Clive actually it may hit page's reputation. Imagine parameter describing should adult content be visible or no. Now URL can contain /noadultcontent, and if attacker will add ?blah=longstringtomakeithardtoread&adultcontent=yes to a link somewhere, people will "see" that page displays adult content to people that does not want it. That's not issue for pager, but definitely that's something that can be abused.
    – Mołot
    Commented Jun 7, 2013 at 7:40
  • @Mołot I disagree - application logic should normalise that risk. The bottom line is sensitive content should only be shown to users who are properly authenticated, thereby removing the risk. No app should be making decisions on showing sensitive content based on URL parameters alone. I still don't see how a properly secure application can be at risk from this 'vulnerability'. Greg's answer seems to back that up (he's head of the security team after all ;)
    – Clive ♦
    Commented Jun 7, 2013 at 10:02
3

HTTP Parameter Pollution is only a problem if one of two things are true:

  1. Those parameters are used to control something important and by polluting the parameter you can cause some inappropriate behavior (doesn't apply).
  2. It's a problem to have user-controlled content inside the html of the page. This is an issue that is more visible via things like Drupal's urls that return 200 responses for a url that is "embarrassing" like https://drupal.org/node/1/acunetix-scans-are-not-super-valid

I would say the fact that the "vulnerability" only shows up on Acunetix sites is evidence is not a "real thing" in the security world.

Improve this answer
3
  • 1
    thanks for chiming in on this. There might be some validity to the scan results. Although I'm not crafty enough to do any real harm, I can create a confusing url. Again, a link to a search for "cat": link. If you change the "Sort by:" field, you will be 1) logged out and 2) taken to a page of my choosing. No harm done, but you if had admin access, and I knew there was an url that changed something, or did something expensive (ie: flush cache)... This obviously isn't about theme_pager() anymore
    – rcourtna
    Commented Jun 7, 2013 at 13:28
  • 1
    Your cat link is a cool trick! That destination=logout issue seems to me to be more about "logout is vulnerable to csrf" - see drupal.org/node/620280 for discussion and remediation if you care about that. I think that's an example where the parameter pollution has a behavior that is an annoyance rather than something malicious. if there is a url that changes something then THAT url is a CSRF issue and parameter pollution is one way (not even a particularly easy way) to exploit it among many others.
    – greggles
    Commented Jun 7, 2013 at 15:27
  • 1
    One other thought: I always ask the vendors of the scan (or the company who ran it for you) to give an example of how to exploit the issue. Most of the time they can't at which point my sense is that it's not a valid issue and is in the report just to bulk it up...
    – greggles
    Commented Jun 7, 2013 at 15:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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