Опасное включение файлов в PHP

PHP 4/5 эпохи — тысячи проектов с index.php?page=. Практика «фронт-контроллера» пришла позже, вместе с фреймворками (Symfony, Laravel), где маршрут определяет класс, а не строку пути.

До сих пор такие схемы встречаются в легаси-панелях, самописных «сайтах-визитках» и старых учебных CMS. На shared-хостинге это ещё и риск для соседних сайтов: одна дыра — и пишут во все доступные директории.

Опасный паттерн: include($_GET['page'] . '.php');. Злоумышленник подставляет page=php://filter/convert.base64-encode/resource=../config — и читает исходники с паролями. Или page=../../uploads/shell — и исполняет свой файл, если удалось его загрузить.

Классическая цепочка: чтение исходников → пароли БД → запись шелла через загрузчик → полный контроль хостинга. Именно так массово «падали» сайты на awstats, phpMyAdmin и подобных утилитах в 2000-х; паттерн живёт и сейчас в самописных системах.

На shared-хостинге один такой сайт-закладка часто тянет за соседей: злоумышленник получает права веб-пользователя и дальше ищет доступные для записи директории у других клиентов. Владелец «своего» сайта замечает проблему, когда хостинг блокирует аккаунт за спам или когда в поиске появляются чужие страницы.

До сих пор регулярно всплывают находки вида «панель управления с include по параметру» в корпоративном легаси. Система работает годами, её никто не трогает, пока аудит или сканер не покажет точку входа.

• Автозагрузка PSR-4, маршрутизация, шаблоны без include по вводу пользователя
• Если динамика нужна — строгий allow-list имен модулей: $pages = ['home' => ..., 'about' => ...]
• Код вне document_root, отдельные права, отсутствие write-доступа к исполняемым директориям
• Логи ошибок без вывода полных путей наружу; display_errors=Off на проде
• Регулярный аудит легаси-точек — именно они остаются в проде годами