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

[Maxim Dounin]

Hello!

On Thu, Jun 12, 2014 at 03:40:21PM +0300, Gena Makhomed wrote:

> On 11.06.2014 22:53, Maxim Dounin wrote:
> 
> >>>>>>>>>>http://habrahabr.ru/post/166855/
> ...
> >>>>>Единственный правильный способ: пойти в IETF с предложением исправить
> >>>>>соответствующие RFC, которые в том числе оговаривают, что следует делать
> >>>>>при получении нескольких заголовков Host, ну а потом уже сюда.
> ...
> >>http://tools.ietf.org/html/rfc7230#section-5.4
> >>
> >>    A server MUST respond with a 400 (Bad Request) status code to any
> >>    HTTP/1.1 request message that lacks a Host header field and to any
> >>    request message that contains more than one Host header field or a
> >>    Host header field with an invalid field-value.
> >>
> >>"invalid field-value" - это в том числе, когда клиент не выполняет
> >>требований, которые изложены выше в этом же документе:
> >>
> >>    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).
> >
> >Если исходить из такой трактовки термина "invalid field-value", то
> >ранее процитированное требование про "the proxy MUST ignore the
> >received Host header..." и далее по тексту - не имеет смысла.
> 
> В стандарте дается однозначное определение, что такое "proxy":
> 
>     A "proxy" is a message-forwarding agent that is selected
>     by the client, usually via local configuration rules.
> 
> nginx - это "reverse proxy" / "gateway", и все те требования,
> которые там предъявляются к "proxy", - к nginx не применимы.

Я нигде не говорил, что требование - применимо к nginx'у.  Я 
говорил, что упомянутое требование - не имеет смысла, если 
пользоваться предлагаемой интерпретацией термина "invalid 
field-value".

Прокси-сервер, помимо всего прочего, является сервером, и 
процитированное требование вернуть 400 в ответ на "Host header 
field with an invalid field-value" - к нему тоже относится.  
Соответственно, если трактовать термин "invalid field-value" как 
включающий проверку не только синтаксиса, но и требований, 
предъявляемых к формированию заголовка Host клиентом, то 
требование "ignore the received Host header" теряет смысл.

Впрочем, сама идея о том, что требования к клиенту как-либо 
опосредованно могут влиять на интерпретацию требований к серверу - 
она странная, если не сказать грубее.

> Как подходить к трактовке термина "invalid field-value"
> в RFC 7230 тоже написано: http://tools.ietf.org/html/rfc7230#section-1.1

Приведённая ссылка не имеет никакого отношения к термину "invalid 
field-value".

Теримн "field-value" расшифровывается в "3.2.  Header Fields", 
http://tools.ietf.org/html/rfc7230#section-3.2:

    field-value    = *( field-content / obs-fold )

Соответственно invalid - это то, что не соответствует указанному 
синтаксису.

На этом, наверно, и завершим нашу дискуссию, т.к. конструктивной 
она явно не получается.

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