Re: Об одной малоизвестной уязвимости в веб сайтах

[Maxim Dounin]

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/