вт, 18 авг. 2020 г. в 13:16, Gena Makhomed <gmm@csdoc.com>:

> 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.
>

XSS предполагает, что атака идет на браузер. если (а это вполне легитимный
кейс)
клиент не браузер, то у него другая семантика и логика. и вы можете ему
что-то сломать.

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

но вы правы, есть WAF-ы, naxsi, например. если оператор реверс прокси
принимает решение, он, конечно, может себе втащить WAF-чик


>
> Просканировать строку на предмет наличия в ней символов
> "\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
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru