ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
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


 




Copyright © Lexa Software, 1996-2009.