Краткий вывод: фрагмент уязвим в первую очередь к SQL‑инъекции; косвенно возможны XSS и информационные утечки; CSRF здесь маловероятен, если запрос только читает, но плохая практика — использовать GET для действий, зависящих от аутентификации. Ниже — какие уязвимости, как их эксплуатируют и конкретные меры защиты.
Возможные уязвимости и их эксплуатация
- SQL‑инъекция (SQLi)
- Почему: параметр вставляется в строку запроса без экранирования/параметризации:
$q = "SELECT * FROM users WHERE name='" . $_GET['name'] . "'";
- Эксплуатация: злоумышленник передаёт в name полезную нагрузку, например `' OR '1'='1` чтобы обойти фильтры и получить все записи, или `'; DROP TABLE users; --` при поддержке выполнения нескольких запросов. Также возможны Union‑инъекции, blind/time‑based инъекции и получение данных из других таблиц.
- XSS (рефлекторный/хранимый)
- Почему: если значение из $_GET['name'] позже выводится в HTML без экранирования, злоумышленник может вставить скрипт.
- Эксплуатация: передать `alert(1)` в name и получить исполнение в браузере жертвы.
- Информационные утечки / детализация ошибок
- Почему: при ошибках mysqli_query могут выводиться подробные сообщения, раскрывающие структуру БД.
- Эксплуатация: использовать ошибки для составления полезных payload'ов (fingerprinting схемы).
- CSRF
- Прямая угроза мала для чистого SELECT, но если запрос приводит к сведениям, зависящим от сессии, или используется GET для действий — можно вызвать нежелательные запросы от имени пользователя (в сочетании с XSS/логикой приложения).
- Прочее: логирование незашифрованных параметров, возможные проблемы с правами пользователя БД (если учётная запись имеет избыточные привилегии).
Рекомендации (комплексные меры)
- Параметризованные запросы (prepared statements)
- mysqli:
$stmt = mysqli_prepare($db, "SELECT * FROM users WHERE name = ?");
mysqli_stmt_bind_param($stmt, "s", $_GET['name']);
mysqli_stmt_execute($stmt);
$res = mysqli_stmt_get_result($stmt);
- PDO:
$stmt = $pdo->prepare("SELECT * FROM users WHERE name = ?");
$stmt->execute([$_GET['name']]);
$rows = $stmt->fetchAll();
- Комментарий: параметризация полностью устраняет классические SQLi.
- Валидация и фильтрация входа
- Применяйте allow‑list (регулярные выражения, фиксированные наборы допустимых имён) и ограничение длины. Не пытайтесь полагаться только на экранирование.
- Экранирование при выводе (предотвращение XSS)
- Для HTML: использовать htmlspecialchars($value, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8').
- Для атрибутов, URL, JS — соответствующее контекстное кодирование.
- Принцип наименьших привилегий (DB user)
- Учётная запись БД должна иметь только необходимые права (например, только SELECT на конкретную таблицу/столбцы), не root/ALL PRIVILEGES.
- Обработка ошибок и логирование
- Не показывать детализированные SQL‑ошибки пользователю; логируйте их в защищённый лог.
- Безопасность транспортного уровня
- Всегда использовать HTTPS; включить HSTS.
- Политика CSP
- Content Security Policy уменьшит последствия XSS (ограничит источники скриптов, inline‑скрипты и т.п.).
- CSRF‑защита (если операция изменяет состояние)
- Для POST/изменяющих запросов — токены CSRF, заголовки SameSite для куки, проверка Origin/Referer.
- Дополнительные меры
- Ограничение частоты запросов, WAF/IDS, регулярные pentest/сканирование на SQLi, обновление СУБД и библиотек.
- Выборочное возвращеие колонок (не SELECT *), минимизация объёма данных.
Короткая инструкция внедрения защиты (минимум)
- Заменить конкатенацию на подготовленные выражения;
- Сделать валидацию входа (формат/длина/список);
- Экранировать вывод в HTML;
- Дать БД пользователю с минимальными правами;
- Включить HTTPS и CSP, не выводить сырой текст ошибок.
Эти меры в комплексе защитят от SQLi, значительно снизят риск XSS и утечек, и улучшат общую безопасность приложения.