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