Коротко — фрагмент
query = "SELECT * FROM users WHERE name = '" + name + "'"
содержит классическую уязвимость SQL‑инъекции: пользовательская строка вставляется в SQL напрямую. Ниже — разбор рисков, примеры атак и подробный план исправления + хорошие практики с примерами безопасной реализации (PHP и Python).

1) Почему это опасно (какие уязвимости)

SQL‑инъекция: управление синтаксисом запроса через переменную name. Можно изменить WHERE, добавить UNION, выполнить дополнительные команды (если СУБД и драйвер поддерживают множественные выражения), вытянуть или модифицировать данные.Логические уязвимости: подмена имени может позволить обойти авторизацию/аутентификацию, получить доступ к чужим данным, выполнить привилегированные операции косвенно.Вторичные уязвимости: если полученные данные используются далее в других запросах или в HTML, возможны вторичные инъекции или XSS.Информационное раскрытие: подробные ошибки БД в ответах дадут атакующему подсказки.Проблемы кодировки/нормализации: смешение Unicode/UTF‑8 может позволить обход правил фильтрации.

2) Примеры возможных атак (некоторые payload'ы)

Простейший обход: name = "' OR '1'='1"
Итоговый запрос: SELECT * FROM users WHERE name = '' OR '1'='1' — вернёт все записи.UNION/утечка данных: name = "' UNION SELECT password FROM admins -- "Снижение целостности (если драйвер/СУБД поддерживает): name = "'; DROP TABLE users; --"Булева/слепая инъекция (по одному биту): используйте выражения в WHERE, чтобы выяснять значения.Time‑based: "' AND (CASE WHEN (subquery) THEN pg_sleep(5) ELSE pg_sleep(0) END) --" — измеряя задержку, извлекают данные.Second‑order: вредоносная строка записана в БД легитимной операцией, а затем используется в другом месте без параметризации и выполняет инъекцию.

3) Общие последствия

Утечка паролей/личных данных, изменение или удаление данных, обход авторизации, получение доступа к системе, разрушение БД, дальнейшее распространение в инфраструктуре.

4) Принципы защиты — кратко

Никогда не строить SQL конкатенацией строк с пользовательскими данными.Использовать параметризованные/prepared запросы (bind parameters).Валидация и нормализация входа (allow‑list по формату/длине), но не как основная защита от инъекций.Принцип наименьших привилегий для учетной записи БД.Логирование аномалий и мониторинг, но без записи секретных данных в явном виде.Безопасная обработка ошибок — не возвращать детализацию пользователю.Тестирование: SAST, DAST, fuzzing, pen‑test, автоматические сканеры (sqlmap).Защита от вторичных инъекций (sanitize при выводе, parametrize всегда).

5) Практическая реализация — подробные рекомендации и примеры

a) Замена конкатенации на параметризованные запросы

PHP (PDO):
$pdo = new PDO($dsn, $user, $pass, [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]);
$stmt = $pdo->prepare("SELECT * FROM users WHERE name = :name");
$stmt->execute([':name' => $name]);$user = $stmt->fetch();

PHP (mysqli, подготовленные выражения):
$stmt = $mysqli->prepare("SELECT * FROM users WHERE name = ?");
$stmt->bind_param("s", $name);$stmt->execute();
$result=$stmt->get_result();

Python (psycopg2 для PostgreSQL):
cur.execute("SELECT * FROM users WHERE name = %s", (name,))
rows = cur.fetchall()

Python (sqlite3):
cur.execute("SELECT * FROM users WHERE name = ?", (name,))

Заметки:

Никогда не подставляйте параметры вручную в строку.Подготовленные выражения корректно экранируют кавычки и специальные символы.Для ORM (SQLAlchemy, Django ORM) используйте API фильтрации: session.query(User).filter_by(name=name).all()

b) LIKE и спецсимволы
Если нужно использовать LIKE и шаблоны, параметр тоже используйте привязанным, но экранируйте % и _ если они не допустимы пользователем:

Python psycopg2

nameesc = name.replace('\', '\\').replace('%', '\%').replace('', '\_')
cur.execute("SELECT * FROM users WHERE name LIKE %s ESCAPE '\\'", (name_esc + '%',))

c) Имена таблиц/столбцов
Параметры не работают для идентификаторов (имя таблицы/столбца). Для таких случаев строго использовать allow‑list:
allowed_columns = {'id','name','email'}
if sort_by in allowed_columns:
query = f"SELECT * FROM users ORDER BY {sort_by}"
else:
raise ValueError("invalid sort")

