Для убедительности, приведу ещё такой пример.
Есть бекенд приложения, которое обслуживает множество хостов, всех этих
хостах fastcgi_pass одинаковы, роутинг внутри приложения осуществляется по
HTTP_HOST, дело в том, что использовать для роутинга SERVER_NAME, часто
невозможно по ряду причин.
Nginx,
On 11.01.2014 2:17, Валентин Бартенев wrote:
Подводя итог, не надо вырывать отдельные фразы из RFC и пытаться их
интерпретировать в свою пользу.
Когда nginx выступает в роли клиента, он пытается соблюдать соответствующие
требования спецификации и делает это неплохо. Аналогично в роли сервера.
On 11.01.2014 1:51, Валентин Бартенев wrote:
с RFC то как раз все в порядке: "network location of the URI
(authority) MUST be transmitted in a Host header field",
только вот nginx не соответствует этим требованиям...
http://tools.ietf.org/search/rfc2616#section-5.1.2
>
Если почитать вниматель
> Т.е вы утверждаете, что значения переменой $proxy_host в данном
> запросе будет = apple-shop.com, а не samsung-shop.com?
> Сейчас проверить самостоятельно не могу, потому что везде у нас
> FastCGI.
Вы правы, $proxy_host = proxy_pass, я со своим FastCGI уже совсем забыл про
правила проксирования,
Хочу уточнить, я не предлагаю полную аналогию с UseCanonicalName, я имел
виду использовать значения переменной $host, при условии что host из
absoluteURI отличается от значения клиентского заголовка Host.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,246086,246275#msg-246275
> Коллизии возможны только в одном случае: программист не проверяет
> данные,
> получаемые от клиента, и такому программисту никаким костылями не
> поможешь.
Проверять на бекенде значения Host не рационально, если в конфигурации
server указан только один домен.
Если следовать вашей логике тогда, б
On Friday 10 January 2014 19:40:07 S.A.N wrote:
> > Ровным счетом так nginx и поступает, если передан absoluteURI, то
> > виртуальный
> > сервер определяется по нему, а заголовок Host игнорируется.
>
> Ровным счетом так же должен поступать и бекенд, игнорировать заголовок Host,
> если передан abso
> Ровным счетом так nginx и поступает, если передан absoluteURI, то
> виртуальный
> сервер определяется по нему, а заголовок Host игнорируется.
Ровным счетом так же должен поступать и бекенд, игнорировать заголовок Host,
если передан absoluteURI.
Но дело в том что бекенд не получает, raw запрос с
On Saturday 11 January 2014 03:51:15 Валентин Бартенев wrote:
[..]
Нда, сорри, уже плохо согласовываю слова в предложениях - явно пора спать.
Подводя итог, не надо вырывать отдельные фразы из RFC и пытаться их
интерпретировать в свою пользу.
Когда nginx выступает в роли клиента, он пытается соб
On Saturday 11 January 2014 01:06:00 Gena Makhomed wrote:
[..]
> >> с RFC то как раз все в порядке: "network location of the URI
> >> (authority) MUST be transmitted in a Host header field",
> >> только вот nginx не соответствует этим требованиям...
> >>
> >> http://tools.ietf.org/search/rfc2616#se
On 11.01.2014 0:17, Валентин Бартенев wrote:
Кому интересно почитать, подробней вот ссылка.
http://habrahabr.ru/post/166855/
...
$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
...
Ед
On Friday 10 January 2014 22:51:17 Gena Makhomed wrote:
> On 10.01.2014 15:07, Валентин Бартенев wrote:
>
> >> Кому интересно почитать, подробней вот ссылка.
> >> http://habrahabr.ru/post/166855/
> ...
> >> $host
> >> in this order of precedence: host name from the request line, or host
>
On 10.01.2014 15:07, Валентин Бартенев wrote:
Кому интересно почитать, подробней вот ссылка.
http://habrahabr.ru/post/166855/
...
$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
...
Е
On Friday 10 January 2014 14:06:43 Gena Makhomed wrote:
> On 10.01.2014 13:45, Gena Makhomed wrote:
> Кому интересно почитать, подробней вот ссылка.
> http://habrahabr.ru/post/166855/
>
> Хотя, есть и более простой вариант,
> как на стороне nginx закрыть эту уязвимость с $http_host.
>
>
On Friday 10 January 2014 13:45:27 Gena Makhomed wrote:
> On 10.01.2014 12:24, Валентин Бартенев wrote:
> >>> Кому интересно почитать, подробней вот ссылка.
> >>> http://habrahabr.ru/post/166855/
> >>>
> >>> Как видите, корректное значения имеют только переменные $host и
> >>> $server_name, все чт
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
On 10.01.2014 12:24, Валентин Бартенев wrote:
Кому интересно почитать, подробней вот ссылка.
http://habrahabr.ru/post/166855/
Как видите, корректное значения имеют только переменные $host и
$server_name, все что основывается на $http_host имеет потенциал
уязвимость, если бекенд доверяет этой пе
On Friday 10 January 2014 00:57:16 Gena Makhomed wrote:
> On 09.01.2014 21:03, S.A.N wrote:
> > Вот наглядный пример:
> > fastcgi_param HTTP_HOST1 $http_host;
> > fastcgi_param HTTP_HOST2 $host;
> > fastcgi_param HTTP_HOST3 $server_name;
> >
On 09.01.2014 21:03, S.A.N wrote:
Вот наглядный пример:
fastcgi_param HTTP_HOST1 $http_host;
fastcgi_param HTTP_HOST2 $host;
fastcgi_param HTTP_HOST3 $server_name;
Делаем, запрос
GET http://site3.dev/ HTTP/1.1
Host:~%#$^&*()<>?@\!."'{}[]=+|
На выход
Gena Makhomed Wrote:
---
> возможно имеет смысл дефолтовые настройки сделать такими,
> чтобы они были безопасными по-умолчанию для всех пользователей?
> т.е. $host вместо $proxy_host ?
Поддержу данную мысль, это добавило бы безопасности дефолтног
20 matches
Mail list logo
