Уязвимость
- В коде — классическая SQL-инъекция: пользовательское значение `$_GET['name']` прямо конкатенируется в SQL, поэтому злоумышленник может изменить семантику запроса.
Какие типы атак возможны (кратко, концептуально)
- Чтение посторонних данных (раздутый результат запроса, доступ к другим строкам/таблицам).
- Аутентификация/авторизация: обход проверок за счёт изменения условий WHERE.
- Модификация/удаление данных (если используемые учётные данные БД имеют такие права).
- Инъекции, использующие несколько операторов (если СУБД и соединение позволяют несколько команд).
- Error‑based, boolean/blind и time‑based техники для извлечения данных при отсутствии прямых ошибок.
- Вторичные инъекции (ввод сохраняется и позднее используется в других запросах).
Как эксплуатируется (концепция, без вредоносных примеров)
- Атакующий подставляет в параметр управляющие SQL‑токены (закрытие строкового литерала, логические операции, комментарии и т.п.), что меняет WHERE или добавляет дополнительные операторы; далее использует поведение сервера (ошибки, время ответа, отличия в выдаче) для достижения цели.
Паттерны защиты на уровне кода (рекомендованные)
- Использовать параметризованные запросы / подготовленные выражения (prepared statements) с привязкой параметров. Пример (PDO):
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$stmt = $db->prepare('SELECT * FROM users WHERE name = :name');
$stmt->execute([':name' => $_GET['name']]);
- Валидировать и фильтровать вход: whitelist (разрешённый формат/символы/длина) для полей, где это возможно.
- Не логировать сырые пользовательские данные в журналы без очистки.
- Ограничивать возвращаемые поля (не использовать SELECT *), лимитировать объём выборки.
- Использовать ORM/Query Builder, которые по умолчанию параметризуют запросы.
- Отключать эмуляцию prepared statements в драйверах, чтобы реальные плейсхолдеры передавались СУБД.
- Ограничивать длину и формат входа и применять контекстную обработку при выводе (XSS‑защита отдельно).
Паттерны защиты на уровне БД и инфраструктуры
- Учетная запись приложения имеет минимум прав: только те операции и таблицы, которые нужны (principle of least privilege).
- Отключить возможность выполнения нескольких операторов в одном запросе (если поддерживается конфигурацией драйвера/СУБД).
- Ограничить доступ к метаданным (information_schema) по необходимости.
- Включить строгую кодировку/charset (utf8mb4) и явно её задавать при соединении.
- Использовать роли и отдельные учетные записи для административных операций.
- Мониторинг, алерты и логирование подозрительных запросов; WAF как дополнительный уровень защиты.
- Регулярные пентесты и ревью запросов с высокой привилегией.
Дополнительно
- Prepared statements — основной и приоритетный метод. Экранирование вручную или использование функций вроде `mysqli_real_escape_string` — менее надёжно и служит запасным вариантом только при отсутствии параметризации.
- Комбинация мер (параметры + валидация + минимальные привилегии + мониторинг) даёт устойчивую защиту.
Если нужно, могу показать короткий пример безопасного кода для mysqli или подсказки по настройке прав БД.