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
_______________________________________________
nginx-ru mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx-ru
