Security Vulnerability(Email Password Reset) : More than 1 Query Param with the same name/key

Have you ever tried passing same query param in http request ?
e.g 127.0.0.1/webapp?emailId=dev@gmail.com&emailId=dora@gmail.com

Any guess forw hich param would be considered .
Does it depend upon on type of webserver or web application code logic ?

Let us try putting same query param on popular search engines like google and bing and see the result.
https://www.google.co.in/search?q=devendradora&q=india
It searched for devendradora india
https://www.bing.com/search?q=devendradora&q=india
It searched for india
Surprised !!!

There is no such particular standard which defines which parameter to consider if there is a same occurence of the same param. So different webservers treat them differently. Some take the last occurence , others take first occurence and few others take concatenation of both values.

Infact, it depends on type of application server (Apache , IIS , Jetty etc) used.
At first glance, you may think that there is no problem based on which parameter is considered by your web app business logic.

But let me give a simple example of password reset using email.
e.g
Suppose url for password reset is
127.0.0.1/webapp/passwordReset?emailId=dev@gmail.com&userId=1
But attacker modified the url as below with email occuring twice
127.0.0.1/webapp/passwordReset?emailId=dev@gmail.com&emailId=dora@gmail.com&userId=1

Suppose you have 2 different microservices

• Microservice1 (Server Type X : Takes last occurence of same named param)
  Generates a unique password reset link and stores in database. So in the above example it takes dora@gmail.com as emailId param and generates a unique link for userId 1
• Microservice2 (Server Type Y : Takes first occurence of same named param)
  Send email containing password link to query param emailId given in request by taking the value stored by Microservice1 in database.

So in the above example it takes dev@gmail.com as emailId param and sends password reset link of dora@gmail.com (userId =1 in query param ] to dev@gmail.com
By the above example, it is clear that you can reset the password of any user by changing request query param.
This is simple example of what can go wrong if business logic is not implemented properly.
Similary , there can be many vulnerabilities.