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@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru