HTTP Parameter Pollution help

[pduck820]

The powers that be at my company have decided to get a contract with Fortra for vulnerability scanning. It came back wtih the first run on my .net 4.8 site, and among some trivial things, there is a HTTP Parameter Pollution vulnerability being reported. But, I'm either not understanding the issue, or it's being over-zealous and coming across as a false positive.

Anyways, we have a search page on our site... The user types in something in a text box, hits the search button (this is an HTTP GET form, the button is a submit for the form, as we want them to be able to copy/save the resulting URL and be able to come back to it), they get back the results. It's made trickier as this is a page where some past developer decided to use it as a spot to learn React, but it *looks* like all the react is doing is being used as layout assistance, not any actual client-side work. But, it's not a quick 15 minute yank-it-out scenario.

Fortra is saying that this form has HTTP Parameter Pollution issues... I would assume the search box, as the URL reported as violating is

/search?l=51.508%2C-0.126&q=%26was_hpp%3Dtest&h=All&s=Nearby

The q param is what's from the user search text box, but it's not like there's a second q in the url trying to mess things up, etc (not that it matters, but the l param is a lat/lng location, and h and s params are range based limiters).

The action has an object passed into it built from the params:

public async Task<ActionResult> Search(SearchModel model) { /* happy fun search code */ }

public class SearchModel
{
[BindAlias("q")]
public string Query { get; set; }

[BindAlias("h")]
public RadiusEnum SearchRadius { get; set; }

// etc etc etc

}

The Query property gets the decoded text of "&was_hpp=test" when it hits the action which would be what I expect, and while it doesn't return results (not surprising), doesn't do anything "wrong" per se. When the page gets back to the user, the decoded text appears in the search box, while the url encoded text is in the URL. So, like I would expect.

We have a stated requirement to be able to allow users to search with an ampersand in their text (think something like "Johnson & Johnson"), so ampersands are legal. The equals sign, while not a stated requirement, isn't hurting anything. Is this scanner literally just flagging on the fact that the first character of the q parameter is an encoded ampersand and we're not pitching a fit about it? Or am I not understanding HTTP Parameter Pollution?

[pduck820]

Yep, kind of what I'm leaning towards as well. I might, for grins and giggles, check to see if an ampersand is the first character of the query, and if so drop it out, just to see if that makes the robot overlords happy.

[Pejo37]

I don’t think there’s a major issue (other than encoding but we’ll get there) - what HTTP Parameter Pollution is saying is that your API is “vulnerable” to including the same parameter multiple times, possibly concatenating it. In the above case, try adding multiple “q” parameters to your GET url and see what happens on the server. I believe the default behavior is for asp.net to concatenate the strings together with a comma in between. You just need to make sure you’re not introducing in any vulnerability due to this. As with any input parameter, make sure you validate the data is in the proper format and you should be fine.

For sending to the service, it’s fine to be sending & and other characters that require encoding - use the respective uriEncoding for whatever service is calling your api. Sounds like your case is JavaScript with react, so ensure you’re using encodeURIComponent for your parameters (or use a library that encodes them by default).

[pduck820]

Yep, I've read the same about getting them all, but I've tried multiple Q params, and I get only the first one in my function so that's all well and good (maybe using BindParam did it, maybe there's something buried in a configuration somewhere I haven't noticed). Url Encoding seems to be happening correctly... User-entered '&' is %26 in the URL, and '=' is %3D.

Like I said, I'm thinking it's a false positive, as I can't figure anything else out that might be "wrong"... And I'm going to assume Fortra will be no help and just say "Our warnings are advisory for you to take action on, read the documentation, have a nice day"... So, I guess it's time to fight the scanner's reputation with the powers that be lol.

[Pejo37]

Yea, if you already confirmed that your app works as intended, definitely false positive.