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

[Dmitry]

Не понял в чем проблема, чисто наитием использую давно:

# Add default fake server
include /..../default_server.conf;

где default_server.conf:
=================

server {
listen *:80 default_server;
server_name _;
return 403;
}



2014-06-11 15:25 GMT+04:00 Gena Makhomed <gmm at csdoc.com>:

> On 11.06.2014 13:42, Валентин Бартенев wrote:
>
>  http://habrahabr.ru/post/166855/
>>>>>>>>>
>>>>>>>>
>>>> Единственный правильный способ: пойти в IETF с предложением исправить
>>>> соответствующие RFC, которые в том числе оговаривают, что следует делать
>>>> при получении нескольких заголовков Host, ну а потом уже сюда.
>>>>
>>>
>>> http://tools.ietf.org/html/rfc7230#section-5.4
>>>
>>>      When a proxy receives a request with an absolute-form of
>>>      request-target, the proxy MUST ignore the received Host header field
>>>      (if any) and instead replace it with the host information of the
>>>      request-target.  A proxy that forwards such a request MUST generate
>>> a
>>>      new Host field-value based on the received request-target rather
>>> than
>>>      forward the received Host field-value.
>>>
>>> Referer: http://www.opennet.ru/opennews/art.shtml?num=39956
>>>
>>
>> Не очень понятно, а что хотели сказать этой цитатой?
>>
>> Так, на всякий случай, nginx не является "proxy" согласно терминологии
>> того
>> же RFC 7230.
>>
>
> Ok.
>
> 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).
>
> следовательно, если приходит запрос
>
> GET http://example.com/ HTTP/1.1
> Host: example.org
>
> - это "Host header field with an invalid field-value"
> и nginx "MUST respond with a 400 (Bad Request) status code".
>
> Если такой запрос приходит по HTTP/1.0 - в этой версии
> протокола нет absolute-form и тоже надо отвечать 400 статусом.
>
> текущее поведение nginx не соответствует требованиям RFC 7230 ?
>
> P.S.
>
> и да, отвечать с 400 статусом тут даже более логично,
> потому что если authority component в строке запроса
> и в заголовке Host: разные - это явно попытка взлома.
>
> --
> Best regards,
>  Gena
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
Dmitry Goryainov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140611/1aac1a07/attachment.html>