Re: нормализация uri

[Gena Makhomed]

On 14.08.2020 17:27, Maxim Dounin wrote:

>> Есть такая конфигурация:
>>
>> client <=> nginx-frontend <=> nginx-backend <=> php-fpm
>>
>> Есть задача от SEO'шников/клиентов сделать так, чтобы несколько слешей,
>> идущих подряд в uri, превращались в один слеш с помощью 301 редиректа,
>> и чтобы точка в конце домена также убиралась с помощью 301 редиректа.
>>
>> Сейчас эту задачу можно решить только на стороне nginx-frontend
> 
> Никто не запрещает решать эту задачу на любых других уровнях, в
> том числе в php.  Другой вопрос, что если менять URI на строне
> nginx'а (например, проксируя с заменой части URI) - исходный URI
> придётся явно пробрасывать и отдельно обрабатывать.

Проксирование без замены части URI можно сделать так:
location / { proxy_pass http://172.16.1.124$request_uri; }
А как сделать проксирование с заменой части URI ?

Например, поменяв /path1/ на /path2/ при проксировании:
location /path1/ { proxy_pass http://172.16.1.124/path2/; }
не выключая при этом merge_slashes on; в конфиге nginx ?

Кроме того, задача убрать точку в конце домена example.com.
выглядит нерешаемой на уровне php, потому что на nginx-backend
запрос приходит уже без точки в конце доменного имени.

>> с помощью такого программирования на конфигах nginx для каждого
>> виртуального сервера:
>>
>>      # remove multiple sequences of forward slashes
>>      # The $uri variable with have duplicate slashes removed by default via [merge_slashes on] - just need to rewrite back to $uri
>>      # note: use of the "^[^?]*?" pattern avoids any matches in the querystring section of URI - which would cause an infinite redirect loop
>>      if ($request_uri ~ "^[^?]*?//") {
>>          rewrite "^" $scheme://$host$uri permanent;
>>      }
>>
>>      if ($http_host ~ "\.$") {
>>          rewrite "^" $scheme://$host$uri permanent;
>>      }
> 
> Отмечу, что тут "напрограммировано на конфигах" два XSS'а.
> Эту и другие подобные проблемы умеет, AFAIK, ловить
> https://github.com/yandex/gixy.

gixy говорит про Possible HTTP-Splitting vulnerability.
Using variables that can contain "\n" or "\r" may lead to http injection.
https://github.com/yandex/gixy/blob/master/docs/en/plugins/httpsplitting.md
Reason: At least variable "$uri" can contain "\n"

Где здесь XSS ?

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

-- 
Best regards,
  Gena