d) Ограничение прав БД

Приложенческий пользователь должен иметь только нужные привилегии (SELECT, INSERT/UPDATE только где нужно). Не давать право DROP, ALTER, GRANT, CREATE если не требуется.Отдельные учетные записи для админских операций.

e) Валидация и нормализация входных данных

Нормализуйте Unicode (NFC) чтобы предотвратить обход allow‑list.Ограничьте длину полей (например, username <= 50).Для username предпочтительна allow‑list (буквы, цифры, дефис, подчёркивание), регулярные выражения.Не пытайтесь "экранировать всё" как основную защиту от инъекций — используйте parametrize.

f) Защита от вторичных атак

Всегда parametrize и при том, даже если данные берутся из БД (second‑order injection).При выводе в HTML — применяйте HTML‑escape (во фронтенде/шаблонизаторе).

g) Логирование и мониторинг

Логируйте аномальные запросы и неудачные попытки с таймстампом, IP, user‑agent.Не логируйте пароли/секреты в явном виде. Маскируйте чувствительные параметры.Настройте алерты при всплесках ошибок/запросов с распространёнными payload‑ами.Централизованный лог (SIEM) + retention policy + защита логов от изменения.

h) Обращение с ошибками

Показывайте пользователю общие сообщения ("Произошла ошибка"), детали — в логах.Отключите вывод трассировок/ошибок БД в продакшн.

i) Тестирование и CI

Добавьте SAST и правила проверки использования SQL в CI.Регулярно прогоняйте DAST (sqlmap и т.п.).Ревью кода: поиск мест, где используется конкатенация для SQL.Пентесты — периодические.

6) План внедрения исправлений (пошагово)

Инвентаризация: найти все места в кодовой базе, где формируются SQL‑запросы конкатенацией.Немедленно исправить самые критичные: точки авторизации, входа/регистрации, операции с привилегированными данными.Заменить конкатенацию на параметризованные запросы/ORM everywhere.Ввести проверку и нормализацию входа (length, allow‑list) там, где применимо.Настроить учетную запись БД с минимальными правами для приложения.Включить логирование аномалий и оповещения.Запустить автоматические сканеры по уязвимостям и проводить ревью.Обучить разработчиков правилам безопасной работы с SQL.Периодически ревизировать и тестировать (pen‑test, fuzz).

7) Дополнительные меры

Web Application Firewall (WAF) как дополнительный барьер (не замена параметризации).Использование ролей и row‑level security в СУБД (Postgres RLS) для усиления контроля доступа.Хеширование паролей (bcrypt/argon2) — если речь о аутентификации.Регулярные обновления СУБД и библиотек драйверов.

8) Пример: безопасный код и комментарии (сравнение)
Уязвимый:
query = "SELECT * FROM users WHERE name = '" + name + "'"

Безопасный (Python/psycopg2):
cur.execute("SELECT * FROM users WHERE name = %s", (name,))
rows = cur.fetchall()

Безопасный (PHP/PDO):
$stmt=$pdo->prepare("SELECT * FROM users WHERE name = :name");
$stmt->execute([':name' => $name]);
$user = $stmt->fetch();

9) Часто встречающиеся ошибки/парадоксы

"Я экранирую кавычки — значит безопасно" — эскейпинг вручную часто ошибочен и ненадёжен, особенно с разными СУБД и кодировками."WAF решит проблему" — WAF помогает, но не заменяет parametrize."Stored procedure — безопасно" — хранимые процедуры безопасны только при использовании параметров; если внутри они динамически конструируют SQL — остаётся уязвимость.

Итог: основной и обязательный шаг — убрать конкатенацию и использовать привязанные параметры. Дополнительно применить валидацию/нормализацию, минимальные права для БД, безопасную обработку ошибок, логирование и тестирование. Это вместе закроет большинство векторов SQL‑инъекций и связанных проблем.

Если нужно, могу:

Пройтись по вашему реальному коду и показать конкретные исправления.Сгенерировать правила для SAST/CI чтобы ловить подобные места.Подготовить шаблон политики прав доступа для БД.