На веб-сайте, который мы разрабатываем, после проверки безопасности мы выявили проблемы безопасности. Этот отчет также содержит уязвимости HTTP-параметров. В Интернете я мог найти, что такое ГЭС? Как это можно вводить и т.д .; Но я не мог найти, как избежать подобных проблем. Язык сервера – php. & i знаю, что один и тот же параметр можно дублировать, а php просто рассмотрит последний параметр, когда их много. Но это не имеет смысла делать что-то, чтобы избежать этого риска. Так может ли кто-нибудь объяснить мне, как избежать уязвимостей HPP с примерами?
Заранее спасибо
HPP – это когда ваше приложение делает обратный HTTP-запрос другой системе.
например, если ваш веб-сайт использует следующий интерфейсный URL для перевода денег:
https://www.example.com/transferMoney.php
Это доступно только с помощью метода POST и принимает следующие параметры:
amount=1000&fromAccount=12345
Когда ваше приложение обрабатывает эту страницу, он делает следующий запрос POST для задней системы для фактической обработки транзакции с фиксированным значением toAccount :
https://backend.example/doTransfer.php toAccount=9876&amount=1000&fromAccount=12345
Теперь вы говорите, что PHP только берет последний параметр в случае дубликатов.
Предположим, что кто-то изменяет POST на ваш сайт следующим образом:
amount=1000&fromAccount=12345&toAccount=99999
Если ваша страница transferMoney.php уязвима для HPP, то теперь она может сделать следующий запрос для задней системы
https://backend.example/doTransfer.php toAccount=9876&amount=1000&fromAccount=12345&toAccount=99999
Второй toAccount введенный пользователем, переопределит этот запрос на бэкэнд и перечислит деньги в свою учетную запись ( 99999 ) вместо предполагаемой учетной записи, установленной системой ( 9876 ). Это может быть полезно для злоумышленника, чтобы изменить свои собственные запросы к вашей системе. но он также может быть полезен злоумышленнику, если злоумышленник может сгенерировать эту ссылку со своего веб-сайта и побудить других пользователей невольно следовать ссылке, не подозревая о дополнительном параметре.
Чтобы исправить это, вы должны убедиться, что любые внутренние HTTP-запросы имеют правильную кодировку URL, а также проверку всех входных данных. например, что fromAccount является действительным действительным номером учетной записи. Также в моем примере, даже если это не было подтверждено, внутренний запрос должен был быть закодирован как fromAccount=12345%26toAccount%3D99999 который остановил бы второй toAccount на интерпретации как отдельный параметр POST.