Уязвимость (что происходит)
- Запрос строится конкатенацией строки и несанкционированного ввода:
`SELECT * FROM users WHERE name = ' + userInput + ';`
Если `userInput` содержит SQL-код, он попадёт в итоговый запрос и выполнится от имени приложения.
- Примеры атак:
- Обход фильтра/аутентификации: если `userInput = '\' OR \'1\'=\'1'` — итог:
`SELECT * FROM users WHERE name = '' OR '1'='1';` — условие всегда истинно.
- Уничтожение данных: если `userInput = '\'; DROP TABLE users; --'` — итог:
`SELECT * FROM users WHERE name = ''; DROP TABLE users; --';`
Последствия: утечка/модификация данных, разрушение схемы, получение привилегий, удалённое выполнение команд.
Защита на уровне кода (основной приоритет)
1. Параметризованные запросы / подготовленные выражения (prepared statements). Всегда передавать данные как параметры, а не встраивать в SQL. Пример (псевдокод):
- Node.js (pg):
`client.query('SELECT * FROM users WHERE name = $1', [userInput]);`
- PHP (PDO):
`$stmt = $pdo->prepare('SELECT * FROM users WHERE name = ?'); $stmt->execute([$userInput]);`
2. ORM с правильно используемыми параметрами (не конкатенировать сырые строки).
3. Валидация и фильтрация входных данных: типы, длина, допустимый набор символов (whitelisting), регулярные выражения — не как единственная мера, но как дополнительная.
4. Экранирование (escaping) входа только если параметризация невозможна; использовать штатные функции драйвера (но это менее надёжно).
5. Ограничение функциональности интерфейсов: использовать строгие типы, числовые параметры преобразовывать в числа до вставки и т. п.
6. Логирование/мониторинг подозрительных запросов и неуспешных попыток.
Защита на уровне БД и инфраструктуры
1. Наименьшие привилегии: учётная запись приложения должна иметь только нужные права (SELECT/INSERT/UPDATE/DELETE по нужным таблицам), без прав на DDL (DROP, ALTER) и администрирование.
2. Разделение прав/ролей: чувствительные операции выполнять под отдельными ролями или через хранимые процедуры с контролируемыми правами.
3. Хранимые процедуры + параметры: если используются правильно, уменьшают риск, но не заменяют параметризацию в коде.
4. Ограничения в схеме: типы столбцов, CHECK-ограничения, длины полей — снижают влияние некорректных данных.
5. Включить аудит и логирование запросов, алерты на подозрительную активность.
6. WAF / IPS: веб-фаервол может блокировать известные шаблоны инъекций (в качестве дополнительной меры).
7. Сегментация сети и шифрование каналов: чтобы при компрометации приложения злоумышленник не получил лёгкого доступа к БД.
8. Регулярные обновления БД/драйверов и тестирование (пентест, сканеры на SQL-инъекции).
Кратко: первичная защита — никогда не конкатенировать пользовательский ввод в SQL; использовать подготовленные запросы/параметры. На уровне БД — давать минимальные привилегии, контролировать операции и логировать.