Перейти к содержанию

Раскрытие папки User⚓︎

В панели управления Grav появляется уведомление такого вида, когда он может прочитать файл из вашей папки user/ напрямую через веб:

Your web server is not applying Grav's access rules.

Эта страница объясняет, что это значит и как это исправить. Это рекомендация по конфигурации, а не признак того, что с вашим сайтом что-то не так.

Что-то находится под риском?⚓︎

Для стандартной установки Grav — нет. Grav не хранит ничего чувствительного в user/data, и в каждом релизе поставляются конфигурации веб-сервера (.htaccess для Apache, а также nginx.conf и другие в папке webserver-configs/), которые блокируют прямой доступ к этим папкам. На сервере, который применяет эти правила, ничего из этого не доступно.

Уведомление просто означает, что эти правила сейчас не применяются, поэтому файлы из user/ можно запрашивать напрямую. Стоит это исправить по двум причинам:

  1. Сторонние плагины. Некоторые плагины хранят данные в user/data. Если плагин сохраняет там что-то приватное, вы захотите защитить это так же, как и остальную часть сайта.
  2. Те же правила распространяются на несколько папок. Их применение также делает приватными user/accounts и user/config, что является хорошей практикой в любом случае.

Включение правил обратно занимает несколько строк конфигурации, что описано ниже.

Почему это происходит⚓︎

Grav полагается на веб-сервер в вопросе запрета прямых запросов к своим приватным папкам. Блокировка перестаёт работать, когда:

  • Вы используете Apache, но файлы .htaccess игнорируются, потому что AllowOverride установлен в None для корня вашего сайта. Это самая распространённая причина.
  • Вы используете Nginx, Caddy, LiteSpeed или другой сервер, который вообще не читает .htaccess, и эквивалентные правила никогда не добавлялись в конфигурацию сайта.
  • Пользовательская или предоставленная хостингом конфигурация сервера заменила правила Grav без переноса этих блокировок.

Как исправить⚓︎

Цель одинакова на любом сервере: запретить прямой веб-доступ к user/accounts, user/config, user/env и user/data (при этом по-прежнему разрешать отдавать публичные медиафайлы, загруженные в user/data, например изображения).

Apache⚓︎

Сначала убедитесь, что .htaccess учитывается. В вашем виртуальном хосте (или соответствующем блоке <Directory>) установите:

<Directory /var/www/grav>
    AllowOverride All
    Require all granted
</Directory>

Перезагрузите Apache (sudo systemctl reload apache2 или sudo apachectl graceful). Встроенный в Grav файл .htaccess уже содержит правила ниже, поэтому как только AllowOverride All станет активным, вы будете защищены:

# Block all direct access to these sensitive user folders, whatever the file type
RewriteRule ^(user)/(accounts|config|env)/(.*) error [F]
# Block user/data too, but allow public media uploads (e.g. Flex Object images)
RewriteCond %{REQUEST_URI} !\.(jpe?g|png|gif|webp|avif|bmp|ico|mp4|webm|ogg|ogv|mov|mp3|wav|m4a|flac|pdf)$ [NC]
RewriteRule ^(user)/data/(.*) error [F]

Если вы не можете включить AllowOverride, скопируйте эти правила в конфигурацию вашего виртуального хоста вместо этого.

Если вы заменили или сильно отредактировали поставляемый .htaccess, сравните его с текущей версией в репозитории Grav и убедитесь, что блок Security присутствует.

Nginx⚓︎

Nginx не читает .htaccess. Добавьте эти блоки location в конфигурацию вашего сайта (они уже присутствуют в поставляемом файле webserver-configs/nginx.conf):

# deny all direct access to these sensitive user folders, whatever the file type
location ~* /user/(accounts|config|env)/.*$ { return 403; }
# allow public media uploads under user/data to be served directly;
# this must come before the user/data deny so it wins the match
location ~* /user/data/.*\.(jpe?g|png|gif|webp|avif|bmp|ico|mp4|webm|ogg|ogv|mov|mp3|wav|m4a|flac|pdf)$ { try_files $uri =404; }
# deny everything else under user/data
location ~* /user/data/.*$ { return 403; }

Затем перезагрузите Nginx (sudo nginx -t && sudo systemctl reload nginx). Полная рекомендуемая конфигурация описана в разделе Nginx.

Caddy⚓︎

Caddy также игнорирует .htaccess. Добавьте matcher, который возвращает 403 для приватных папок, перед вашими директивами php_fastcgi/file_server:

@gravBlocked path_regexp /user/(accounts|config|env)/.* /user/data/.*
respond @gravBlocked 403

Если вы отдаёте публичные медиафайлы из user/data, разместите более конкретный matcher для разрешённых расширений изображений и медиа перед этим блоком, чтобы такие запросы продолжали успешно обрабатываться.

LiteSpeed⚓︎

LiteSpeed читает .htaccess и совместим с правилами Grav для Apache, поэтому достаточно включить поддержку .htaccess (аналог AllowOverride All). Убедитесь, что правила перезаписи включены для виртуального хоста.

За обратным прокси, CDN или на управляемом хостинге⚓︎

Если ваш сайт находится за обратным прокси или CDN, либо работает на управляемом/разделяемом хостинге, правила должны применяться на том слое, который реально отдаёт файлы. Если не уверены, какой сервер находится спереди — уточните у вашего хостера.

Проверка исправления⚓︎

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

Вы также можете проверить вручную. Запрос вида https://www.example.com/user/config/system.yaml должен возвращать 403 Forbidden или 404 Not Found, а не содержимое файла.

Примечание о публичных медиафайлах в user/data⚓︎

Grav намеренно разрешает прямую отдачу обычных изображений, аудио, видео и PDF-файлов из user/data, чтобы медиа, загруженные через Flex-объекты и подобные поля, продолжали работать. Это сделано по дизайну и не является причиной предупреждения. Предупреждение срабатывает только когда не-медиа файлы из ваших приватных папок становятся доступны. Для безопасной отдачи приватных или произвольных загруженных файлов лучше маршрутизировать их через прокси на уровне приложения, а не открывать папку напрямую.