Host header attacks
В этом разделе мы обсудим, как из-за неправильной конфигурации и ошибок бизнес-логики сайты могут подвергаться различным атакам через HTTP заголовок Host. Вы узнаете методологию выявления сайтов, уязвимых к атакам через заголовок Host и как использовать это для следующих видов атак:
Лабораторные задания
Если вы уже знакомы с базовыми концепциями уязвимостей заголовка HTTP Host и просто хотите попрактиковаться в их эксплуатации на реалистичных, заведомо уязвимых целях, все лабораторные работы по этой теме доступны по ссылке ниже.
Что такое заголовок Host?
Заголовок Host — это обязательный заголовок запроса начиная с HTTP/1.1. Он указывает доменное имя, к которому клиент хочет получить доступ. Например, когда пользователь посещает https://portswigger.net/web-security, его браузер сформирует запрос с таким заголовком Host:
В некоторых случаях, например, когда запрос был перенаправлен промежуточной системой, значение Host может быть изменено до того, как он достигнет целевого бэкенд-компонента. Более подробно этот сценарий рассматривается ниже.
Какова цель заголовка Host?
Назначение заголовка Host — помочь определить, с каким бэкенд-компонентом хочет общаться клиент. Если бы запросы не содержали заголовок Host или если бы он был некорректно сформирован, это могло бы привести к проблемам при маршрутизации входящих запросов в нужное приложение.
Исторически такой неоднозначности не было, поскольку каждый IP-адрес обслуживал контент только для одного домена. Сегодня, во многом из-за растущей популярности облачных решений и аутсорсинга значительной части инфраструктуры, нередко несколько сайтов и приложений доступны по одному и тому же IP-адресу. Рост популярности этого подхода также частично связан с исчерпанием пула адресов IPv4.
Когда по одному IP-адресу доступны несколько приложений, это чаще всего результат одного из следующих сценариев.
Виртуальный хостинг
Один из возможных сценариев — когда один веб-сервер обслуживает несколько сайтов или приложений. Это могут быть несколько сайтов одного владельца, но также возможно, что сайты разных владельцев размещаются на одной общей платформе. Это встречается реже, чем раньше, но всё ещё имеет место с некоторыми облачными SaaS решениями.
В обоих случаях, хотя у каждого отдельного сайта будет своё доменное имя, все они разделяют общий IP-адрес сервера. Сайты, размещённые таким образом на одном сервере, называются «виртуальными хостами».
Для обычного пользователя виртуальный хост часто неотличим от сайта, размещённого на собственном выделенном сервере.
Маршрутизация трафика через промежуточный узел
Другой распространённый сценарий — когда сайты размещены на отдельных бэкенд-серверах, но весь трафик между клиентом и серверами проходит через промежуточную систему. Это может быть простой балансировщик нагрузки или реверс-прокси. Такой подход особенно распространён, когда клиенты получают доступ к сайту через CDN.
В этом случае, хотя сайты и размещены на отдельных бэкенд-серверах, все их доменные имена резолвятся в один IP-адрес промежуточного компонента. Это создаёт похожую ситуацию, что и при виртуальном хостинге, поскольку реверс-прокси или балансировщику нагрузки нужно знать, на какой бэкенд маршрутизировать каждый запрос.
Как заголовок Host решает эту проблему?
В обоих сценариях на заголовок Host полагаются для указания предполагаемого получателя. Частая аналогия — отправка письма человеку, живущему в многоквартирном доме. У всего здания один и тот же адрес, но за ним скрывается множество квартир, и каждая должна получить свою почту. Одно из решений: включить номер квартиры или имя получателя в адрес. В случае HTTP-сообщений заголовок Host выполняет аналогичную роль.
Когда браузер отправляет запрос, целевой URL резолвится в IP-адрес конкретного сервера. Получив запрос, сервер обращается к заголовку Host, чтобы определить целевой бэкенд, и пересылает запрос соответствующим образом.
Что такое атака через заголовок Host?
Если сервер неявно доверяет заголовку Host и не валидирует или не экранирует его должным образом, атакующий может использовать этот ввод для внедрения вредоносного пейлоада, который изменяет поведение на серверной стороне. Атаки, в которых полезная нагрузка внедряется непосредственно в заголовок Host, часто называют «Host header injection».
Готовые веб-приложения обычно не знают, на каком домене они развернуты, если это не указано вручную в конфигурационном файле при установке. Когда им нужно знать текущий домен, например, чтобы сгенерировать абсолютный URL для включения в электронное письмо, они могут прибегнуть к получению домена из заголовка Host:
Значение заголовка также может использоваться в различных взаимодействиях между разными системами инфраструктуры сайта.
Поскольку заголовок Host на самом деле контролируется пользователем, такая практика может приводить к ряду проблем. Если ввод не экранируется или не валидируется должным образом, заголовок Host становится потенциальным вектором для эксплуатации целого ряда других уязвимостей, в частности:
Отравление веб-кэша
Ошибки бизнес-логики в конкретной функциональности
SSRF, основанная на маршрутизации
Классические уязвимости на стороне сервера, такие как SQL-инъекция
Как возникают уязвимости заголовка Host?
Уязвимости заголовка Host обычно возникают из-за ошибочного предположения, что этот заголовок не контролируется пользователем. Это создаёт неявное доверие к заголовку Host и приводит к недостаточной проверке или экранированию его значения, хотя атакующий легко может изменить его с помощью инструментов вроде Burp Proxy.
Даже если сам заголовок Host обрабатывается более безопасно, он потенциально может быть переопределён путём внедрения других заголовков, в зависимости от конфигурации серверов, работающих с входящими запросами. Иногда владельцы сайтов не знают, что поддержка этих заголовков включена по умолчанию, и, как следствие, они не подвергаются таким же проверкам.
На самом деле многие из этих уязвимостей возникают не из-за небезопасного кода, а из-за небезопасной конфигурации одного или нескольких компонентов соответствующей инфраструктуры. Эти проблемы конфигурации могут появляться потому, что сайты интегрируют сторонние технологии в свою архитектуру, не всегда понимая варианты конфигурации и их последствия для безопасности.
Эксплуатация уязвимостей заголовка Host
К этому моменту у вас должно сложиться хорошее понимание того, что такое заголовок Host. Для пентестеров и багхантеров есть дополнительные рекомендации по тому, как самостоятельно выявлять и эксплуатировать подобные уязвимости. А также некоторые заведомо уязвимые лабораторные задания, чтобы вы могли попрактиковаться в этих техниках.
Как предотвратить атаки через заголовок Host
Чтобы предотвратить атаки через заголовок Host, самый простой подход — совсем не использовать заголовок Host в серверном коде. Дважды проверьте, действительно ли каждому URL нужно быть абсолютным. Часто можно просто использовать относительный URL. Это простое изменение поможет, в частности, предотвратить уязвимости отравления веб-кэша.
Защита абсолютных URL
Когда вам всё же нужны абсолютные URL, требуйте явного указания текущего домена в конфигурационном файле и используйте это значение вместо заголовка Host. Такой подход, например, устранит угрозу отравления сброса пароля.
Валидируйте заголовок Host
Если вам приходится использовать заголовок Host, убедитесь, что вы корректно его валидируете. Это должно включать проверку по списку разрешённых доменов и отклонение либо перенаправление любых запросов к нераспознанным хостам. Обратитесь к документации вашего фреймворка за рекомендациями по реализации. Например, у фреймворка Django есть параметр ALLOWED_HOSTS в файле настроек. Такой подход снизит вероятность атак внедрения через заголовок Host.
Отключите заголовки переопределения Host
Также важно убедиться, что вы не поддерживаете дополнительные заголовки, которые могут использоваться для построения таких атак, в частности X-Forwarded-Host. Помните, что они могут поддерживаться по умолчанию.
Внесите разрешённые домены в белый список
Чтобы предотвратить атаки на внутреннюю инфраструктуру, основанные на маршрутизации, настройте балансировщик нагрузки или любые реверс-прокси таким образом, чтобы они пересылали запросы только на домены из белого списка.
Будьте осторожны с виртуальными хостами, доступными только внутри сети
При использовании виртуального хостинга избегайте размещения внутренних сайтов и приложений на том же сервере, что и публичный контент. В противном случае злоумышленники могут получить доступ к внутренним доменам путём манипулирования заголовком Host.
Last updated