On 16.06.2014 15:00, Maxim Dounin wrote:
озвученные в 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).
- это ведь требования к синтаксису, которые обязательны для выполнения.
Нет, это не требования к синтаксису, это требования к семантике.
Запись target URI в виде valid request message - это разве не syntax?
http://tools.ietf.org/html/rfc7231#section-2
When a client constructs an HTTP/1.1 request message, it sends the
target URI in one of various forms, as defined in (Section 5.3 of
[RFC7230]). When a request is received, the server reconstructs an
effective request URI for the target resource (Section 5.5 of
[RFC7230]).
One design goal of HTTP is to separate resource identification from
request semantics, which is made possible by vesting the request
semantics in the request method (Section 4) and a few
request-modifying header fields (Section 5).
"effective request URI" - это именно что resource identification.
Они ведь разнесли "syntax" и "semantics" по двум отдельным документам:
RFC 7230: Message Syntax and Routing
RFC 7231: Semantics and Content
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 более или менее в любой момент.
Да, но здесь явно указывается, когда сервер возвращает 400:
в случае client error, например, "malformed request syntax"
или "deceptive request routing" - эти две причины подходят.
Кроме того, в разделе 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",
когда считает нужным/возможным.
"SHOULD NOT" - это не запрет, а только лишь рекомендация:
http://tools.ietf.org/html/rfc2119#section-4
так что формально и фактически Chrome ничего не нарушает.
В обсуждаемой выше ситуации написано совсем иначе: "MUST".
http://tools.ietf.org/html/rfc2119#section-1
и если клиент этого не сделал - он сам прислал невалидный запрос,
так что ответить 400-м статусом на такой запрос - вполне разумно.
да и в RFC 7230 об этом тоже есть (про поведение хрома):
http://tools.ietf.org/html/rfc7230#section-2.3
server MUST NOT assume that two requests on the same connection are
from the same user agent unless the connection is secured and
specific to that agent. Some non-standard HTTP extensions (e.g.,
[RFC4559]) have been known to violate this requirement, resulting in
security and interoperability problems.
То, как ведёт себя nginx по умолчанию - вполне себе безопасно,
и проблемы нет. Какая-либо проблема появляется тогда и только
тогда, когда администратор начинает писать в конфиге $http_host,
не думая о последствиях. Есть мнение, что совсем простое решение
этой проблемы - не делать так (c) анекдот.
Когда nginx выполняет роль origin server или HTTP reverse proxy
- тогда проблем действительно нет, но когда он выполняет роль
"gateway" и communicates с backend`ом по протоколу FastCGI -
тогда получаются очень неприятные проблемы.
Причина проблем: malformed request syntax,
который не получается корректным образом передать на backend.
Что мешает в этой ситуации вернуть 400 статус? Вместо того,
чтобы отсылать на backend невалидный запрос, интерпретируя
клиентский запрос не по спецификации HTTP/1.1 а по спецификации
CGI/1.1, которая не согласуется со спецификацией протокола HTTP/1.1.
Ничего ведь не сломается и на backend не уйдет misdirected запрос.
И даже отдельной директивы никакой не надо будет создавать для этого.
Никакой легальный клиент не пострадает от этого изменения в nginx,
потому что никто кроме взломщиков не создает таких misdirected запросов,
которые не соответствуют обязательным требованиям к клиентским запросам.
--
Best regards,
Gena
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
