Покупка готового PHP-скрипта за $30–$150 с маркетплейсов вроде CodeCanyon или поиск «бесплатных» версий (nulled) в 40% случаев приводит к установке бэкдоров, которые активируются спустя 2-4 недели после запуска. Стоимость ликвидации последствий одного успешного взлома через уязвимость в стороннем коде начинается от $500 и может достигать тысяч долларов при потере базы клиентов.
Поиск обфусцированного кода и скрытых функций
Первым делом ищем функции eval(), base64_decode(), gzinflate() и str_rot13(). В качественном коммерческом продукте обфускация встречается редко; её наличие в 90% случаев означает попытку скрыть вредоносный код, который скачивает шелл или создает администратора в БД. Если вы видите строку длиной в 2000 символов из случайных знаков, передаваемую в eval — скрипт идет в корзину.
Кейс: в популярном скрипте для автоматизации рассылок был найден скрытый блок в файле конфигурации, который раз в 7 дней отправлял копию всех API-ключей владельца на удаленный сервер в Восточной Европе. Это классический «спящий» бэкдор.
Вывод эксперта: Любой обфусцированный код в open-source или недорогом коммерческом решении — это стопроцентный риск. Требуйте чистый код или отказывайтесь от покупки.
Анализ фильтрации входных данных и SQL-инъекций
Проверка на использование mysqli_real_escape_string() или, что гораздо важнее, подготовленных выражений (Prepared Statements) через PDO. Если в коде встречаются конструкции вида "WHERE id = " . $_GET['id'] — перед вами дыра, через которую за 5 минут выгрузят всю вашу базу данных. В 2023-2024 годах использование процедурного стиля без параметризации в новых скриптах считается грубейшей ошибкой.
Сравнение: скрипт на чистом PHP (процедурный стиль) требует ручной проверки каждой переменной, тогда как современные MVC-фреймворки (Laravel, Symfony) фильтруют данные на уровне ядра, снижая риск SQLi на 80-90%.
Вывод эксперта: Если проект написан на процедурном PHP без использования PDO/Prepared Statements, стоимость его доработки по безопасности составит от 20% до 50% от цены самого скрипта.
Проверка XSS-уязвимостей в выводе данных
Ищите отсутствие функции htmlspecialchars() или strip_tags() при выводе пользовательского контента в HTML. Межсайтовый скриптинг (XSS) позволяет злоумышленнику украсть сессионные куки администратора, что дает полный доступ к панели управления без знания пароля. В дешевых скриптах за $20-50 эта проверка часто игнорируется в пользу скорости разработки.
Пример: форма обратной связи, которая выводит имя отправителя в админ-панели без фильтрации. Хакер присылает в поле «Имя» скрипт <script>alert(document.cookie)</script>, и при открытии письма администратором данные сессии улетают злоумышленнику.
Вывод эксперта: Отсутствие базовой фильтрации вывода говорит о низкой квалификации автора. Такой код нельзя ставить на production без полного ревью всех шаблонов.
Аудит прав доступа и IDOR-уязвимостей
Проверьте, как скрипт обрабатывает запросы к объектам. Если доступ к заказу или профилю осуществляется по прямой ссылке edit_user.php?id=123 без проверки, принадлежит ли этот ID текущему авторизованному пользователю — это IDOR (Insecure Direct Object Reference). Это позволяет перебирать ID в URL и редактировать чужие данные.
Кейс: в одном из CRM-скриптов за $60 была возможность скачать любой инвойс, просто меняя цифру в URL. В итоге за неделю утекли данные 1200 клиентов. Исправление этой ошибки заняло 15 минут правки кода, но репутационный ущерб был огромным.
Вывод эксперта: Безопасность должна быть на уровне сервера (Backend), а не скрыта за отсутствием ссылок в интерфейсе. Проверяйте права доступа в каждом контроллере.
Проверка зависимостей и устаревших библиотек
Изучите файл composer.json. Использование библиотек с версиями, вышедшими 3-5 лет назад, означает наличие известных CVE (Common Vulnerabilities and Exposures). Обновление старой версии PHP-библиотеки может сломать совместимость, что потребует переписывания 10-15% функционала, но это дешевле, чем восстанавливать сервер после атаки.
Статистика: около 60% уязвимостей в PHP-приложениях связаны с использованием устаревших сторонних компонентов, которые давно имеют патчи, но не были обновлены разработчиком скрипта.
Вывод эксперта: Скрипт, который не обновлял зависимости более года, считается техническим долгом. Перед импортом обязательно используйте composer audit для поиска известных дыр.
Контроль загрузки файлов и RCE-атак
Самая опасная точка — загрузка файлов. Если скрипт проверяет расширение файла только по строке (например, if($ext == 'jpg')) или вообще не проверяет MIME-тип, злоумышленник может загрузить shell.php под видом картинки. Это ведет к Remote Code Execution (RCE) — полному захвату сервера.
Правильная реализация: переименование файла при загрузке, хранение вне публичного доступа (вне public_html) и проверка через finfo_file(). В 70% бюджетных решений реализован только поверхностный фильтр расширений.
Вывод эксперта: Любой модуль загрузки файлов в стороннем скрипте должен быть переписан или подвергнут жесточайшему стресс-тесту перед запуском.
Вывод
Мой вердикт: никогда не импортируйте готовый PHP-скрипт напрямую на рабочий сервер. Оптимальный путь — развертывание в изолированном Docker-контейнере, прогон через статический анализатор (например, Psalm или PHPStan) и ручная проверка по вышеуказанным 7 точкам. Избегайте «бесплатных» версий платных плагинов — риск получить бэкдор там составляет почти 100%. Если бюджет ограничен, выбирайте решения на базе современных MVC-фреймворков, так как они закрывают базовые дыры (SQLi, XSS) на уровне архитектуры, что в разы надежнее, чем надеяться на внимательность автора процедурного кода.
