<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">вт, 18 авг. 2020 г. в 13:16, Gena Makhomed <<a href="mailto:gmm@csdoc.com">gmm@csdoc.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 17.08.2020 17:58, Maxim Dounin wrote:<br>
<br>
> HTTP response splitting предоставляет атакующему контроль над<br>
> ответом, и XSS - одно из прямых и наиболее очевидных следствий.<br>
<br>
>> И почему nginx не может закодировать "\n" or "\r" перед тем,<br>
>> как применять $uri для построения проксированого запроса?<br>
>> Это выглядит как не закрытая security vulnerability в nginx.<br>
<br>
> Ничего не мешает, равно как и, скажем, заменить в отправляемом<br>
> перенаправлении A на B. Тут и в остальных подобныых директивах<br>
> (return, add_header, proxy_set_header, proxy_pass) nginx ожидает<br>
> корректно закодированне значения.<br>
<br>
Если эти ожидания не оправдались - nginx ведь может понять,<br>
что ему не предоставили корректно закодированные значения.<br>
<br>
И в таком случае - он может ведь вернуть 500 ошибку вместо<br>
того, чтобы предоставлять атакующему возможность сделать XSS.<br>
<br>
Например, проведите голосование среди пользователей nginx+,<br>
какую реакцию nginx+ они предпочитают - 500 ошибку или XSS?<br>
Я почти уверен, что никто не захочет, чтобы у них была XSS.<br></blockquote><div><br></div><div>XSS предполагает, что атака идет на браузер. если (а это вполне легитимный кейс) <br></div><div>клиент не браузер, то у него другая семантика и логика. и вы можете ему что-то сломать.</div><div><br></div><div>nginx как реверс прокси ничего не знает про семантику приложения. но про нее знают</div><div>на бекенде. кажется, что данные штуки логично тащить на бекенд</div><div><br></div><div>но вы правы, есть WAF-ы, naxsi, например. если оператор реверс прокси</div><div>принимает решение, он, конечно, может себе втащить WAF-чик<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Просканировать строку на предмет наличия в ней символов<br>
"\n" или "\r" окажет влияне на производительность<br>
на уровне статистической погрешности, около нуля.<br>
<br>
Почему нет? Ведь тогда nginx станет неуязвим к атаке<br>
вида HTTP response splitting - разве это того не стоит?<br>
<br>
Наверное нет смысла делать в nginx отдельную директиву<br>
HTTP_response_splitting_security_vulnerability on/off;<br></blockquote><div><br></div><div>поменять поведение по умолчанию и сломать кому-то сценарии, так себе удовольствие<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> В случае директивы rewrite дополнительно гарантируется, что<br>
> переменные $1..$9, полученные из раскодированного URI запроса с<br>
> помощью регулярного выражения в первом параметре, будут<br>
> рассматриваться как раскодированные.<br>
<br>
Может быть имеет смысл для каждой переменной в nginx добавить<br>
поле статуса, показывающее, является ли эта переменная<br>
корректно закодированной или корректно раскодированной?<br>
<br>
Тогда nginx смог бы сам на лету превращать раскодированные<br>
переменные в закодированные, например, при использовании их<br>
в тех директивах, где необходимо корректно закодированное<br>
значение переменной.<br>
<br>
>>>> Насколько высока вероятность того, что патч, реализующий<br>
>>>> дополнительную функциональность merge_slashes redirect;<br>
>>>> или normalize_uri on; будет принят в основную ветку nginx?<br>
>><br>
>>> Задача не кажется типичной. Если очень хочется решать её силами<br>
>>> nginx'а - я бы рекомендовал начать с инкапсуляции нужных<br>
>>> перенаправленый в отдельных include-файлах, и/или решений на<br>
>>> скриптовых языках, или же отдельного модуля для нормализации.<br>
>><br>
>> Что написать в include-файлах вместо<br>
>><br>
>> if ($request_uri ~ "^[^?]*?//") {<br>
>> rewrite "^" $scheme://$host$uri permanent;<br>
>> }<br>
>><br>
>> if ($http_host ~ "\.$") {<br>
>> rewrite "^" $scheme://$host$uri permanent;<br>
>> }<br>
>><br>
>> чтобы не было XSS ?<br>
> <br>
> rewrite ^(.*) $scheme://$host$1 permanent;<br>
<br>
Спасибо. Получился такой конфиг:<br>
<br>
if ($request_uri ~ "^[^?]*?//") { rewrite ^(.*) $scheme://$host$1 <br>
permanent; }<br>
if ($http_host ~ "\.$") { rewrite ^(.*) $scheme://$host$1 permanent; }<br>
<br>
Похоже, что это максимум из того, что можно выжать из nginx<br>
в его современном виде и эту ситуацию уже никак улучшить нельзя?<br>
<br>
Например, путем создания в nginx директивы normalize_uri со значением<br>
по умолчанию on. Тогда все работало бы так как надо прямо из коробки.<br>
<br>
Задача является более, чем типичной, вот например, такая проблема:<br>
<a href="http://mailman.nginx.org/pipermail/nginx-ru/2014-April/053860.html" rel="noreferrer" target="_blank">http://mailman.nginx.org/pipermail/nginx-ru/2014-April/053860.html</a><br>
Здесь бы тоже normalize_uri on; было бы решением проблемы.<br>
<br>
Случаев, когда normalize_uri on; будет создавать проблемы<br>
при включенном merge_slashes on; не обнаружено ни одного.<br>
<br>
-- <br>
Best regards,<br>
Gena<br>
<br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote></div></div>