Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proxy cache key и fastcgi cache key
On 10.01.2014 13:45, Gena Makhomed wrote:
Кому интересно почитать, подробней вот ссылка.
http://habrahabr.ru/post/166855/
Хотя, есть и более простой вариант,
как на стороне nginx закрыть эту уязвимость с $http_host.
$host
in this order of precedence: host name from the request line, or host
name from the ?Host? request header field, or the server name matching a
request
Eсли в request line оказывается одно значение $host,
а в ?Host? request header field оказывается другое значение,
тогда просто возвращать 400 Bad Request, поскольку от нормального
клиента (браузера и т.п.) такой запрос никакогда придти не может.
Это формально правильный способ, но менее удобный для разработчиков,
потому что вполне может быть такой вариант, что это default server
и запрос придет вообще без заголовка Host: - тогда в HTTP_HOST
будет пусто и backend скорее всего нормально не отработает.
Поэтому мне больше нравится вариант в случае несоответствия
значений переменных $host и $http_host - в $http_host писать
значение $host. Тем более, что в случае запроса по ип-адресу
тогда в HTTP_HOST на backend уйдет значение из $server_name.
И любой современный код отработает на такой запрос нормально.
Это максимально надежный и максимально безглючный вариант.
А если backend - apache, в его SERVER_NAME может быть другое
значение, отличное от правильного значения $server_name из nginx.
И тут будут аналогичные проблемы, что и сейчас с $host и $http_host.
P.S.
Или сделать это поведение конфигурируемым, возвращать 400 ошибку,
или писать в $http_host значение из $host. По дефолту может быть
например, перезапись $http_host значением из $host, кому это не подходит
- могут настроить возврат 400 ошибки или даже полностью
выключить какую-либо реакцию на эти попытки взлома веб-сервера
и пропускать их as is на backend, пусть он попробует защититься.
Есть такое мнение, что это вообще идеальный вариант решения проблемы.
Не могу даже придумать кому и почему может не понравиться такой вариант.
--
Best regards,
Gena
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru
|