Примеры вредоносных входных данных (для случаев, где приложение небезопасно конкатенирует строки в SQL):
- Аутентификация (строковые параметры):
- `username: ' OR '1'='1' -- `
Эффект: условие всегда истинно, обход аутентификации.
- Удаление/модификация данных (если разрешены несколько операторов):
- `id: 1; DROP TABLE users; --`
Эффект: удаление таблицы (наличие зависит от драйвера/БД).
- UNION-эксфильтрация данных:
- `search: ' UNION SELECT username, password FROM users -- `
Эффект: добавление строк из другой таблицы в результат.
- Blind / time-based SQLi:
- `id: 1' OR IF(1=1, SLEEP(5), 0) -- ` (MySQL)
Эффект: задержка ответа — подтверждение уязвимости без явного вывода данных.
- Команды ОС через расширения СУБД (MS SQL):
- `'; EXEC xp_cmdshell('dir') -- `
Эффект: выполнение команд ОС (при наличии прав).
- Числовые параметры, некорректная вставка:
- `page: 0 OR 1=1`
Эффект: изменение логики фильтра/страницы.
Комплекс мер защиты (кратко и по делу):
1. Параметризованные запросы / подготовленные выражения
- Используйте placeholders и привязку параметров (prepared statements). Это предотвращает смешивание кода и данных.
- Пример (псевдокод):
Небезопасно: `sql = "SELECT * FROM users WHERE name = '" + name + "'"`
Безопасно: `SELECT * FROM users WHERE name = ?` + bind(name)
2. ORM или драйверы с поддержкой параметров
- Используйте проверенные ORM/библиотеки, но не забывайте, что raw-запросы всё ещё должны быть параметризованы.
3. Белые списки и строгая валидация входа
- Для идентификаторов/чисел — приведение типов/проверка формата.
- Для перечисляемых значений — только заранее разрешённые значения.
4. Контекстно-правильное экранирование (как запасной метод)
- Если параметризация невозможна, применяйте проверенное API экранирования для конкретной СУБД. Но это менее надёжно, чем параметризация.
5. Ограничение прав БД (принцип наименьших привилегий)
- Учётная запись приложения должна иметь минимум прав (например, без DROP, без xp_cmdshell, без админских привилегий).
6. Отключение множественных команд в одном запросе, если не требуется
- Запретить исполнение нескольких SQL-операторов в одном вызове (depends on API/driver).
7. Обработка ошибок и логирование
- Не возвращайте подробные сообщения об ошибках пользователю; логируйте и мониторьте аномалии.
8. WAF и проверка трафика
- Web Application Firewall как дополнительный слой защиты (подходит для подпорки, но не как основной механизм).
9. Регулярное тестирование и аудит
- SAST/DAST, пентесты, ревью кода, автоматические тесты на SQLi.
10. Ограничение времени и объёма запросов
- Таймауты, ограничение результата (LIMIT), мониторинг долгих запросов (защита от time-based/expensive injections).
11. Избегать динамического SQL в СУБД
- По возможности не строить SQL в строках внутри хранимых процедур; если нужно — использовать параметризованные способы.
Краткое резюме: основная и самая надёжная защита — разделять код и данные через параметризованные запросы (prepared statements) + строгая валидация входа + минимальные привилегии БД. Дополнительно — WAF, логирование и регулярные тесты.