Инъекция заголовка хоста
Я новичок в области безопасности и чтения о внедрении заголовка узла. Я протестировал приложение на наличие этой уязвимости, и там можно было выполнить какой-то запрос, но разработчик внедрил флаги no-cache, no-store, и эта уязвимость отсутствует в запросе сброса пароля.
Итак, во-первых, отравления кешем не будет. и второе - это не происходит в запросе сброса пароля.
Как я понимаю, для использования этой уязвимости я изменил заголовок этого узла. Поэтому я хочу знать, почему это будет уязвимость, почему пользователь изменит Хост приложения? и как злоумышленник может использовать это?
1 ответ
Как и во всех случаях, клиентскому вводу в приложении никогда нельзя доверять (с точки зрения безопасности). host
Атрибут заголовка также может быть изменен клиентом.
Типичным сценарием атаки может быть, например:
Предположим, у вас есть приложение, которому вы слепо доверяете значению заголовка HOST и используете его в приложении, не проверяя его. Таким образом, у вас может быть следующий код в вашем приложении, где вы загружаете файл JS динамически (по имени хоста):
<script src="http://<?php echo _SERVER['HOST'] ?>/script.js">
В этом случае все, что злоумышленник установил в качестве заголовка HOST, будет отражено в загрузке JS-скрипта. Таким образом, злоумышленник может изменить это, манипулируя ответом для загрузки JS-скрипта с другого хоста (возможно, злонамеренного). Если приложение использует какой-либо механизм кэширования или CDN, и если этот запрос повторяется несколько раз, он может быть кэширован прокси-сервером кэширования. Затем это может быть передано и другим пользователям (так как оно было сохранено в кеше).
Еще один способ использовать это:
Предположим, что приложение имеет функцию сброса пароля пользователя. И приложение отправит электронное письмо тому, кто попросит сбросить пароль, с уникальным токеном для его сброса, как показано ниже:
Hi user,
Here is your reset link
http://<?php echo _SERVER['HOST'] ?>/reset-password?token=<?php echo $token ?>
Теперь злоумышленник может инициировать сброс пароля для известной электронной почты жертвы, изменяя значение заголовка HOST по своему желанию. Затем жертва получит законное письмо для сброса пароля, но URL будет изменен на домен, установленный злоумышленником. Если жертва откроет эту ссылку, злоумышленник может сбросить токен сброса пароля, что приведет к захвату учетной записи.