Что произойдёт
- Подстановка приведёт к формированию строки запроса:
"SELECT * FROM users WHERE name = ''; DROP TABLE users;--'"
Если сервер БД и драйвер позволяют выполнение нескольких SQL-операторов в одном вызове, сначала выполнится `SELECT`, затем `DROP TABLE users` — таблица будет удалена. Если множественные операторы запрещены, скорее всего произойдёт ошибка, но цель инъекции достигнута — выполнение произвольного SQL-кода.
Какие уязвимости проявляются
- SQL‑инъекция — непосредственная, через конкатенацию пользовательских данных в SQL.
- Неправильная обработка входа (отсутствие валидации/экранирования).
- Недостаток принципа наименьших привилегий у учётной записи БД (если учётная запись может удалять таблицы).
- Отсутствие контроля многокомандных запросов и недостаточного журналирования/мониторинга.
Как правильно проектировать слой взаимодействия с БД
- Использовать параметризованные запросы / подготовленные выражения (bind parameters) вместо конкатенации строк.
Примеры (псевдокод):
- PDO (PHP):
$stmt = $pdo->prepare("SELECT * FROM users WHERE name = ?");
$stmt->execute([$name]);
- node-postgres:
client.query("SELECT * FROM users WHERE name = $1", [request.name]);
- Использовать ORM или безопасные query‑builders, которые автоматически параметризуют ввод.
- Отключать возможность выполнения нескольких SQL‑команд в одном запросе (опция драйвера).
- Делать слой доступа к БД узким и централизованным (все запросы проходят через проверяемые функции/репозитории), чтобы легче применять защиту и аудит.
- Разделять права: отдельные учётные записи для чтения и для записи/администрирования.
Дополнительные меры защиты — рекомендации
- Валидация входных данных:
- По возможности применять белые списки допустимых значений (наиболее надёжно).
- Ограничивать длину и формат (регулярные выражения), нормализовать/декодировать вход.
- Валидация — дополнение к параметризации, но не замена ей.
- Подготовленные выражения / bind parameters — основная защита от SQL‑инъекций.
- Правила привилегий:
- Приложение использует учётную запись с минимально необходимыми правами (например, только SELECT/INSERT/UPDATE, без DROP/ALTER).
- Спрятать учётные данные, использовать секрет‑менеджер.
- Журналирование и мониторинг:
- Логирование подозрительных запросов и ошибок (без записи паролей/секретов).
- Настроить алерты на необычные DDL/DML операции, резкие пики удаления/создания объектов.
- Вести аудит доступа и операций БД.
- Ограничение контекста выполнения:
- Таймауты запросов, ограничение объёма возвращаемых данных, rate limiting на интерфейс.
- Инфраструктурные меры:
- Бэкапы и планы восстановления (чтобы избежать потери данных при успешной атаке).
- WAF/IDS для фильтрации известных атак на уровне HTTP (не заменяет параметризацию).
- Регулярное обновление СУБД и библиотек.
- Экранирование спецсимволов только как запасной вариант и строго по контексту (SQL‑экранирование), но не как основной метод.
Краткий вывод
- Главный риск — SQL‑инъекция через конкатенацию. Правильный подход — параметризованные запросы, принцип наименьших привилегий, централизованная валидация и аудит. Эти меры вместе снижают вероятность выполнения вредоносного SQL и уменьшают ущерб при успешной атаке.