Поэтому мне было поручено исследовать проблему, которая была обнаружена при сканировании веб-безопасности Acunetix.
Вот подробности сканирования:
Host_header_attack
Автоматическое обнаружение атак на заголовок хоста
Я пока не могу опубликовать более двух ссылок, так как у меня недостаточно репутации, но ссылка на скелетоны на первой из приведенных выше ссылок дает более подробную информацию об эксплойте и, кажется, является основным источником по этому вопросу.
Предлагаемые обходные пути предполагают использование «фиктивных» виртуальных хостов и приложений по умолчанию, использующих SERVER_NAME вместо использования Заголовок хоста. Эти предложения хороши, когда речь идет об истинном сервере происхождения, но не особенно, когда вы используете обратный прокси.
Наш веб-сайт, который сканирует Acunetix, настроен как сервер приложений, расположенный за обратным прокси-сервером. В нашем случае обратный прокси-сервер - iPlanet, но я подтвердил то же поведение в Apache 2.4.7 с mod_proxy. Вот как это работает и почему запускает сканирование Acunetix.
Когда запрос выполняется с использованием абсолютного URI (как это делает сканер), сервер, согласно спецификации RFC, должен игнорировать заголовок Host и вместо этого использовать хост, который находится внутри абсолютного URI. Это то поведение, которое мы видим, и в результате выбирается правильный виртуальный хост, даже если заголовок Host имеет неправильное / вредоносное значение. Все идет нормально.
Проблема возникает, когда обратный прокси-сервер затем передает этот запрос внутреннему исходному серверу. При этом он передает исходный заголовок Host вместе с запросом. Если заголовок Host имеет неправильное или вредоносное значение, оно будет передано обратно на исходный сервер. Если исходный сервер не реализует виртуальные хосты, ему не нужно проверять правильность заголовка Host.
Результатом этого является то, что любое приложение, работающее на исходном веб-сервере / сервере приложений, которое пытается использовать значение Заголовок хоста будет использовать значение вредоносного хоста. Используя SERVER_NAME бесполезен в этом случае, поскольку имя сервера (или истинный хост) сайта не пересылается обратным прокси, а исходный сервер по-прежнему отвечает значением заголовка Host. С помощью UseCanonicalName и ServerNamДиректива e здесь также бесполезна, поскольку вам нужно имя сервера из исходного запроса, которое может иметь более одного значения.
Эта «атака» была обнаружена в 2013 году, но я не могу найти о ней много информации, которая не просто повторяла бы детали из приведенных выше ссылок. Это не обычная проблема, потому что HTTP-клиенты не отправляют абсолютные URI, если они не обращаются к прокси-серверам пересылки. Это означает, что все регулярный запросы будут относительными URI, и эта проблема исчезнет (заголовки вредоносного хоста застревают на «фиктивном» или виртуальном хосте по умолчанию на обратном прокси).
Я создал обходной путь, при котором обратный прокси-сервер активно устанавливает заголовок Host на SERVER_NAME перед отправкой запроса на серверную часть. Это работает, но я беспокоюсь, может ли это решение противоречить практике / стандартам ставок. Будет ли установка такого заголовка Host что-нибудь сломать? Мы провели мозговой штурм, но я не могу придумать, где бы это было. Завтра я позвоню в Oracle, чтобы получить от них обратную связь.
Мне кажется, что это может быть настолько второстепенный случай, что это просто недосмотр в двух продуктах веб-серверов, которые я пробовал, но я не могу представить, чтобы что-то могло продлиться так долго без решения. Я, должно быть, что-то упускаю.
Извините, это так долго, но есть идеи? :) "Вопрос" в этом эссе будет следующим:
Ваш обратный прокси-сервер должен исправлять заголовок Host: по умолчанию. То, что он этого не делает, является ошибкой, о которой следует сообщить разработчику (-ам).
Когда прокси получает запрос с абсолютной формой цели запроса, прокси ДОЛЖЕН игнорировать полученное поле заголовка Host (если есть) и вместо этого заменить его информацией о хосте цели запроса. Прокси-сервер, который пересылает такой запрос, ДОЛЖЕН сгенерировать новое значение поля Host на основе полученной цели запроса, а не пересылать полученное значение поля Host.
Обратите внимание, что предыдущая версия этого RFC, RFC 2616, была гораздо менее конкретной. Он только сказал:
Прокси-сервер HTTP / 1.1 ДОЛЖЕН гарантировать, что любое пересылаемое им сообщение запроса содержит соответствующее поле заголовка хоста, которое идентифицирует услугу, запрашиваемую прокси-сервером.
Нельзя сказать, что поведение вашего прокси соответствует ни старой, ни новой спецификации.
А пока ваш обходной путь в порядке, поскольку он вводит правильное поведение.
Мне нужно исправить ту же проблему, Acunetix сообщил об этой уязвимости - у меня нет обратного прокси, но я нашел такое же решение, я явно установил заголовок Host в vHost, поэтому это всегда то, что я хочу. Однако повторное сканирование показывает, что проблема все еще существует.
Я использовал Postman и cURL для проверки своего решения и заметил, что вредоносные заголовки Host или X-Forwarded-Host больше не отражаются, но Acunetix все еще показывает уязвимость, поскольку там ...
Реализовал 2 решения:
1) Создал общий vHost ... 2) Явно установите заголовок Host на моем сервере vHost
Точка 1 предназначена для защиты от простого изменения заголовка Host, чтобы предотвратить передачу Apache запроса на vHost на основе имени, а точка 2 сортирует модификацию X-Forwarded-Host.
Что еще там?
Apache 2.4 Ubuntu 14.04.5