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

[Gena Makhomed]

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 ?

Кроме того, в разделе 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-м статусом не будет лучше?

-- 
Best regards,
  Gena