Уязвимость: SQL-инъекция — сборка SQL через конкатенацию строк с пользовательским вводом (`name`) позволяет атакующему подставлять произвольные фрагменты SQL и менять логику запроса.
Примеры атак (с пояснениями):
- Аутентификация/обход фильтров: при `name = "' OR '1'='1"` запрос станет
SELECT * FROM users WHERE name = '' OR '1'='1'
(тут логическая таутология `'1'='1'` позволяет вернуть все строки).
- Получение/изменение данных: `name = "'; UPDATE users SET role='admin' WHERE id=1; --"` (если СУБД и драйвер разрешают несколько команд) — удаление/изменение данных.
- Экфильтрация через побочные каналы: `name = "' OR (SELECT CASE WHEN (SUBSTRING(password,1,1)='a') THEN sleep(5) ELSE 0 END)=0 --"` — тайминг-атака (time-based blind).
- Разрушение БД: `name = "'; DROP TABLE users; --"` — удаление таблиц.
Безопасные способы взаимодействия с БД (Java):
- Параметризованные запросы (PreparedStatement):
PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE name = ?");
ps.setString(1, name);
ResultSet rs = ps.executeQuery();
Параметры передаются отдельно, драйвер корректно экранирует/биндит значения — исключает SQL-инъекции.
- ORM/Query builders (Hibernate, jooq и т.д.) с параметризацией — не вставлять сырые строки в запросы.
- Хранимые процедуры с параметрами — НО: если внутри PROC строятся строки динамически с конкатенацией, уязвимость останется.
- Для динамических идентификаторов (имена таблиц/столбцов) — применять строгую белую очередь (whitelist) и не подставлять напрямую пользовательский ввод.
Дополнительные меры в коде и конфигурации:
- Валидация и нормализация входа: проверять длину, разрешённый набор символов (whitelist), но не полагаться на это как на единственную защиту.
- Ограничение максимальной длины параметров, например $\le 255$ символов.
- Не разрешать выполнение нескольких команд в одном запросе (если возможно, отключить в драйвере/СУБД).
- Использовать привилегии минимально необходимых для аккаунта БД (principle of least privilege).
- Использовать подготовленные выражения/пул соединений по умолчанию.
Меры на уровне системы и политики:
- Сетевые ограничения: изолировать БД в приватной сети, доступ только с приложений.
- WAF и Database Firewall: блокировка известных паттернов SQLi, защита на уровне сети/приложения.
- Логирование и мониторинг: аудит SQL-запросов и аномалий, оповещения при подозрительной активности и резком росте времени отклика (timing attacks).
- Регулярное тестирование: SAST/DAST/IAST, пентесты, автоматические сканеры на SQLi.
- Процессы и обучение: код-ревью критичных мест, обязательное использование параметризации, обучение разработчиков безопасности.
- Управление секретами: ротация учётных данных, хранение в vault, шифрование каналов (TLS).
- Политика доступа: разграничение прав (отдельные пользователи для чтения/записи/админов), ограничение привилегий на уровне таблиц/схем.
Краткий итог: не конкатенировать пользовательский ввод в SQL; использовать PreparedStatement/ORM с параметрами, ограничивать привилегии и внедрять многослойную защиту (валидация, WAF, логирование, тестирование и процессы).