До 70% уязвимостей в самописных или покупных PHP-скриптах связаны с некорректной фильтрацией входных данных и избыточными правами доступа. Запуск скрипта без базового аудита безопасности превращает ваш сервер в открытый шлюз для RCE-атак и SQL-инъекций, где стоимость восстановления данных после взлома начинается от 50 000 рублей и может достигать сотен тысяч при потере клиентской базы.
Изоляция среды и принцип минимальных привилегий
Запуск PHP от имени root — фатальная ошибка. В стандартном стеке LAMP/LEMP процесс должен работать от имени ограниченного пользователя (например, www-data), который не имеет прав на запись в системные директории. Практика показывает: ограничение прав доступа к папкам до 755 для директорий и 644 для файлов снижает риск модификации кода злоумышленником на 90%.
Кейс: при установке скрипта для парсинга данных многие ставят chmod 777 на папку /uploads. В итоге через загрузку файла с расширением .php злоумышленник получает shell-доступ к системе. Правильный подход — запрет исполнения PHP-файлов в папках для загрузки через .htaccess (php_flag engine off) или конфиг Nginx.
Экспертный вывод: никогда не используйте общие аккаунты хостинга для разных проектов. Один скомпрометированный скрипт на дешевом Shared-хостинге за 200 руб/мес может скомпрометировать все ваши сайты через симлинки.
Фильтрация ввода и защита от инъекций
Использование функций mysql_query (устарело) или даже прямой конкатенации переменных в SQL-запросах — прямой путь к потере БД. Современный стандарт — Prepared Statements через PDO или MySQLi. Это исключает возможность SQL-инъекции, так как данные передаются отдельно от тела запроса. По статистике, переход на подготовленные выражения закрывает до 95% дыр в уровне доступа к данным.
Ошибкой является вера в функцию addslashes() или strip_tags(). Для валидации типов данных используйте filter_var() с флагами FILTER_VALIDATE_EMAIL или FILTER_SANITIZE_NUMBER_INT. Например, проверка входящего ID пользователя на целое число занимает 1 строку кода, но предотвращает обход авторизации через манипуляцию параметрами URL.
Экспертный вывод: любой входящий параметр (GET, POST, COOKIE) должен считаться враждебным. Если вы решили заказать скрипты на PHP у фрилансеров, первым делом проверяйте наличие PDO в коде — если его нет, переписывайте слой работы с БД.
Конфигурация php.ini для защиты сервера
Безопасность начинается с настроек интерпретатора. Отключение функции exec(), shell_exec(), system() и passthru() через директиву disable_functions в php.ini блокирует возможность удаленного выполнения системных команд. В среднем, 60% эксплойтов для PHP-скриптов опираются именно на эти функции для закрепления в системе.
Также критически важно выключить display_errors в продакшене (set to Off). Вывод ошибок в браузер раскрывает структуру путей на сервере, версии PHP и названия таблиц БД, что сокращает время подготовки атаки для хакера с нескольких часов до нескольких минут. Логирование должно идти строго в файл, доступ к которому закрыт извне.
Экспертный вывод: стандартный конфиг хостинга настроен на удобство разработки, а не на безопасность. Ручная правка php.ini — обязательный этап перед деплоем любого коммерческого решения.
Управление сессиями и защита от XSS
Классическая атака Cross-Site Scripting (XSS) позволяет красть сессионные куки пользователей. Для защиты необходимо использовать функцию htmlspecialchars() при выводе любых данных, введенных пользователем. Внедрение Content Security Policy (CSP) заголовков позволяет ограничить источники загрузки скриптов, что снижает вероятность успешного XSS-выполнения на 80%.
Мини-кейс: использование сессий без флага HttpOnly позволяет JS-скрипту считать ID сессии. Установка session.cookie_httponly = 1 в настройках PHP полностью блокирует доступ к кукам через JavaScript, что делает кражу сессии практически невозможной даже при наличии XSS-уязвимости на странице.
Экспертный вывод: защита данных на выходе так же важна, как и фильтрация на входе. Игнорирование экранирования вывода делает ваш сайт уязвимым для фишинга внутри собственного интерфейса.
Адаптация и обновление зависимостей
Использование устаревших версий PHP (например, 5.6 или 7.2) увеличивает риск атаки в разы, так как известные CVE для этих версий не закрываются. Переход на PHP 8.2+ не только дает прирост производительности в 2-3 раза, но и предоставляет встроенные механизмы защиты. Работа с внешними библиотеками должна идти строго через Composer.
Проблема многих готовых решений — заброшенные зависимости. Регулярный запуск команды composer audit позволяет выявить уязвимые пакеты за секунды. Если в вашем проекте используется библиотека с критической уязвимостью, время на её обновление обычно составляет от 15 минут до 2 часов, но это экономит недели разбора последствий взлома.
Экспертный вывод: безопасность — это процесс, а не разовое действие. Настройка и адаптация готовых PHP-решений требует регулярного мониторинга версий всех используемых компонентов.
Вывод
Безопасный запуск PHP-скриптов базируется на трех столпах: изоляция прав доступа (chmod 644/755), жесткая фильтрация ввода (PDO + filter_var) и отключение опасных функций в php.ini. Начинать нужно с запрета исполнения PHP в папках загрузки и отключения вывода ошибок в браузер. Избегайте Shared-хостингов для серьезных проектов и никогда не используйте функции exec() без крайней необходимости. Мой вердикт: лучше потратить 4 часа на базовый аудит и настройку среды, чем потерять бизнес из-за одной забытой функции strip_tags().