On 17.08.2020 17:58, Maxim Dounin wrote:

> HTTP response splitting предоставляет атакующему контроль над
> ответом, и XSS - одно из прямых и наиболее очевидных следствий.

>> И почему nginx не может закодировать "\n" or "\r" перед тем,
>> как применять $uri для построения проксированого запроса?
>> Это выглядит как не закрытая security vulnerability в nginx.

> Ничего не мешает, равно как и, скажем, заменить в отправляемом
> перенаправлении A на B. Тут и в остальных подобныых директивах
> (return, add_header, proxy_set_header, proxy_pass) nginx ожидает
> корректно закодированне значения.

Если эти ожидания не оправдались - nginx ведь может понять,
что ему не предоставили корректно закодированные значения.

И в таком случае - он может ведь вернуть 500 ошибку вместо
того, чтобы предоставлять атакующему возможность сделать XSS.

Например, проведите голосование среди пользователей nginx+,
какую реакцию nginx+ они предпочитают - 500 ошибку или XSS?
Я почти уверен, что никто не захочет, чтобы у них была XSS.

Просканировать строку на предмет наличия в ней символов
"\n" или "\r" окажет влияне на производительность
на уровне статистической погрешности, около нуля.

Почему нет? Ведь тогда nginx станет неуязвим к атаке
вида HTTP response splitting - разве это того не стоит?

Наверное нет смысла делать в nginx отдельную директиву
HTTP_response_splitting_security_vulnerability on/off;

> В случае директивы rewrite дополнительно гарантируется, что
> переменные $1..$9, полученные из раскодированного URI запроса с
> помощью регулярного выражения в первом параметре, будут
> рассматриваться как раскодированные.

Может быть имеет смысл для каждой переменной в nginx добавить
поле статуса, показывающее, является ли эта переменная
корректно закодированной или корректно раскодированной?

Тогда nginx смог бы сам на лету превращать раскодированные
переменные в закодированные, например, при использовании их
в тех директивах, где необходимо корректно закодированное
значение переменной.

>>>> Насколько высока вероятность того, что патч, реализующий
>>>> дополнительную функциональность merge_slashes redirect;
>>>> или normalize_uri on; будет принят в основную ветку nginx?
>>
>>> Задача не кажется типичной. Если очень хочется решать её силами
>>> nginx'а - я бы рекомендовал начать с инкапсуляции нужных
>>> перенаправленый в отдельных include-файлах, и/или решений на
>>> скриптовых языках, или же отдельного модуля для нормализации.
>>
>> Что написать в include-файлах вместо
>>
>> if ($request_uri ~ "^[^?]*?//") {
>> rewrite "^" $scheme://$host$uri permanent;
>> }
>>
>> if ($http_host ~ "\.$") {
>> rewrite "^" $scheme://$host$uri permanent;
>> }
>>
>> чтобы не было XSS ?
>
> rewrite ^(.*) $scheme://$host$1 permanent;

Спасибо. Получился такой конфиг:

if ($request_uri ~ "^[^?]*?//") { rewrite ^(.*) $scheme://$host$1
permanent; }
if ($http_host ~ "\.$") { rewrite ^(.*) $scheme://$host$1 permanent; }

Похоже, что это максимум из того, что можно выжать из nginx
в его современном виде и эту ситуацию уже никак улучшить нельзя?

Например, путем создания в nginx директивы normalize_uri со значением
по умолчанию on. Тогда все работало бы так как надо прямо из коробки.

Задача является более, чем типичной, вот например, такая проблема:
http://mailman.nginx.org/pipermail/nginx-ru/2014-April/053860.html
Здесь бы тоже normalize_uri on; было бы решением проблемы.

Случаев, когда normalize_uri on; будет создавать проблемы
при включенном merge_slashes on; не обнаружено ни одного.

--
Best regards,
Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru