Nginx alias не работает

Частые ошибки в настройках Nginx, из-за которых веб-сервер становится уязвимым

Nginx — это веб-сервер, на котором работает треть всех сайтов в мире. Но если забыть или проигнорировать некоторые ошибки в настройках, можно стать отличной мишенью для злоумышленников. Detectify Crowdsource подготовил список наиболее часто встречающихся ошибок, делающих сайт уязвимым для атак.

Nginx — один из наиболее часто используемых веб-серверов в Интернете, поскольку он модульный, отзывчивый под нагрузкой и может масштабироваться на минимальном железе. Компания Detectify регулярно сканирует Nginx на предмет неправильных настроек и уязвимостей, из-за которых могут пострадать пользователи. Найденные уязвимости потом внедряются в качестве теста безопасности в сканер веб-приложений.

Мы проанализировали почти 50 000 уникальных файлов конфигурации Nginx, загруженных с GitHub с помощью Google BigQuery. С помощью собранных данных удалось выяснить, какие ошибки в конфигурациях встречаются чаще всего. Эта статья прольёт свет на следующие неправильные настройки Nginx:

Отсутствует корневой каталог

Небезопасное использование переменных

Чтение необработанного ответа сервера

Отсутствует корневой каталог

Root-директива указывает корневую папку для Nginx. В приведённом выше примере корневая папка /etc/nginx , что означает, что мы можем получить доступ к файлам в этой папке. В приведенной выше конфигурации нет места для / (location / <. >) , только для /hello.txt . Из-за этого root-директива будет установлена ​​глобально, а это означает, что запросы к / перенаправят вас на локальный путь /etc/nginx .

Такой простой запрос, как GET /nginx.conf , откроет содержимое файла конфигурации Nginx, хранящегося в /etc/nginx/nginx.conf. Если корень установлен в /etc , запрос GET на /nginx/nginx.conf покажет файл конфигурации. В некоторых случаях можно получить доступ к другим файлам конфигурации, журналам доступа и даже зашифрованным учётным данным для базовой аутентификации HTTP.

Из почти 50 000 файлов конфигурации Nginx, которые мы проанализировали, наиболее распространёнными корневыми путями были следующие:

Потерявшийся слеш

При неправильной настройке off-by-slash можно перейти на один шаг вверх по пути из-за отсутствующей косой черты. Orange Tsai поделился информацией об этом в своём выступлении на Blackhat «Нарушение логики парсера!». Он показал, как отсутствие завершающей косой черты в location директиве в сочетании с alias директивой позволяет читать исходный код веб-приложения. Менее известно то, что это также работает с другими директивами, такими как proxy_pass . Давайте разберёмся, что происходит и почему это работает.

Если на Nginx запущена следующая конфигурация, доступная на сервере, можно предположить, что доступны только пути в http://apiserver/v1/ .

Когда запрашивается http://server/api/user , Nginx сначала нормализует URL. Затем он проверяет, соответствует ли префикс /api URL-адресу, что он и делает в данном случае. Затем префикс удаляется из URL-адреса, поэтому остаётся путь /user. Затем этот путь добавляется к URL-адресу proxy_pass , в результате чего получается конечный URL-адрес http://apiserver/v1//user .

Обратите внимание, что в URL-адресе есть двойная косая черта, поскольку директива местоположения не заканчивается косой чертой, а путь URL-адреса proxy_pass заканчивается косой чертой. Большинство веб-серверов нормализуют http://apiserver/v1//user до http://apiserver/v1/user , что означает, что даже с этой неправильной конфигурацией всё будет работать так, как ожидалось, и это может остаться незамеченным.

Эта неправильная конфигурация может быть использована путём запроса http://server/api../ , из-за чего Nginx запросит URL-адрес http://apiserver/v1/../ , который нормализован до http://apiserver/ . Уровень вреда от такой ошибки определяется тем, чего можно достичь, если использовать эту неправильную конфигурацию. Например, это может привести к тому, что статус сервера Apache будет отображаться с URL-адресом http://server/api../server-status , или он может сделать доступными пути, которые не должны быть общедоступными.

Одним из признаков того, что сервер Nginx имеет неправильную конфигурацию, является возврат сервером одинакового же ответа при удалении косой черты в URL-адресе. То есть, если http://server/api/user и http://server/apiuser возвращают один и тот же ответ, сервер может быть уязвимым. Он позволяет отправлять следующие запросы:

Небезопасное использование переменных

Некоторые фреймворки, скрипты и конфигурации Nginx небезопасно используют переменные, хранящиеся в Nginx. Это может привести к таким проблемам, как XSS, обход HttpOnly-защиты, раскрытие информации и в некоторых случаях даже RCE.

SCRIPT_NAME

С такой конфигурацией, как эта:

основная проблема будет заключаться в том, что Nginx отправит интерпретатору PHP любой URL-адрес, заканчивающийся на .php, даже если файл не существует на диске. Это распространённая ошибка во многих конфигурациях Nginx, и об этом говорится в документе «Ловушки и распространенные ошибки», созданном Nginx.

XSS возможен, если PHP-скрипт попытается определить базовый URL на основе SCRIPT_NAME ;

Использование $uri может привести к CRLF-инъекции

Другая неправильная конфигурация, связанная с переменными Nginx, заключается в использовании $uri или $document_uri вместо $request_uri .

$ur i и $document_uri содержат нормализованный URI, тогда как нормализация в Nginx включает URL-декодирование URI. В блоге Volema рассказывалось, что $uri обычно используется при создании перенаправлений в конфигурации Nginx, что приводит к внедрению CRLF.

Пример уязвимой конфигурации Nginx:

Символами новой строки для HTTP-запросов являются \r (возврат каретки) и \n (перевод строки). URL-кодирование символов новой строки приводит к следующему представлению символов %0d%0a . Когда эти символы включены в запрос типа http://localhost/%0d%0aDetectify:%20clrf на сервер с неправильной конфигурацией, сервер ответит новым заголовком с именем Detectify , поскольку переменная $uri содержит новые URL-декодированные строчные символы.

Произвольные переменные

В некоторых случаях данные, предоставленные пользователем, можно рассматривать как переменную Nginx. Непонятно, почему это происходит, но это встречается не так уж редко, а проверяется довольно-таки сложным путём, как видно из этого отчёта. Если мы поищем сообщение об ошибке, то увидим, что оно находится в модуле фильтра SSI, то есть это связано с SSI.

Одним из способов проверки является установка значения заголовка referer:

Мы просканировали эту неправильную конфигурацию и обнаружили несколько случаев, когда пользователь мог получить значение переменных Nginx. Количество обнаруженных уязвимых экземпляров уменьшилось, что может указывать на то, что уязвимость исправлена.

Чтение необработанного ответа сервера

С proxy_pass Nginx есть возможность перехватывать ошибки и заголовки HTTP, созданные бэкендом (серверной частью). Это очень полезно, если вы хотите скрыть внутренние сообщения об ошибках и заголовки, чтобы они обрабатывались Nginx. Nginx автоматически предоставит страницу пользовательской ошибки, если серверная часть ответит ей. А что происходит, когда Nginx не понимает, что это HTTP-ответ?

Если клиент отправляет недопустимый HTTP-запрос в Nginx, этот запрос будет перенаправлен на серверную часть как есть, и она ответит своим необработанным содержимым. Тогда Nginx не распознает недопустимый HTTP-ответ и просто отправит его клиенту. Представьте себе приложение uWSGI, подобное этому:

И со следующими директивами в Nginx:

proxy_intercept_errors будет обслуживать пользовательский ответ, если бэкенд имеет код ответа больше 300. В нашем приложении uWSGI выше мы отправим ошибку 500, которая будет перехвачена Nginx.

proxy_hide_header почти не требует пояснений; он скроет любой указанный HTTP-заголовок от клиента.

Если мы отправим обычный GET-запрос, Nginx вернёт:

Но если мы отправим неверный HTTP-запрос, например:

То получим такой ответ:

merge_slashes отключены

Для директивы merge_slashes по умолчанию установлено значение «on», что является механизмом сжатия двух или более слешей в один, поэтому /// станет / . Если Nginx используется в качестве обратного прокси и проксируемое приложение уязвимо для включения локального файла, использование дополнительных слешей в запросе может оставить место для его использования. Об этом подробно рассказывают Дэнни Робинсон и Ротем Бар.

Мы нашли 33 Nginx-файла, в которых для параметра merge_slashes установлено значение «off».

Попробуйте сами

Мы создали репозиторий GitHub, где вы можете использовать Docker для настройки своего собственного уязвимого тестового сервера Nginx с некоторыми ошибками конфигурации, обсуждаемыми в этой статье, и попробуйте найти их самостоятельно!

Вывод

Nginx — это очень мощная платформа веб-серверов, и легко понять, почему она широко используется. Но с помощью гибкой настройки вы даёте возможность совершать ошибки, которые могут повлиять на безопасность. Не позволяйте злоумышленнику взломать ваш сайт слишком легко, не проверяя эти распространённые ошибки конфигурации.

Вторая часть будет позднее.

Что ещё интересного есть в блоге Cloud4Y

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.

Источник

Nginx, почему не работает root/alias в location?

Имеется следующая конфигурация nginx:

Проблема в том, по адресу my_ip/yii2-test-job лезет 404 ошибка. Директория /var/www/default/yii2-test-job/web — 100% существует. Просто my_ip работает.

Если вне location поставить
root /var/www/default/yii2-test-job/web;

Все будет работать. А вот почему не работает именно location /yii2-test-job ?

• Вопрос задан более трёх лет назад
• 9257 просмотров

Конечно работает, но только в контексте location /yii2-test-job .

Как только try_files сделал внутренний редирект на /index.php (ктати, никогда не понимал нафига там дописывать ?$args ), вы попадаете в location

\.php$ и там действует root сервера.

UPD: Я бы написал так:

Первая секция
set $dir «/var/www/default/yii2-test-job/web»;
2 секция
set $dir «/var/www/default»;

Получилось что-то странное.
Корневая секция вообще не работает (404 от nginx)
Секция /yii2-test-job перехватывается yii2 и дает 404 ошибку (рендерит yii2, причем без ресурсов)

Я вспомнил, что около года назад мучался с тойже проблемой, не смог решить и переехал на поддомены. Но в этот раз в моем распоряжении только ip адрес.

Источник

Nginx — static file serving confusion with root & alias

I need to serve my app through my app server at 8080 , and my static files from a directory without touching the app server. The nginx config I have is something like this.

Now, with this config, everything is working fine. Note that the root directive is commented out.

If I activate root and deactivate the alias — it stops working. However, when I remove the trailing /static/ from the root it starts working again.

Can someone explain what’s going on. Also please explain clearly and verbosely what are the differences between root and alias , and their purposes.

8 Answers 8

I have found answers to my confusions.

There is a very important difference between the root and the alias directives. This difference exists in the way the path specified in the root or the alias is processed.

In case of the root directive, full path is appended to the root including the location part, whereas in case of the alias directive, only the portion of the path NOT including the location part is appended to the alias.

Let’s say we have the config

In this case the final path that Nginx will derive will be

This is going to return 404 since there is no static/ within static/

This is because the location part is appended to the path specified in the root . Hence, with root , the correct way is

On the other hand, with alias , the location part gets dropped. So for the config

the final path will correctly be formed as

In a way this makes sense. The alias just let’s you define a new path to represent an existing «real» path. The location part is that new path, and so it gets replaced with the real path. Think of it as a symlink.

Root, on the other hand is not a new path, it contains some information that has to be collated with some other info to make the final path. And so, the location part is used, not dropped.

The case for trailing slash in alias

There is no definitive guideline about whether a trailing slash is mandatory per Nginx documentation, but a common observation by people here and elsewhere seems to indicate that it is.

A few more places have discussed this, not conclusively though.

Источник

nginx alias не работает для папки статических файлов

Я не знаю, почему псевдоним nginx не работает.

Почему эта строка не работает:

На самом деле, возможно, он работает, но мои статические файлы с учетной записью администратора не обслуживаются. Я получаю ошибку, что static/admin/. не существует.

Я предполагаю, что он служит только файлам в статической папке, но не в папке static_root, где все файлы собираются командой manage.py collectstatic

Вот моя конфигурация:

Я узнал, что псевдоним не работает из-за:

У вас есть предложения по его устранению? Потому что, когда я удаляю этот static_root, работает.

Просмотр документации по конфигурации location в nginx:

Место может быть определено строкой префикса или регулярным выражением. Регулярные выражения задаются с помощью предыдущего модификатора «

*» (для нечувствительности к регистру) или модификатора «

» (для сопоставления с учетом регистра). Чтобы найти местоположение, соответствующее заданному запросу, nginx сначала проверяет местоположения, определенные с помощью префиксных строк (места префикса). Среди них выбирается и запоминается местоположение с самым длинным совпадающим префиксом. Затем проверяются регулярные выражения в порядке их появления в файле конфигурации. Поиск регулярных выражений заканчивается в первом совпадении, и используется соответствующая конфигурация. Если совпадение с регулярным выражением не найдено, используется ранее используемая ранее конфигурация расположения префикса.

Случай из вашего вопроса можно объяснить следующим образом:

Когда вы пытаетесь получить доступ к статическому файлу (который, как я полагаю, является одним из css, js или медиафайлов), он сначала соответствовал строке префикса:

Затем он начинает поиск регулярных выражений, а в случае css или js файла следующее будет соответствовать:

Если поиск завершен, и указанная конфигурация используется. И в этом псевдониме конфигурации не определен, поэтому псевдоним не используется.

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

Источник