Уязвимости PHP — это слабости в среде выполнения PHP, коде приложения, сторонних пакетах или конфигурации сервера, которые могут подвергнуть веб-сайт несанкционированному доступу, краже данных или сбоям. Распространенные примеры включают SQL-инъекции, межсайтовый скриптинг, небезопасную загрузку файлов и нарушенные элементы управления доступом.
Различие имеет значение, поскольку исправления различны. Недостаток безопасности среды выполнения требует исправленной сборки PHP. Ошибка авторизации требует изменения кода или политики. Обновление PHP необходимо, но оно не устранит автоматически каждую слабость веб-сайта, созданного с его использованием.
Для криптосервисов ставки могут включать элементы управления выводом средств, учетные данные API и детали транзакций, отображаемые пользователям кошелька. Компрометация веб-сайта не означает, что правила консенсуса Bitcoin или криптография блокчейна были нарушены.
Начните с поддерживаемого, исправленного программного обеспечения
Обновление безопасности, 22 октября 2026 г.: В бюллетене PHP от 21 октября были указаны две критические уязвимости удаленного выполнения кода, CVE-2026-109618 и CVE-2026-109619. Исправленные выпуски для поддерживаемых веток: PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Команда PHP настоятельно рекомендовала пользователям обновиться; временные меры не являются полной заменой исправлений. Проверьте официальное уведомление о безопасности и рекомендации вашего хостинг-провайдера.
Используйте применимый исправленный выпуск или более позднюю стабильную версию с исправлениями. Поставщики дистрибутивов могут переносить исправления безопасности, поэтому проверяйте статус уведомлений пакета, а не только его строковый номер версии. Убедитесь, что среда выполнения, обслуживающая веб-запросы, а не только PHP командной строки, была обновлена и соответствующие рабочие процессы перезапущены.
Также поддерживайте план обновлений. Поддержка PHP 8.2 по безопасности закончится 31 декабря 2026 года; получение этого конкретного исправления не продлевает его обычный жизненный цикл поддержки.
SQL-инъекции: Держите данные вне структуры запроса
SQL-инъекция происходит, когда непроверенный ввод становится частью команды базы данных. Основное исправление — привязывать значения данных через подготовленные выражения, а не объединять пользовательский ввод в строки SQL. Документация PDO по PHP объясняет это разделение.
Например, поиск частной статьи может привязать как проверенный идентификатор статьи, так и серверную идентификацию аутентифицированного пользователя:
$stmt = $pdo->prepare(
'SELECT id, title FROM articles
WHERE id = :id AND owner_id = :owner'
);
$stmt->execute([
'id' => $articleId,
'owner' => $authenticatedUserId,
]);Заполнители защищают значения данных, а не произвольные имена таблиц, имена столбцов или направления сортировки. Сопоставляйте эти выборы с фиксированными, разрешенными значениями. Также ограничивайте привилегии базы данных: приложению редко нужен учетная запись, которая может администрировать всю базу данных.
Межсайтовый скриптинг: Кодируйте для контекста вывода
Межсайтовый скриптинг, или XSS, возникает, когда непроверенный контент интерпретируется как исполняемый браузерный контент. Комментарий, поле профиля или импортированный документ могут стать опасными, когда страница отображает их некорректно.
Используйте автоматическое экранирование вашего фреймворка и держите непроверенные данные вне исполняемых контекстов. Для простого текста, помещенного между обычными HTML-тегами, подходящим инструментом является htmlspecialchars() PHP с явной обработкой UTF-8. Это не универсальное решение для JavaScript, CSS или URL.
Если пользователям необходимо отправлять богатый HTML, используйте поддерживаемый санитайзер HTML на основе белого списка, а не считайте весь ввод доверенным. Политика безопасности контента (Content Security Policy) добавляет еще один уровень; она не заменяет правильную обработку контента. Эти различия освещены в руководстве OWASP по предотвращению XSS.
Загрузка и обработка файлов: Контролируйте, что принимает сервер
Функция загрузки не должна позволять пользователю решать, какой исполняемый файл появится на сервере. Разрешайте только те типы файлов, которые необходимы продукту, проверяйте контент, а не полагайтесь на заявленный браузером MIME-тип, устанавливайте ограничения по размеру и генерируйте имена файлов на стороне сервера.
Храните непроверенные загрузки вне корневой директории веб-сервера или в отдельном хранилище с контролируемым доступом. Убедитесь, что конфигурация сервера не может выполнять загруженный контент. Аутентификация, авторизация и соответствующая проверка на вредоносное ПО или контент обеспечивают дополнительную защиту. Руководство OWASP по загрузке файлов рекомендует комбинировать эти средства контроля.
Применяйте ту же дисциплину к путям к файлам и импорту. Сопоставляйте идентификаторы документов, видимые пользователю, с утвержденными серверными файлами вместо передачи необработанных значений запроса в функции включения файлов. Избегайте передачи непроверенного ввода в команды оболочки, или десериализацию объектов PHP. Более безопасные API и проверенные форматы данных уменьшают потребность в этих опасных операциях.
Аутентификация, сессии и CSRF требуют отдельных средств контроля
Аутентификация устанавливает, кто такой пользователь; авторизация решает, что этот пользователь может делать. Рабочая страница входа не доказывает, что записи учетных записей, загрузки или административные действия защищены. Проверяйте разрешения на сервере для каждой конфиденциальной операции и объекта.
Используйте установленные функции обработки паролей, такие как password_hash() и password_verify(), защищайте привилегированные учетные записи с помощью MFA и ограничивайте попытки злонамеренного входа. Для сессий используйте HTTPS, настраивайте соответствующие атрибуты cookie Secure, HttpOnly и SameSite, обновляйте идентификаторы сессий после аутентификации или изменения привилегий и аннулируйте сессии при выходе. Следуйте руководству OWASP по управлению сессиями, а не изобретайте собственную схему управления сессиями.
Запросы, изменяющие состояние и аутентифицированные с помощью cookie, также требуют защиты от CSRF. Предпочитайте поддерживаемую реализацию вашего фреймворка, включая серверную проверку токенов, где это применимо. Cookie SameSite являются полезной дополнительной защитой, но не следует полагаться на них для защиты каждого развертывания или потока запросов. Не используйте GET-запросы для выполнения конфиденциальных изменений состояния.
Конфигурация и зависимости являются частью приложения
Хорошо написанный контроллер может находиться в небезопасной среде развертывания. Держите учетные данные, закрытые ключи, секреты конфигурации и резервные копии вне общедоступных каталогов. Отключите подробное отображение ошибок в производственной среде, сохраняя при этом журналы с контролируемым доступом, которые помогают расследовать сбои, не собирая лишних секретов.
Просмотрите полный список зависимостей: среда выполнения PHP, расширения, фреймворк, CMS, плагины и пакеты Composer. Команда Composer audit может выявлять сообщенные проблемы безопасности в зависимостях, но она не может гарантировать безопасность пользовательской логики приложения.
Тестируйте обновления на приложении и развертывайте воспроизводимо из проверенных версий зависимостей. Удаляйте неиспользуемые компоненты, а не оставляйте их открытыми неопределенно долго. Ограничивайте разрешения файловой системы, чтобы процесс приложения не мог перезаписать все на сервере, и отделяйте инструменты разработки от производственной среды.
Как уязвимости PHP могут повлиять на криптографические веб-сайты
На уровень приложения криптографического веб-сайта можно атаковать отдельно от блокчейна, к которому он подключен. Ниже приведены сценарии архитектурных рисков, а не выводы о какой-либо конкретной бирже или кошельке.
| Крипториск | Что может пойти не так | Практический контроль |
|---|---|---|
| Злоупотребление кастодиальным счетом или выводом средств | Перехваченные сессии или слабая серверная авторизация | Повторно аутентифицируйте конфиденциальные действия и привязывайте одобрение к точному получателю и сумме. |
| Обман при депозитных адресах или подписи | Измененное содержимое веб-страницы или вводящие в заблуждение описания транзакций | Проверяйте сеть, получателя, актив и сумму в доверенном интерфейсе кошелька или на читаемом дисплее аппаратного кошелька. |
| Утечка учетных данных API | Секреты, утекшие через код, журналы или общедоступные файлы | Храните ключи на стороне сервера, узко ограничивайте разрешения, исключайте права на вывод средств, когда это не требуется, и ротируйте раскрытые учетные данные. |
Защита закрытого ключа не защищает автоматически решение о его использовании. Руководство Trezor по чистому подписанию объясняет, почему скомпрометированный фронтенд может некорректно описывать транзакцию. Не одобряйте запросы, которые вы не можете осмысленно проверить, или не вводите seed-фразу на веб-сайт, утверждающий, что ему требуется обновление безопасности.
Примените соответствующее исправление или изменение кода, затем протестируйте как средство контроля безопасности, так и нормальное поведение пользователя. Включите негативные тесты: пользователь не должен получать доступ к чужой записи просто путем изменения идентификатора. Запускайте тесты безопасности только против систем, которыми вы владеете или которые вам явно разрешено оценивать.
Если подозревается компрометация, установка исправлений — лишь часть восстановления. Изолируйте инцидент, сохраните полезные доказательства, расследуйте наличие постоянного доступа и раскрытых учетных данных, а также восстановите из проверенного чистого состояния. Правило межсетевого экрана или результат чистого сканирования не подтверждают, что доступ злоумышленника устранен.
Часто задаваемые вопросы
Является ли PHP по своей сути небезопасным?
Нет. Риск зависит от версии среды выполнения, дизайна приложения, зависимостей и развертывания. Приложения PHP по-прежнему требуют регулярного обслуживания безопасности.
Исправит ли обновление PHP SQL-инъекции и XSS?
Не обязательно. Обновления среды выполнения исправляют уязвимости среды выполнения; небезопасное построение запросов и обработка вывода обычно требуют изменений в приложении.
Предотвращает ли HTTPS уязвимости PHP?
Нет. HTTPS защищает данные при передаче. Он не исправляет нарушенные разрешения, небезопасные загрузки или уязвимый серверный код.
Может ли межсетевой экран веб-приложений заменить установку исправлений?
Нет. Он может снизить некоторую подверженность риску, но не может надежно исправить основной дефект программного обеспечения или логику приложения.
Заключение
Уязвимости PHP не имеют единого универсального исправления. Устанавливайте исправления для среды выполнения и зависимостей, отделяйте значения базы данных от SQL, безопасно обрабатывайте вывод браузера, ограничивайте загрузку файлов и применяйте серверные элементы управления доступом.
Для криптографических приложений также защищайте авторизацию вывода средств, учетные данные API и детали транзакций, отображаемые в кошельке. Сопоставьте каждую слабость с правильным средством контроля и проверьте этот контроль после развертывания. Обновления, безопасное кодирование и операционный мониторинг работают вместе; ни одно из них не заменяет другие.
