debian nginx 1.10.3 предотвращает внедрение заголовков
У меня Debian 8 VPS работает с nginx 1.10.3.
Я размещаю несколько веб-сайтов Symfony 3.2 (используя php7-fpm) и сталкиваюсь с проблемами внедрения заголовков. Я не могу понять, связана ли проблема больше с nginx или с конфигурацией проекта symfony.
Я не использую никакой LoadBalancer, такой как Varnish или Amazon AWS.
Когда кто-то отправляет запрос, используя недействительный X-Forwared-Host
такие как:
X-Forwarded-Host: pg_sleep(2)
Затем он получает 500 Internal Server Error
и я вижу критическую ошибку в журналах:
UnexpectedValueException: "Invalid Host "pg_sleep(2)" at [...]/var/bootstrap.php.cache"
Я могу легко воспроизвести его (только в производственной среде, используя этот файл bootstrap.php.cache) с помощью curl:
curl -I\
-H "X-Forwarded-Host: pg_sleep(2)"\
"https://my-domain.tld"
Некоторые другие ценности, которые я получил, могут быть X-Forwarded-Host: *.domain.tld
, X-Forwarded-Host: -1 or 2+429-429-1=0+0+0+1 --
, X-Forwarded-Host: -1; waitfor delay '0:0:14' --
и т.п.
Я похож на инъекционную атаку.
Моя цель - обработать такие недопустимые заголовки и вернуть, например, статус 444, или, по крайней мере, предотвратить запуск приложения 500 Internal Server Error
,
Мой первый вопрос: должен ли я попытаться перехватить такие недопустимые заголовки внутри конфигурации nginx (используя модуль?) Или это то, что должно обрабатываться проектом symfony?
Я прочитал это руководство: http://symfony.com/doc/current/components/http_foundation/trusting_proxies.html
Вам также следует убедиться, что ваш прокси-сервер фильтрует несанкционированное использование этих заголовков, например, если прокси-сервер изначально использует заголовок X-Forwarded-For, он не должен позволять клиентам отправлять перенаправленные заголовки в Symfony.
Что заставляет меня думать, что этим должен заниматься nginx, тогда... Как?
Я пытался проверить хост внутри моего блока server{}, но он не перехватывает его...
server {
listen 443;
# [...]
if ($host !~ ^(my-domain.tld)$ ) {
return 444;
}
# [...]
}
Похоже, можно было бы использовать headers_more
модуль, но это лучшая практика?