Removing duplicate parameters from post or URL-CodePudding

I have a security concern raised by a security consultant with regards to a website of one of my clients:

Using Burp Suite Community Edition, running a POST request with the following parameter string:

search=Search&city=Johannesburg&city=Madrid

PHP populates the POST array to this:

Array
(
    [search] => Search
    [city] => Madrid
)

This is obvious that it would happen, but I want to know if my attempt to resolve this potential problem has any downsides, except the things I can think of, which I will mention below. Here is my attempted code (PHP, CodeIgniter 3):

$raw_input = explode('&', $this->input->raw_input_stream);
if (!empty($raw_input)) {
    $new_post = [];
    foreach ($raw_input as $key => $value) {
        $param = explode('=', $value);
        if (!isset($new_post[$param[0]])) {
            $new_post[$param[0]] = $param[1];
        }
    }
    if (!empty($new_post)) {
        $_POST = $new_post;
    }
}

This results in my output to be as follows, which is at face value what I want to achieve:

Array
(
    [search] => Search
    [city] => Johannesburg
)

Now - I can see a few points of concern:

I am aware that I still have to do XSS clean and all those nice security things on the POST. [I just do that elsewhere as needed - this part of code I wish to run at the earliest part possible to ensure that it runs for every page/request]
I will have to do this for GET and probably all other HTTP verbs as well. [Which ones? All of them?]
What if the hacker manages to inject the duplicate parameter before the valid one? [Is that possible?]
Why am I reinventing the wheel for something that probably already exists? [Because I do not know where to find a proper solution, or what it would even look like.]

Any advice will be greatly appreciated.

CodePudding user response：

The problem you have described goes by the name parameter pollution. It is a bit bug, a bit feature of the web servers. It may have security implications if - for example - your filter layer checks access rights on the first occurrence of the userid attribute, but the business logic takes the last occurrence of the attribute. You will get an inconsistency that may be exploited.

If you are vulnerable to such type of attack - for me it is a strong evidence that you are doing something wrong inside the code, like you take the message body and extract the attributes manually from the POST requests and you do it different way in two different parts of your code.

If you don't do anything really stupid, this kind of attacks will not hurt the system and does not need any kind of mitigation code.

Unless you really must fix stuff like this, in which case I would say - take a WAF to clear the request before it even reaches the web server.