Hello!

On Sun, Jun 15, 2014 at 11:07:58PM +0300, Gena Makhomed wrote:

> On 14.06.2014 21:14, Maxim Dounin wrote:
>
> >>>>>>>>>>>>http://habrahabr.ru/post/166855/
> ...
> >Прокси-сервер, помимо всего прочего, является сервером, и
> >процитированное требование вернуть 400 в ответ на "Host header
> >field with an invalid field-value" - к нему тоже относится.
> >Соответственно, если трактовать термин "invalid field-value" как
> >включающий проверку не только синтаксиса, но и требований,
> >предъявляемых к формированию заголовка Host клиентом, то
> >требование "ignore the received Host header" теряет смысл.
>
> Максим, теперь я понял, в чем была моя ошибка, спасибо!
>
> >Теримн "field-value" расшифровывается в "3.2. Header Fields",
> >http://tools.ietf.org/html/rfc7230#section-3.2:
> >
> > field-value = *( field-content / obs-fold )
> >
> >Соответственно invalid - это то, что не соответствует указанному
> >синтаксису.
>
> Понял, спасибо!
>
> Но есть один не совсем понятный нюанс -
> озвученные в RFC 7230 требования к клиенту:
>
> http://tools.ietf.org/html/rfc7230#section-5.4
>
> A client MUST send a Host header field in all HTTP/1.1 request
> messages. If the target URI includes an authority component, then a
> client MUST send a field-value for Host that is identical to that
> authority component, excluding any userinfo subcomponent and its "@"
> delimiter (Section 2.7.1).
>
> - это ведь требования к синтаксису, которые обязательны для выполнения.

Нет, это не требования к синтаксису, это требования к семантике.
И они обязательны для клиента, но не для сервера. Соответственно,
что делать в случае, если клиент их не выполнил - на совести
сервера.

> А вот что есть в RFC 7231:
>
> http://tools.ietf.org/html/rfc7231#section-6.5.1
>
> 6.5.1. 400 Bad Request
>
> The 400 (Bad Request) status code indicates that the server cannot or
> will not process the request due to something that is perceived to be
> a client error (e.g., malformed request syntax, invalid request
> message framing, or deceptive request routing).
>
> Следовательно, сервер имеет право вернуть 400 статус,
> если получит запрос с разными authority component
> в заголовке Host и в absolute Request URI ?

Сервер имеет право вернуть 400 более или менее в любой момент.

> Кроме того, в разделе 5.5. Effective Request URI
> http://tools.ietf.org/html/rfc7230#section-5.5
>
> даже прямо говорят, что запрос может быть misdirected,
> deliberately or accidentally, и что origin server должен
> сам решить, обрабатывать такой запрос или нет, потому что
> "it might indicate an attempt to bypass security filters,
> trick the server into delivering non-public content,
> or poison a cache."
>
> именно это ведь и происходит в случае запроса
>
> GET http://apple.com/ HTTP/1.1
> Host: samsung.com
>
> Разве ответить на такой запрос 400-м статусом не будет лучше?

Это зависит от многих факторов. Вот тут Валентин давеча
напрограммировал возврат 400, если имя, указанное в SNI, не
совпадало с именем, используемым в запросе, ибо RFC 6066 говорит:

... If the server_name is
established in the TLS session handshake, the client SHOULD NOT
attempt to request a different server name at the application layer.

Так пришлось распрограмировать обратно - потому что Chrome
использует "a different server name at the application layer",
когда считает нужным/возможным.

То, как ведёт себя nginx по умолчанию - вполне себе безопасно, и
проблемы нет. Какая-либо проблема появляется тогда и только
тогда, когда администратор начинает писать в конфиге $http_host,
не думая о последствиях. Есть мнение, что совсем простое решение
этой проблемы - не делать так (c) анекдот.

--
Maxim Dounin
http://nginx.org/

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru