Пример уязвимого кода (контекст PHP + mysqli):
<?php
// уязвимый пример
$name = $_GET['name'];
$query = "SELECT * FROM users WHERE name='" . $name . "'"; // <-- уязвимо
$result = mysqli_query($conn, $query);
?>
Механизм атаки (кратко)
- Атакующий подставляет в параметр строку с SQL‑синтаксисом, чтобы изменить смысл запроса.
- Например, если в GET передать payload типа: `anything' OR '1'='1`, итоговый SQL станет:
"SELECT * FROM users WHERE name='anything' OR '1'='1'". Здесь выражение $1=1$ всегда истинно, поэтому фильтр обходится и возвращаются все строки.
- Последствия: обход аутентификации, чтение/изменение данных, привилегированное выполнение команд через инъекции в другие запросы.
Обнаружение
- Ревью кода: поиск конкатенации пользовательских данных в SQL (regexp, SAST).
- Логирование и анализ БД/приложения: неожиданно большие выборки, частые синтаксические ошибки SQL в логах, нестандартные символы (кавычки, `--`, `/*`).
- DAST (сканирование веб‑приложения), fuzzing и тесты на SQLi в CI.
- Мониторинг аномалий: резкие всплески количества запросов, необычные запросы к таблицам с чувствительными данными.
- WAF/IDS сигнатуры и поведенческие правила.
Устранение (ремонт уязвимости)
- Немедленно заменить уязвимые места на параметризованные запросы / подготовленные выражения. Пример с PDO:
<?php
$pdo = new PDO($dsn, $user, $pass, $options);
$stmt = $pdo->prepare("SELECT * FROM users WHERE name = :name");
$stmt->execute([':name' => $_GET['name']]);
$rows = $stmt->fetchAll();
?>
- Минимизация прав: аккаунт БД, используемый приложением, должен иметь только нужные привилегии (SELECT/INSERT/UPDATE/DELETE по необходимости), не root.
- Убрать подробные SQL‑ошибки из ответа клиенту; логировать их на сервере.
- Проверить и исправить все остальные места с динамическим SQL (включая ORM/строительство запросов вручную).
- Обновить зависимости, патчи.
Предотвращение (best practices)
- Всегда использовать подготовленные выражения/параметры (PDO, mysqli->prepare, ORM с параметризацией).
- Whitelist валидация входных данных (тип/длина/формат) вместо попыток полноценно экранировать.
- Экранирование входа только как запасной вариант (mysqli_real_escape_string) — не заменяет подготовленные выражения.
- Хранить секреты отдельно, использовать шифрование/хеширование для паролей (bcrypt/argon2).
- Ограничивать привилегии БД и сетевой доступ между сервисами.
- Внедрить автоматизированные SAST/DAST тесты в CI/CD; регулярные ревью кода.
- Включить WAF и правила блокировки для известных паттернов SQLi; настроить алерты.
- Журналировать запросы/ошибки, делать аудит и периодические пентесты.
Краткая дорожная карта внедрения fixes
1. Поиск всех мест с конкатенацией SQL (SAST, grep).
2. Заменить на подготовленные выражения + покрыть тестами.
3. Ограничить права БД и отключить вывод SQL ошибок пользователю.
4. Запустить DAST/пентест и настроить мониторинг/WAF.
5. Внедрить правила безопасности в разработческий процесс (SAST в CI, ревью).
Если нужно, могу привести безопасный пример для mysqli, шаблон политики аудита или чек‑лист для ревью кода.