Безопасность логов

В статье:

Логи лежат вне корня сайта

Каталог логов — \Shef\Problems\Main\Constants::getLogDir(). По умолчанию он на уровень выше корня сайта:

корень сайтакаталог логов
/home/bitrix/www (BitrixVM)/home/bitrix/sh_log
/var/www/portal/var/www/sh_log

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

До 2.0.0 логи лежали в /local/sh_log — под корнем сайта, и /local/ в стандартной поставке BitrixVM не закрыт. Имена файлов предсказуемы (log.log, sh_problems_sale.log), так что скачать их мог любой.

Свой каталог

Если рядом с корнем сайта писать нельзя или логи нужны в другом месте, проект задаёт каталог в /bitrix/.settings_extra.php:

return [
    'shef.problems' => [
        'value' => [
            'logDir' => '/var/log/portal',
        ],
        'readonly' => true,
    ],
];

Принимается только абсолютный путь. Относительный зависел бы от текущего каталога процесса: агент из cron писал бы в одно место, а страница — в другое. Что-то кроме абсолютного пути — каталог по умолчанию.

Каталог обязан быть вне корня сайта — модуль это не проверяет, это решение проекта.

Права и open_basedir

Каталог создаётся сам при первой записи — если пользователь PHP может писать в его родителя. На BitrixVM /home/bitrix принадлежит bitrix, всё работает из коробки. В другом окружении создайте каталог заранее:

sudo mkdir /var/www/sh_log && sudo chown www-data: /var/www/sh_log

Если в PHP задан open_basedir, каталог логов должен в него входить — иначе запись в файл не пройдёт. В логе PHP появятся предупреждения open_basedir restriction in effect от самого Monolog и строка shef.problems: запись логгера … не прошла: UnexpectedValueException …. Вызывающий код при этом не падает — у логгеров модуля (сервисы из .settings.php, фабрика проблем). _log() и _log1() пишут мимо Monolog, через File::putFileContents(), и строки shef.problems: от них не будет.

После обновления с 1.x

Старый каталог /local/sh_log модуль не трогает: в нём ваши данные. Но он по-прежнему открыт веб-серверу. Перенесите нужное и удалите его:

mv /home/bitrix/www/local/sh_log/*.log /home/bitrix/sh_log/ 2>/dev/null
rm -r /home/bitrix/www/local/sh_log

И поправьте пути в /etc/logrotate.d/, если настраивали ротацию — пример.

Если проект кладёт в каталог логов exceptions.log (exception_handling в /bitrix/.settings.php) или mailer.log, перенесите и эти пути.

Логи смотреть через админку

Раз каталог вне корня сайта, ни прямая ссылка, ни файловый менеджер Битрикса до него не дотянутся. Смотреть логи — страницей модуля /bitrix/admin/shef_problems_logs.php (Настройки → Учёт проблем → Логи):

  • только администратору;
  • имя файла из запроса проверяется дважды — по шаблону (буквы, цифры, _, -, расширение .log, номер ротации) и после разрешения пути: файл обязан лежать внутри каталога логов, символическая ссылка наружу отсекается;
  • показывается конец файла, не больше 256 КБ;
  • содержимое экранируется.

Держит это \Shef\Problems\Main\LogFiles, сторожит tests/logfiles_test.php.

Вывод на экран экранируется

_pr(), PrHandler и PrHtmlHandler печатают запись прямо в страницу. Всё, что пришло из записи, экранируется: в сообщение и контекст попадает в том числе ввод посетителя, а смотрит на вывод администратор — непроэкранированный вывод был бы хранимым XSS в его браузере. До 2.0.0 так и было.

Показывать вывод всем (isShowForAll: true) — только на стенде: там может оказаться что угодно из контекста.

Ключи и токены — не в код

Обработчики с ключами (Telegram, Slack, почта) настраиваются в /bitrix/.settings_extra.php, который не уезжает в репозиторий проекта, — см. Monolog.

← Ротация логов | ↑ Содержание

Источник: problems/docs/security.md — правки туда, сайт пересобирается сам.
CtrlI