Безопасность в DLE: что проверять на ревью

На ревью сайта на DataLife Engine недостаточно проверить версию CMS и наличие SSL-сертификата. Реальный риск обычно появляется в самописном модуле, шаблоне с выводом пользовательских данных, обработчике загрузки или слишком широких правах на каталог. Этот разбор рассчитан на DLE 17.x: номера минорных релизов и требования к серверу перед проверкой нужно сверить с документацией конкретной установки.

Что именно проверять на ревью

Безопасность DLE-проекта складывается из пяти слоёв: ядро, расширения, код сайта, конфигурация сервера и права пользователей. Если смотреть только на PHP-файлы движка, можно пропустить уязвимость, через которую злоумышленник меняет шаблон или загружает исполняемый файл.

Первый проход: инвентаризация и версия

Начинайте не с поиска подозрительной строки, а с карты проекта. Зафиксируйте версию DLE 17.x, версию PHP, список установленных модулей, шаблон, cron-задачи, точки входа AJAX и каталоги, доступные для записи веб-серверу. Отдельно отметьте файлы, изменённые относительно чистой поставки.

Ревьюер должен получить ответ на три вопроса:

• какие компоненты действительно нужны сайту;
• кто и когда обновляет DLE, плагины и PHP;
• можно ли восстановить сайт после компрометации.

Если команда не может показать список модулей и резервную копию, проверка уже обнаружила процессный риск. Установка «работает» не означает, что её можно безопасно обновить или быстро восстановить.

Скрытый URL админки снижает количество случайных попыток входа, но не заменяет обновления, двухфакторную защиту и ограничение доступа.

Ввод данных: где искать инъекции и XSS

В DLE пользовательские данные проходят через комментарии, формы обратной связи, поиск, дополнительные поля и параметры модулей. На ревью нужно проследить путь каждого значения: от HTTP-запроса до SQL-запроса, HTML-страницы, атрибута или JavaScript-кода.

Что проверять в самописном коде

• Параметры из $_GET, $_POST, $_COOKIE и заголовков не должны напрямую попадать в SQL, HTML или имя файла.
• Проверка формата должна происходить на сервере. Ограничение длины в браузере не защищает обработчик.
• Для числового идентификатора нужен числовой контракт, а не простое доверие параметру с именем id.
• Перед выводом в HTML нужно учитывать контекст: текст, атрибут, URL и JavaScript требуют разных правил экранирования.
• Нельзя считать безопасным значение только потому, что его ввёл авторизованный пользователь. Учётная запись редактора тоже может быть скомпрометирована.

Особенно внимательно проверяйте дополнительные поля и шаблоны. Значение, безопасное как обычный текст, становится опасным, если шаблон выводит его внутри атрибута, обработчика события или фрагмента JavaScript.

Сноска. XSS, или межсайтовый скриптинг, — выполнение чужого JavaScript в браузере посетителя через данные, которые сайт вывел без правильного экранирования.

Как формулировать замечание

Слабое замечание звучит так: «проверьте валидацию». Оно не помогает исправить проблему. Лучше написать: «значение дополнительного поля попадает в HTML-атрибут без экранирования; проверить вывод в шаблоне и добавить тест со строкой, содержащей кавычки и HTML-теги». Для SQL: «параметр формируется конкатенацией; заменить ручную сборку на безопасный механизм работы с базой, который принят в этой версии DLE, и проверить запрос на граничных значениях».

Загрузка файлов: проверяйте не только расширение

Проверка имени файла на суффикс вроде .jpg не доказывает, что внутри находится изображение. Имя можно изменить, MIME-заголовок подделать, а каталог загрузки может разрешать выполнение скриптов. Ревью должно пройти весь маршрут: приём, проверка, переименование, сохранение и последующая раздача файла.

1. Определите список допустимых типов. Он должен быть ограниченным и соответствовать бизнес-задаче. Если сайту нужны только изображения, документы и архивы не должны приниматься «на всякий случай».
2. Проверьте содержимое. Сервер должен проверять фактический тип файла, а не только расширение и заголовок запроса.
3. Проверьте имя. Пользовательское имя не должно становиться путём на диске. Нужны безопасное переименование и защита от переходов в родительский каталог.
4. Проверьте каталог. Уточните, может ли веб-сервер исполнять файлы из директории загрузок. Если нет — путь к загруженному объекту всё равно не должен раскрывать внутреннюю структуру сервера.
5. Проверьте размер и лимиты. Ограничения должны действовать на сервере и учитывать лимиты PHP, прокси и веб-сервера.

Отдельно протестируйте загрузку файла с двойным расширением, необычным регистром букв, длинным именем и подменённым Content-Type. Делайте это только на копии сайта или тестовом стенде с разрешения владельца.

Права пользователей и панель управления

В DLE нужно проверять не только наличие ролей, но и фактические операции, доступные каждой группе. Редактору может быть разрешено публиковать материал, но не менять шаблоны, плагины, пользователей и настройки сайта. Если код нового модуля проверяет только факт входа в админку, а не конкретное право, обычная учётная запись может получить административную операцию.

На ревью задайте практические вопросы:

• может ли автор редактировать чужой материал;
• может ли редактор менять HTML, дополнительные поля и файлы шаблона;
• проверяются ли права повторно в AJAX-обработчике;
• что произойдёт после удаления или блокировки пользователя;
• как отзываются активные сессии после смены пароля.

Общие логины для команды — отдельный красный флаг. Они лишают журнал событий смысла: после инцидента невозможно установить, кто изменил запись или загрузил файл.

Конфигурация, секреты и резервные копии

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

Для ревью важны не только права файла, но и граница публикации:

• резервные копии хранятся вне директории, из которой веб-сервер раздаёт файлы;
• тестовая копия не использует реальные пароли и персональные данные без необходимости;
• режим отладки и подробные ошибки отключены на продакшене;
• логи не содержат пароли, токены и полные значения cookie;
• обновление PHP и DLE проходит сначала на копии с проверкой совместимости.

Защита от подделки межсайтовых запросов, настройки cookie, заголовки безопасности и ограничение доступа к панели должны проверяться на рабочем стенде. Их точная реализация зависит от версии DLE, PHP, веб-сервера и прокси, поэтому универсальная строка конфигурации без этих данных может навредить.

Что ломается первым и как приоритизировать

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

Не используйте для проверки реальные боевые токены и не вставляйте их в отчёт. Для воспроизводимого теста достаточно заглушек вроде YOUR_API_KEY и специально созданной тестовой учётной записи.

Что делать после ревью

Соберите минимальный план исправлений: обновить DLE и расширения, закрыть критические пути ввода и загрузки, пересмотреть роли, вынести резервные копии из публичного каталога и настроить журналирование административных действий. После этого повторите проверку на копии сайта и сравните не только список закрытых замечаний, но и фактические права групп.

В продакшене дальше следите за версиями DLE, PHP и модулей, неожиданными изменениями файлов, входами в админку и появлением новых архивов в web-директориях. Отдельно проверьте процедуру восстановления: резервная копия, которую нельзя быстро развернуть и проверить, не является готовым планом после инцидента.