Contents
Что такое заголовок узла HTTP?
Заголовок узла HTTP является обязательным заголовком запроса, начиная с HTTP/1.1. Он указывает доменное имя, к которому клиент хочет получить доступ. Например, когда пользователь посещает https://portswigger.net/web-security, его браузер создаст запрос, содержащий заголовок Host, следующим образом:
GET /web-security HTTP/1.1В некоторых случаях, например, когда запрос был перенаправлен промежуточной системой, значение узла может быть изменено до того, как оно достигнет предполагаемого внутреннего компонента. Ниже мы обсудим этот сценарий более подробно.
Host: portswigger.net
Какова цель заголовка HTTP Host?
Цель заголовка HTTP Host — помочь определить, с каким внутренним компонентом клиент хочет взаимодействовать. Если запросы не содержали заголовков Host или если заголовок Host был каким-то образом искажен, это могло привести к проблемам при маршрутизации входящих запросов в предполагаемое приложение.
Исторически такой неоднозначности не существовало, поскольку на каждом IP-адресе размещался контент только для одного домена. В настоящее время, в основном из-за постоянно растущей тенденции к облачным решениям и аутсорсингу большей части связанной архитектуры, многие веб-сайты и приложения обычно доступны по одному и тому же IP-адресу. Популярность этого подхода также возросла отчасти из-за исчерпания адресов IPv4.
Когда несколько приложений доступны через один и тот же IP-адрес, это чаще всего является результатом одного из следующих сценариев.
Виртуальный хостинг
Один из возможных сценариев — когда на одном веб-сервере размещается несколько веб-сайтов или приложений. Это может быть несколько веб-сайтов с одним владельцем, но веб-сайты с разными владельцами также могут размещаться на одной общей платформе. Это реже, чем раньше, но все еще происходит с некоторыми облачными решениями SaaS.
В любом случае, хотя у каждого из этих отдельных веб-сайтов будет свое доменное имя, все они имеют общий IP-адрес с сервером. Веб-сайты, размещенные таким образом на одном сервере, называются «виртуальными хостами».
Для обычного пользователя, заходящего на веб-сайт, виртуальный хост часто неотличим от веб-сайта, размещенного на собственном выделенном сервере.
Маршрутизация трафика через посредника
Другой распространенный сценарий — когда веб-сайты размещаются на отдельных внутренних серверах, но весь трафик между клиентом и серверами направляется через промежуточную систему. Это может быть простой балансировщик нагрузки или какой-либо обратный прокси-сервер. Эта настройка особенно распространена в тех случаях, когда клиенты получают доступ к веб-сайту через сеть доставки контента (CDN).
В этом случае, несмотря на то, что веб-сайты размещены на отдельных внутренних серверах, все их доменные имена разрешаются в один IP-адрес промежуточного компонента. Это создает некоторые из тех же проблем, что и виртуальный хостинг, потому что обратному прокси-серверу или балансировщику нагрузки необходимо знать соответствующий сервер, на который он должен направлять каждый запрос.
Как заголовок узла HTTP решает эту проблему?
В обоих этих сценариях заголовок Host используется для указания предполагаемого получателя. Распространенной аналогией является процесс отправки письма тому, кто живет в многоквартирном доме. Все здание имеет один и тот же почтовый адрес, но за этим уличным адресом находится много разных квартир, каждая из которых должна каким-то образом получать правильную почту. Одним из решений этой проблемы является простое включение в адрес номера квартиры или имени получателя. В случае HTTP-сообщений заголовок Host служит той же цели.
Когда браузер отправляет запрос, целевой URL-адрес преобразуется в IP-адрес определенного сервера. Когда этот сервер получает запрос, он обращается к заголовку Host, чтобы определить предполагаемую серверную часть, и соответствующим образом перенаправляет запрос.
Что такое атака HTTP-заголовка хоста?
Атаки на заголовок узла HTTP используют уязвимые веб-сайты, которые небезопасно обрабатывают значение заголовка узла. Если сервер неявно доверяет заголовку Host и не может правильно его проверить или экранировать, злоумышленник может использовать эти входные данные для внедрения вредоносных полезных данных, которые манипулируют поведением на стороне сервера. Атаки, которые включают в себя внедрение полезной нагрузки непосредственно в заголовок узла, часто называются атаками «внедрения заголовка узла».
Готовые веб-приложения обычно не знают, в каком домене они развернуты, если это не указано вручную в файле конфигурации во время установки. Когда им нужно знать текущий домен, например, для создания абсолютного URL-адреса, включенного в электронное письмо, они могут прибегнуть к извлечению домена из заголовка узла:
<a href="https://_SERVER['HOST']/support">Contact support</a>Значение заголовка также может использоваться во множестве взаимодействий между различными системами инфраструктуры веб-сайта.
Поскольку заголовок Host на самом деле контролируется пользователем, такая практика может привести к ряду проблем. Если входные данные не экранированы или не проверены должным образом, заголовок Host является потенциальным вектором для использования ряда других уязвимостей, в первую очередь:
- Отравление веб-кэша
- Ошибки бизнес -логики в определенных функциях
- SSRF на основе маршрутизации
- Классические уязвимости на стороне сервера, такие как SQL-инъекция
Как возникают уязвимости HTTP-заголовка хоста?
Уязвимости заголовка узла HTTP обычно возникают из-за ошибочного предположения, что заголовок не контролируется пользователем. Это создает неявное доверие к заголовку Host и приводит к неадекватной проверке или экранированию его значения, даже если злоумышленник может легко изменить это с помощью таких инструментов, как Burp Proxy.
Даже если сам заголовок узла обрабатывается более безопасно, в зависимости от конфигурации серверов, обрабатывающих входящие запросы, узел потенциально может быть переопределен путем внедрения других заголовков. Иногда владельцы веб-сайтов не знают, что эти заголовки поддерживаются по умолчанию, и в результате к ним может не относиться такой же уровень проверки.
На самом деле многие из этих уязвимостей возникают не из-за небезопасного кода, а из-за небезопасной конфигурации одного или нескольких компонентов в соответствующей инфраструктуре. Эти проблемы с конфигурацией могут возникать из-за того, что веб-сайты интегрируют сторонние технологии в свою архитектуру, не обязательно разбираясь в параметрах конфигурации и их последствиях для безопасности.
Эксплуатация уязвимостей HTTP-заголовка хоста
К настоящему времени вы должны хорошо понимать, что такое заголовок узла HTTP. Для пентестеров и охотников за ошибками мы создали несколько дополнительных руководств о том, как самостоятельно выявлять и использовать подобные уязвимости. Мы также предоставили несколько преднамеренно уязвимых ЛАБОРАТОРИЙ , чтобы вы могли попрактиковаться в некоторых из этих методов.
Как предотвратить атаки заголовков хоста HTTP
Чтобы предотвратить атаки на заголовок узла HTTP, самый простой подход — вообще избегать использования заголовка узла в коде на стороне сервера. Дважды проверьте, действительно ли каждый URL-адрес должен быть абсолютным. Вы часто обнаружите, что вместо этого вы можете просто использовать относительный URL-адрес. Это простое изменение может помочь вам, в частности, предотвратить уязвимости, связанные с отравлением веб-кэша.
Другие способы предотвращения атак заголовков хоста HTTP включают в себя:
Защитить абсолютные URL-адреса
Когда вам нужно использовать абсолютные URL-адреса, вы должны потребовать, чтобы текущий домен был указан вручную в файле конфигурации, и ссылаться на это значение вместо заголовка Host. Такой подход устранит, например, угрозу отравления при сбросе пароля.
Проверить заголовок хоста
Если вы должны использовать заголовок Host, убедитесь, что вы правильно его проверили. Это должно включать проверку его по белому списку разрешенных доменов и отклонение или перенаправление любых запросов для неопознанных хостов. Вам следует обратиться к документации вашего фреймворка, чтобы узнать, как это сделать. Например, платформа Django предоставляет ALLOWED_HOSTSпараметр в файле настроек. Такой подход уменьшит вашу подверженность атакам с внедрением заголовков хоста.
Не поддерживать заголовки переопределения хоста
Также важно убедиться, что вы не поддерживаете дополнительные заголовки, которые могут использоваться для построения этих атак, в частности X-Forwarded-Host. Помните, что они могут поддерживаться по умолчанию.
Белый список разрешенных доменов
Чтобы предотвратить атаки на внутреннюю инфраструктуру на основе маршрутизации, вы должны настроить свой балансировщик нагрузки или любые обратные прокси-серверы для пересылки запросов только в белый список разрешенных доменов.
Будьте осторожны с виртуальными хостами только для внутреннего использования
При использовании виртуального хостинга вам следует избегать размещения внутренних веб-сайтов и приложений на том же сервере, что и общедоступный контент. В противном случае злоумышленники могут получить доступ к внутренним доменам посредством манипулирования заголовком хоста.
