По статистике инцидентов в нише микро-сервисов, до 40% взломов свежеустановленных PHP-скриптов происходят в первые 72 часа из-за дефолтных прав доступа 777 и открытых функций исполнения. Безопасный запуск — это не установка дорогого файервола, а жесткое ограничение привилегий процесса PHP, которое отсекает 90% автоматизированных ботов-сканеров.
Права доступа: смерть правилу 777
Самая фатальная ошибка новичка — установка прав 777 на папки /uploads или /cache. В реальных условиях это превращает ваш сервер в открытый репозиторий для шеллов. Правильный стандарт: папки — 755, файлы — 644. Для директорий, куда скрипт должен писать данные, используйте владельца-пользователя (www-data) с правами 755 или 775, но никогда не давайте запись всему миру.
Кейс: при аудите скрипта-автопостера было обнаружено, что из-за прав 777 на папку с логами злоумышленник загрузил .php файл через форму обратной связи и получил полный контроль над БД за 15 минут. Итог: переустановка сервера и потеря данных за неделю.
Экспертный вывод: если скрипт требует 777 для работы — это признак архитектурного мусора. Ищите способ сменить владельца папки через chown, а не расширять права через chmod.
Отключение опасных функций в php.ini
Многие готовые решения используют системные вызовы для работы с архивами или почтой, но оставляют «дыру» для удаленного выполнения кода (RCE). Необходимо жестко прописать директиву disable_functions. В список обязательного бана: exec, passthru, shell_exec, system, proc_open, popen. Эти функции используются в 95% эксплойтов для захвата root-прав.
Пример: стандартный скрипт бэкапа может использовать system() для вызова mysqldump. Вместо этого используйте встроенные PHP-классы или специализированные API. Разница в безопасности колоссальна: запрет shell_exec полностью блокирует возможность запуска произвольных bash-команд через уязвимые поля ввода.
Экспертный вывод: безопасность сервера начинается с php.ini. Любой скрипт, который отказывается работать без exec, должен быть отправлен в корзину или переписан.
Изоляция через open_basedir и PHP-FPM
По умолчанию PHP-процесс видит всю файловую систему сервера. Если вы запускаете несколько проектов на одном VPS, одна уязвимость в дешевом скрипте откроет доступ к конфигам всех остальных сайтов. Директива open_basedir ограничивает доступ PHP только конкретной папкой проекта (например, /var/www/site1). Это снижает риск горизонтального перемещения хакера по серверу на 80%.
Сравнение: запуск всех сайтов от одного пользователя root (риск 100% потери сервера) против использования PHP-FPM с раздельными пулами пользователей (риск ограничен одним сайтом). Стоимость настройки PHP-FPM — 0 рублей, затраты времени — 20 минут, профит — сохранность всего сервера при взломе одного скрипта.
Экспертный вывод: использование одного пользователя для всех сайтов — преступление. Только раздельные пулы PHP-FPM и жесткий open_basedir.
Защита конфигов и .env файлов
Файлы с паролями к БД часто остаются доступными по прямой ссылке (например, config.php или .env). Если сервер неправильно настроен, запрос к .env вернет все секреты в текстовом виде. Решение: вынос конфига на уровень выше корневой директории сайта (public_html). Тогда файл физически недоступен через HTTP, даже если сервер «глюкнет».
Мини-кейс: в 2023 году тысячи сайтов на базе популярных фреймворков слили ключи API и пароли БД просто потому, что .env лежал в корне, а Nginx не имел правила запрета доступа к скрытым файлам. Потеря прибыли от остановки таких сервисов исчисляется тысячами долларов за час простоя.
Экспертный вывод: никогда не храните пароли в корне сайта. Либо вынос файла за пределы public_html, либо жесткий запрет в .htaccess/nginx.conf.
Валидация ввода и фильтрация запросов
При использовании готовых скриптов на PHP для новичков часто упускается проверка входящих данных. SQL-инъекции и XSS остаются лидерами в топе OWASP. Обязательно проверьте, использует ли код Prepared Statements (PDO или MySQLi). Если в коде встречаются конструкции вида "WHERE id = " . $_GET['id'], этот скрипт небезопасен и требует немедленной правки.
Статистика показывает, что использование подготовленных запросов снижает вероятность успешной SQL-инъекции до нуля. В то время как простая фильтрация через addslashes или strip_tags обходится опытным пентестером за несколько секунд с помощью кодировок.
Экспертный вывод: любой код с конкатенацией переменных в SQL-запросах — это бомба замедленного действия. Только PDO и только типизация данных.
Контроль версий и обновление зависимостей
Старые версии PHP (5.6, 7.0, 7.2) давно не получают патчей безопасности. Запуск современного решения на PHP 7.4 вместо 8.2 увеличивает поверхность атаки в разы из-за известных CVE. Также критично следить за Composer-пакетами. Около 30% уязвимостей в PHP-проектах приходят не из основного кода, а из устаревших сторонних библиотек.
Практика: запуск команды composer audit позволяет за 5 секунд выявить критические дыры в зависимостях. Игнорирование обновлений библиотек в течение 6 месяцев обычно приводит к появлению в системе бэкдоров, которые обнаруживаются только при полной остановке трафика.
Экспертный вывод: PHP 8.1+ — это минимум. Регулярный аудит зависимостей через Composer — обязательная гигиена, а не опция.
Вывод
Безопасность PHP-скрипта на 80% зависит от конфигурации окружения и на 20% от качества кода. Чтобы не быть взломанным в первый день: начните с запрета функций exec/system в php.ini, установите права 644/755 и разнесите сайты по разным пулам PHP-FPM. Избегайте любых решений, требующих прав 777, и никогда не запускайте скрипты на версиях PHP ниже 8.1. Это технический минимум, который превращает ваш сервер из «решета» в защищенную крепость.
Контекст и детали — в основном материале Готовые скрипты и решения на PHP.