Уязвимость безопасности (сброс пароля электронной почты): более 1 параметра запроса с одинаковым именем/ключом

Вы когда-нибудь пытались передать тот же параметр запроса в http-запросе?
например 127.0.0.1/webapp?emailId=dev@gmail.com&emailId=dora@gmail.com

Любое предположение относительно этого параметра будет рассмотрено.
Зависит ли это от типа веб-сервера или логики кода веб-приложения?

Давайте попробуем указать один и тот же параметр запроса в популярных поисковых системах, таких как Google и Bing, и посмотрим на результат.
https://www.google.co.in/search?q=devendradora&q=индия
Он искал devendradora в Индии
https://www.bing.com/search?q=devendradora&q=Индия
Он искал Индию
Удивлен!!!

Не существует такого конкретного стандарта, который определяет, какой параметр следует учитывать, если один и тот же параметр встречается одинаково. Поэтому разные веб-серверы относятся к ним по-разному. Некоторые берут последнее вхождение, другие — первое вхождение, а немногие — объединение обоих значений.

Фактически, это зависит от типа используемого сервера приложений (Apache, IIS, Jetty и т. д.).
На первый взгляд может показаться, что нет никакой проблемы в том, какой параметр учитывается бизнес-логикой вашего веб-приложения.

Но позвольте мне привести простой пример сброса пароля с помощью электронной почты.
например
Предположим, URL для сброса пароля
127.0.0.1/webapp/passwordReset?emailId=dev@gmail.com&userId=1
Но злоумышленник изменил URL-адрес, как показано ниже, и электронное письмо появилось дважды.
127.0.0.1/webapp/passwordReset?emailId=dev@gmail.com&emailId=dora@gmail.com&userId=1

Предположим, у вас есть 2 разных микросервиса.

• Microservice1 (тип сервера X: принимает последнее вхождение параметра с таким же именем)
  Создает уникальную ссылку для сброса пароля и сохраняет ее в базе данных. Таким образом, в приведенном выше примере он принимает dora@gmail.com в качестве параметра emailId и создает уникальную ссылку для идентификатора пользователя 1.
• Microservice2 (тип сервера Y: принимает первое вхождение параметра с таким же именем)
  Отправьте электронное письмо, содержащее ссылку на пароль, для параметра запроса emailId, указанного в запросе, взяв значение, хранящееся в базе данных Microservice1.

Таким образом, в приведенном выше примере он принимает dev@gmail.com в качестве параметра emailId и отправляет ссылку для сброса пароля dora@gmail.com (userId = 1 в параметре запроса]на dev@gmail.com
Из приведенного выше примера видно, что вы можете сбросить пароль любого пользователя, изменив параметр запроса запроса.
Это простой пример того, что может пойти не так, если бизнес-логика реализована неправильно.
Аналогично, уязвимостей может быть много.