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

[Gena Makhomed]

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 не применимы.

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

Сейчас nginx этим требованиям стандарта HTTP/1.1 не соответствует,
и пытается обрабатывать те запросы, на которые он на самом деле
MUST respond with a 400 (Bad Request) status code.

И это создает security проблемы с backend`ами, которые работают
по протоколу FastCGI и расчитывают на то, что nginx соответствует
требованиям стандарта HTTP/1.1 и не пропустит на backend запрос
с невалидным значением в заголовке Host. (RFC 2616 или RFC 7230)

Более правильно в этой ситуации наверное будет все-таки
привести nginx в соответствие с требованиями RFC 7230,
вместо того чтобы добавлять workaround`ы для этого бага
на стороне каждого backend`а, который работает с nginx.

=======================================================

Вопрос: признают ли разработчики nginx эту ошибку
и будет ли она исправлена в новых версиях сервера?

Второй вопрос: признается ли эта ошибка в nginx
проблемой с безопасностью (security vulnerability)
и будет ли по этому поводу выпущено CVE / advisorу
на http://nginx.org/en/security_advisories.html ?

-- 
Best regards,
  Gena