Кратко и по делу.
1) Как атакующий воспользуется строкой
- Исходный код:
query = "SELECT * FROM users WHERE name = '"+name+"'";
- Примеры полезных полезей:
- Аутентификационный/фильтровый обход: если ввести name = `' OR '1'='1` получится запрос
`SELECT * FROM users WHERE name = '' OR '1'='1'` — условие всегда истинно, вернёт все строки.
- Инъекция UNION для чтения других таблиц: name = `a' UNION SELECT password, email FROM admins -- ` даст комбинированный результат.
- Удаление/выполнение команд (если драйвер разрешает несколько запросов): name = `a'; DROP TABLE users; -- ` приведёт к выполнению DROP.
- Blind SQLi: по одному символу проверять ответы/время и вытягивать данные при отсутствии прямого вывода.
2) Защиты (в порядке важности и практичности)
- Подготовленные выражения (prepared statements / parameterized queries) — обязательны: параметры передаются отдельно от кода запроса, драйвер экранирует значения. Примеры:
- Java JDBC:
PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE name = ?");
ps.setString(1, name);
- PHP PDO:
$stmt = $pdo->prepare("SELECT * FROM users WHERE name = ?");
$stmt->execute([$name]);
Это закрывает классические инъекции.
- Валидация входа (allowlist) — дополнительная защита:
- Разрешать только ожидаемый формат (буквы, цифры, ограниченная длина), например имя пользователя без спецсимволов.
- Проверять длину и тип (не принимать длинные строки/байты).
- Для сложных полей применять специфичную валидацию (email, UUID).
- Привилегии БД (принцип минимальных привилегий):
- У приложения — учётная запись с минимально необходимыми правами (обычно SELECT/INSERT/UPDATE на нужные таблицы).
- Не давать права DROP/ALTER/CREATE если они не нужны.
- Разделять аккаунты: один для чтения, другой для админских операций.
- Отключить возможность выполнения нескольких выражений в одном запросе (если драйвер/коннектор поддерживает опцию, например `allowMultiQueries=false`).
- Дополнительно (комплексная защита):
- ORM/хелперы, которые по умолчанию используют параметры, снижают риск.
- Экранирование (escape) только как запасной вариант — ненадёжно по сравнению с параметрами.
- Ограничение выдачи ошибок клиенту (не показывать текст ошибок SQL).
- WAF/IDS для обнаружения атакующих паттернов.
- Логирование и мониторинг подозрительных запросов.
- Тестирование: автоматические сканеры и ручное тестирование на SQLi.
3) Итоговая рекомендация
- Первично — заменить конкатенацию на подготовленные выражения.
- Затем ввести строгую валидацию входа и минимальные привилегии для БД.
- Дополнительно — отключить многострочные запросы, логировать и ставить WAF.
Если нужно, могу привести точные примеры кода для вашего языка/драйвера.