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

[Gena Makhomed]

On 17.06.2014 9:30, Maxim Dounin wrote:

>>>> 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-1.2 и
> далее.

Не все требования к синтаксису выражены в виде нормативных грамматик.
Например, требование отправлять первой строкой запроса request-line
- это тоже требование к синтаксису валидной HTTP request message.
Но это требование не выражено в виде Augmented Backus-Naur Form.

>> "SHOULD NOT" - это не запрет, а только лишь рекомендация:
>> http://tools.ietf.org/html/rfc2119#section-4
>> так что формально и фактически Chrome ничего не нарушает.
>
> Фактически - упомянутый "SHOULD NOT" на тот момент безусловно
> отклонялся Apache'ом,

И это безусловный BUG апача, копировать его в nginx - нет смысла.
Apache ведь не является reference implementation протокола HTTP/1.1

> а противоречащие друг другу Host +
> Request-Line - формально вообще ничего не нарушали

Вообще-то в RFC 2616 написано в точности то же самое что и в RFC 7230:

http://tools.ietf.org/html/rfc2616#section-14.23

    The Host request-header field specifies the Internet host and port
    number of the resource being requested, as obtained from the original
    URI given by the user or referring resource (generally an HTTP URL,
    as described in section 3.2.2). The Host field value MUST represent
    the naming authority of the origin server or gateway given by the
    original URL. This allows the origin server or gateway to
    differentiate between internally-ambiguous URLs, such as the root "/"
    URL of a server for multiple host names on a single IP address.

Здесь точно так же присутствует требование "MUST",
то есть клиент, который не выполнил это требование -
прислал на сервер невалидный запрос и сервер имеет
полное право ответить на такой запрос статусом 400.

> до выхода HTTPbis.

Выход HTTPbis так и не состоялся. Вместо этого - решили
уточнить спецификацию протокола HTTP/1.1 и сконцентировать
свои усилия в работе над протоколом HTTP/2.0 на базе SPDY,
насколько мне известно.

> И что на самом деле происходит в реальной жизни
> - это отдельный интересный вопрос.

В реальной жизни я не встречал софта, который бы создавал запросы

GET http://apple.com/ HTTP/1.1
Host: samsung.com

и ожидал бы, что такой запрос будет нормально обработан сервером.

> Среди прочего, например, HTTPbis явно требует возвращать 400,
> если запрос содержит несколько заголовков Host.

Нет смысла отправлять несколько одинаковых заголовков
с одинаковым значением. А разных значений там быть не должно.

Единственное что добавилось в RFC 7230 - это более явное требование,
чтобы такой заголовок был всего один. В RFC 2616 это было между строк.

> В своё время, однако, nginx'у потребовалось от этой практики отказаться:
>
> http://hg.nginx.org/nginx/rev/b9de93d804ea
>
> Если мне не изменяет память, причина была всё та же - реальная
> жизнь заставила.

Можно подробнее узнать про причину?

-- 
Best regards,
  Gena