Коротко: предложенный код
String q = "SELECT * FROM users WHERE name = '"+name+"'";
опасен — он уязвим к SQL-инъекциям и другим рискам. Далее — почему и как исправить.
Почему это опасно
$1$ SQL-инъекция: если пользователь задаст, например, имя ${}^{\prime }O{R}^{\prime }{a}^{\prime }{=}^{\prime }{a}^{\prime }--$, итоговый SQL станет
SELECT * FROM users WHERE name = '' OR 'a'='a' --'
и вернёт все строки или позволит выполнить произвольный SQL (например удаление таблиц).
$2$ Утечка данных: злоумышленник может получить данные, к которым у приложения не должно быть доступа.
$3$ Уровень привилегий: если соединение выполняет опасные операции (DELETE, DROP), последствия критичны.
$4$ Логика приложения: даже без злонамеренных намерений некорректный ввод может сломать запросы.
Надёжные подходы (рекомендуется использовать комбинацию)
$1$ Подготовленные выражения / параметризованные запросы (PreparedStatement, parameter binding) — основной и простой способ:
- Java (JDBC):
String q = "SELECT * FROM users WHERE name = ?";
PreparedStatement ps = conn.prepareStatement(q);
ps.setString($1$, name);
ResultSet rs = ps.executeQuery();
- ORM / JPA:
Query q = em.createQuery("SELECT u FROM User u WHERE u.name = :name");
q.setParameter("name", name);
Параметризованные запросы гарантируют, что ввод трактуется как данные, а не как часть SQL.
$2$ Хранимые процедуры с параметрами — если используются правильно (без конкатенации внутри процедуры), также защищают.
$3$ ORM, query builders — позволяют избегать ручной конкатенации SQL; всё равно используйте параметры, а не конкатенацию для фильтров и выражений.
$4$ Белый список для структурных частей запроса — если нужно подставлять имена столбцов/таблиц/ORDER BY, нельзя подставлять произвольный ввод: сравнивайте вход с допустимым набором значений и подставляйте только проверенные имена.
$5$ Валидация и ограничение ввода — длина, допустимые символы/формат; это дополнительная защита, но не заменяет параметризацию.
$6$ Экранирование — ненадёжно в одиночку; используйте только как доп. меру с учётом конкретной СУБД и её функций, но лучше избегать ручного экранирования.
$7$ Принцип наименьших привилегий — учётная запись БД для приложения должна иметь минимально необходимые права (SELECT, INSERT и т.п.), не DROP/ALTER без надобности.
$8$ Логи, мониторинг и WAF — как вспомогательные меры (обнаружение аномалий и блокировка известных атак).
Специальные случаи
- LIKE-паттерны: используйте параметры и экранирование метасимволов (%, _) средствами драйвера или вручную, но параметризуйте сам паттерн.
- Динамический SQL (например динамическое ORDER BY): используйте белые списки, а не подстановку пользовательского текста.
Пример безопасного рабочего процесса (минимум)
$1$ Использовать PreparedStatement / parameter binding.
$2$ Валидировать формат ввода и ограничить длину.
$3$ Давать соединению БД минимальные права.
$4$ При необходимости — логирование и мониторинг.
Итог: не конкатенируйте пользовательский ввод в SQL. Используйте параметризованные запросы (PreparedStatement/ORM), валидацию и ограничение привилегий — это простые и эффективные меры против SQL-инъекций.