NGINX уменьшает% 2f до косой черты. Как я могу остановить его?

Скажем, я хочу закодировать заголовок статьи в URL-адресе и содержать косую черту. Если я кодирую URL-адрес заголовка статьи, я получаю:

http://example.com/articles/foo%2fbar/view/

NGINX передает это приложение моему FastCGI как:

http://example.com/articles/foo/bar/view/

Который скорее разрушает идею.

Я замечаю, что если NGINX обслуживает файл, скажем /path/to/page.html, то он может быть достигнут одним из следующих двух URL-адресов:

http://example.com/path/to/page.html
http://example.com/path/to%2fpage.html

Однако это не относится к (например) Apache.

Есть ли способ исправить это поведение?

Я пробовал документы и Google без везения.

Спасибо.

UPDATE

nginx config:

worker_processes  1;
pid ./nginx.pid;
events {
    worker_connections  1024;
}
http {
    server_tokens off;
    server {
        listen 80;
        server_name localhost;
        location /mysite/{
            fastcgi_pass   unix: ./mysite.fcgi.socket;

            fastcgi_param SERVER_NAME $server_name;
            fastcgi_param SERVER_PORT $server_port;
            fastcgi_param SERVER_PROTOCOL $server_protocol;
            fastcgi_param SCRIPT_NAME "/mysite/";
            fastcgi_param PATH_INFO $fastcgi_path_info;
            fastcgi_param REQUEST_METHOD $request_method;
            fastcgi_param QUERY_STRING $query_string;
            fastcgi_param CONTENT_TYPE $content_type;
            fastcgi_param CONTENT_LENGTH $content_length;
            fastcgi_pass_header Authorization;
            fastcgi_intercept_errors off;
        }
    }

}

Ответы

Ответ 1

Попробуйте выполнить "%" как "% 25" 

http://example.com/articles/foo%252fbar/view/

Ответ 2

У вас не будет проблем, если вы используете параметры URL-запроса. Когда вы можете контролировать маршруты своих серверов, вы можете пойти:

http://example.com/articles/view/?path=foo%2fbar

и nginx не коснется% 2f

Ответ 3

Более подробная информация по этому вопросу представлена в подкаталоге Nginx pass_proxy без декодирования URL, что дает полное решение, если вы являетесь пользователем proxy_pass.

С fastcgi_pass это может произойти из-за conf/fastcgi.conf по умолчанию в nginx, где переменная DOCUMENT_URI установлена в http://nginx.org/r/$document_uri, что эквивалентно просто http://nginx.org/r/$ uri, которая, в свою очередь, является нормализованной (декодированной и неэкранированной), без запросов и потенциально переписанной версией http://nginx.org/r/$request_uri (к которой, в свою очередь, можно получить доступ через REQUEST_URI вместо):

  fastcgi_param  REQUEST_URI        $request_uri;
  fastcgi_param  DOCUMENT_URI       $document_uri;

В вашем случае, однако, вы на самом деле не указываете DOCUMENT_URI вообще, поскольку http://nginx.org/r/fastcgi_param не наследуется от предыдущего уровня, если используется на текущем уровне, поэтому, возможно, что декодированный путь выходит из вашего http://nginx.org/r/$fastcgi_path_info, который должен быть в паре с http://nginx.org/r/fastcgi_split_path_info, который вы пропускаете из предоставленной конфигурации, так что оригинал вопрос может показаться противоречивым, поскольку точные пути между предоставленными запросами и примером конфигурации тоже не совпадают.

В fastcgi случае, лучшее решение для fastcgi зависит от приложения и может быть одним из следующих:

  • Не зависит от того, какие пути не декодируются и не очищаются должным образом с помощью nginx. Вероятно, это лучшее исправление в плане безопасности, поскольку вы в основном просите nginx не очищать такие вещи, как /../ (включая все экранированные варианты), что, безусловно, предназначено для защиты вас от целого класса уязвимостей. в вашем бэкэнде.
  • Перепроектируйте весь интерфейс, чтобы использовать параметры запроса в QUERY_STRING чтобы пути не смешивались и не декодировались преждевременно.
  • Используйте REQUEST_URI чтобы получить исходный URI запроса без какой-либо нормализации или декодирования.
  • Обратите особое внимание на все случаи использования $uri или $document_uri, а также, возможно, и $fastcgi_path_info, которые обычно содержат декодированные и нормализованные пути.
  • Используйте приемы перезаписи, как указано в связанном ответе, чтобы поместить не кодированный $request_uri обратно в $uri. Обратите внимание, что вам также может понадобиться удалить строку запроса вручную, если вы пойдете по этому пути.

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

Тот факт, что то, что вы хотите сделать, работает в Apache "как есть", является скорее ошибкой, чем функцией - это работает по-другому в nginx по конструкции и для предотвращения целого класса уязвимостей безопасности.