Потенциальные угрозы (из-за строки query = "SELECT * FROM users WHERE login = '" + userInput + "'";)

SQL-инъекции (SQLi): вставка userInput может привести к подмене/добавлению SQL‑команд (например, ' OR '1'='1', '; DROP TABLE users; --), чтению/изменению/удалению данных, обходу аутентификации. XSS (косвенно): если результат запроса или ввод сохраняется и выводится в UI без корректного экранирования — злоумышленник может вставить скрипт. RCE / командная инъекция (опосредованно): через SQLi можно вытянуть конфиденциальные данные (пароли, ключи) и затем использовать их для дальнейших атак; в некоторых СУБД возможна эскалация в исполняемый код (например, функции, вызывающие shell), либо компрометация приложения приводит к RCE. Утечка данных и привилегий: чрезмерные права учетной записи БД позволяют любым SQLi расширить ущерб. Логирование чувствительных данных: если логируются "чистые" входы, инъекции сохраняются в логах и могут раскрыть данные.

План исправлений

На уровне кода

Параметризация запросов (prepared statements / bind parameters). Примеры:
Java (JDBC):
PreparedStatement ps = conn.prepareStatement("SELECT id, login FROM users WHERE login = ?");
ps.setString(1, userInput);
ResultSet rs = ps.executeQuery();PHP (PDO):
$stmt = $pdo->prepare("SELECT id, login FROM users WHERE login = :login");
$stmt->execute(['login' => $userInput]);Python (psycopg2):
cur.execute("SELECT id, login FROM users WHERE login = %s", (userInput,));Не собирать SQL конкатенацией и не пытаться «правильно экранировать» вручную.Минимизировать возвращаемые столбцы (select only needed columns) и не возвращать пароли/хэши.Валидация входных данных по белому списку (формат логина: допустимые символы, длина). Отдельно валидировать контексты (DB, HTML, shell).Экранирование/кодирование при выводе в браузер (для XSS): HTML‑экранирование, Content Security Policy (CSP).Ограничить возможность выполнения нескольких команд за один запрос (например, отключить multi‑statements в драйвере).Использовать ORM/абстракции с поддержкой безопасных параметров, но следить за raw SQL в ORM.Хранить пароли только как стойкие хэши (bcrypt/argon2), не хранить секреты в коде.

На уровне архитектуры

Разделение привилегий: дать приложению минимально необходимую роль/пользователя БД (разные учётные записи для чтения/записи/администрации).Сеть и доступ: БД недоступна напрямую из интернета; доступ только с доверенных приложений/серверов, использовать VPC, ограничить IP.Шифрование каналов (TLS) и at‑rest (по необходимости).Изолировать критичные сервисы, разделять привилегии между компонентами.Вставить слой WAF для базовой фильтрации известных паттернов SQLi и XSS.Использовать RASP/EDR для раннего обнаружения и блокировки подозрительного поведения.

На уровне процессов (валидaция, тестирование, развёртывание)

Валидация: стандартизовать валидацию входов в библиотеках, централизовать правила, белые списки, лимиты по длине.Код‑ревью: обязательные ревью для всех изменений, затрагивающих SQL/аутентификацию/логирование.SAST/DAST/IAST: интегрировать статический анализ и динамическое сканирование в CI/CD; запускать DAST перед релизом.Регулярные пентесты и ревью конфигурации БД/сервисов.Тесты: unit/integration тесты, имитирующие типичные payload‑ы SQLi и XSS (fuzzing), тесты на отказоустойчивость.CI/CD: автоматические блокировки мерджей при нахождении уязвимостей, секрет‑сканирование.Политики логирования: не логировать чувствительные данные в явном виде, использовать маскирование/редакцию.

Методы обнаружения атак в продакшне

WAF: сигнатурный и поведенческий контроль запросов (правила против SQLi/XSS). Хорош для блокировки массовых автоматических атак.SIEM/логирование: централизованные логи приложения и БД; корелляция событий (всплески ошибок SQL, неожиданные долгие запросы, частые 500/400 ответы).Аудит БД: включить аудит запросов (особенно на привилегированные операции), журналировать параметры (с маскировкой секретов) и источники.Anomaly detection: мониторинг количества и формы параметризованных значений (например, внезапный рост количества уникальных логинов/запросов с подозрительными символами), ML‑детекторы для нетипичных паттернов запросов.Honeytokens / honeypot‑аккаунты: создания «фальшивых» записей/аккаунтов в БД; обращение к ним — индикация компрометации.RASP: обнаружение/блокировка SQLi/XSS на рантайме в самом приложении (отслеживает вызовы API, соединения к БД, попытки exec).Мониторинг медленных/необычных запросов: частые длинные или сложные JOIN/подзапросы, резкие изменения в профиле запросов.Обнаружение исключений и ошибок БД: массовые синтаксические ошибки/ошибки типизации могут указывать на инъекции; подавлять детальные ошибки пользователю, но логировать их для анализа.Сигнатуры и эвристики в IDS/IPS: искать характерные payload‑шаблоны (UNION SELECT, --, ; DROP, ' OR '1'='1').Нотификации и playbooks: при детекции — автоматические блокировки IP, выяснение масштаба, форензика; иметь заранее подготовленный план реагирования.

Короткие эксплуатационные рекомендации (неотложно)

Немедленно заменить такие конкатенированные запросы параметризованными. Ограничить права БД, включить аудит и централизованное логирование. Включить WAF и настроить базовые правила SQLi/XSS. Добавить тесты на CI и запланировать пентест.

Если нужно, могу прислать чек‑лист по конкретным изменениям в кодовой базе или примеры исправлений для вашего стека.