Коротко: строка
SELECT * FROM users WHERE username = "' + username + '"
— это классическая уязвимая конкатенация входных данных в SQL. Ниже — полный обзор возможных уязвимостей (технических и бизнес‑логических), многоуровневая стратегия защиты (код, конфигурация, процессы) и методы проверки/тестирования безопасности.

1) Какие уязвимости возможны

SQL‑инъекции
Прямые/рефлекторные: ввод "' OR '1'='1" и т.п. позволяет обходить фильтры.Blind (boolean/time‑based) — когда ответы не содержат ошибок, но по времени/логике можно извлечь данные.UNION/stacked queries (если БД и драйвер позволяют несколько запросов) — вытягивание других таблиц или выполнение дополнительных команд.Second‑order SQLi — вредоносные данные сохраняются в БД и используются позднее в некорректных конкатенациях.Инъекции в другие контексты (LDAP, XPath, OS) из полей, если эти данные используются дальше в системе.XSS (если username отображается в UI)
Stored XSS — вредоносный username сохраняется и отображается другим пользователям.Reflected/DOM XSS — username возвращается в ответе без кодирования.CSRF
Если действия (например, смена профиля) выполняются по запросу без CSRF‑токена, атакующий может заставить жертву выполнить нежелательное действие.Аутентификация/авторизация и бизнес‑логика
Username enumeration — разные сообщения об ошибках (или разные задержки) позволяют определить, какие username существуют.Bypass авторизации — если авторизационные решения или права доступа делаются на основании пользовательского поля username без проверки, можно подделать.Privilege escalation — возможность изменить username/роль и получить доп. привилегии.Race conditions — конкурентные изменения (например, reset password) без корректной синхронизации.Mass assignment / insecure direct object references (IDOR) — если username/идентификатор используются напрямую для доступа к ресурсам.Неправильная логика восстановления пароля / сброса — утечка токенов, слабые токены, predictable tokens.Информационные утечки и ошибки
Подробные сообщения об ошибках (SQL ошибки) раскрывают структуру БД.Логирование чувствительных данных (пароли, токены) в незашифрованные логи.Конфигурационные уязвимости
ДБ‑пользователь с избыточными привилегиями.Включение многостейтментных запросов (allow_multi_statements).CORS/Headers misconfiguration, отсутствие CSP, незащищённые cookies.Прочее
Неправильная нормализация/некорректный обработчик Unicode/encoding leading to bypasses (homoglyphs, encoded quotes).Отсутствие лимитов: брутфорс username/password, enumeration via automated probes.

2) Примеры атак (для тестирования, использовать только в разрешённой среде)

Простая проверка SQLi:
username: "anything" OR "1"="1username: "admin"'; -- (если допускаются кавычки)Blind/time‑based:
username: ' OR IF(SUBSTRING((SELECT password FROM users WHERE username='admin'),1,1)='a', SLEEP(5), 0) -- XSS:
username: alert(1)CSRF:
Поддельная форма, отправляющая POST запрос к /profile/update

3) Многоуровневая стратегия защиты
Общая идея: защита в глубину — валидировать, параметризовать, кодировать выход, минимальные привилегии, мониторинг и процессы контроля.

A. Уровень кода (самое важное)

Использовать параметризованные запросы / подготовленные выражения (prepared statements) ВСЕГДА, никогда не конкатенировать строки.
Примеры:PHP (PDO):
stmt = $pdo->prepare('SELECT id, username, email FROM users WHERE username = ?');
$stmt->execute([$username]);Python (psycopg2):
cur.execute('SELECT id, username FROM users WHERE username = %s', (username,))Java (JDBC):
PreparedStatement ps = conn.prepareStatement("SELECT id, username FROM users WHERE username = ?");
ps.setString(1, username);Node.js (pg):
client.query('SELECT id, username FROM users WHERE username = $1', [username]);Не использовать SELECT * — явно перечисляйте колонки, чтобы свести к минимуму возврат чувствительных данных.Запретить выполнение нескольких SQL‑инструкций в одном запросе (если драйвер/БД позволяет выключить).Use ORMs корректно: не составлять raw SQL с конкатенацией; использовать встроенные безопасные API.Валидация входа:
Белые списки там, где возможно (формат username: разрешённые символы, длина).Нельзя полагаться на валидацию на клиенте — проверять на сервере.Нормализация Unicode (NFC/NFKC) при сравнении/сравнении usernames для предотвращения bypass.Контекстное кодирование при выводе:
Для HTML — HTML‑encode (escape) все пользовательские данные.Для атрибутов, JavaScript, URL — соответствующее кодирование.Используйте зрелые библиотеки (например, OWASP Java Encoder, htmlspecialchars в PHP, DOMPurify при необходимости разрешать HTML).Защита от XSS:
По возможности не разрешать HTML в username.Если нужно показывать HTML, очищайте через санитайзер и применяйте CSP.CSRF:
Для state‑changing действий требовать CSRF‑токен (per‑session or per‑form).Использовать SameSite=strict/strict/lax и Secure+HttpOnly для cookie.При необходимости требовать двойную аутентификацию для чувствительных операций.Ограничение количества попыток/Rate limiting:
Блокировать/замедлять брутфорс и перебор username.Error handling:
Показать общие сообщения об ошибках (не «username does not exist» vs «password incorrect»).Не логировать чувствительные данные (пароли, токены).Логирование и мониторинг:
Логи запросов, медленные запросы, ошибки БД — с алертами.Записывать подозрительные паттерны (входящие payloads с SQL‑паттернами).Защита от second‑order SQLi:
При чтении ранее сохранённых значений тоже использовать параметризованные запросы; санитайзить данные при выводе и повторном использовании в SQL.Защита на прикладном уровне:
Проверки авторизации по user_id, ролям, а не по username из формы.Если принимаете username как параметр для доступа к данным — проверяйте, что текущий пользователь имеет право смотреть/изменять эти данные.

B. Конфигурация и инфраструктура

База данных:
Пользователь БД с минимальными правами (только SELECT/INSERT/UPDATE/DELETE там, где нужно).Отключить мультитейтенси/выполнение нескольких команд, если не требуется.Использовать TLS для соединения к БД.Подключать запросы под отдельными пользователями; не запускать приложение под суперпользователем БД.Веб‑сервер/приёмник:
Включить HTTP headers: Content‑Security‑Policy, X‑Content‑Type‑Options: nosniff, X‑Frame‑Options, Referrer‑Policy, Strict‑Transport‑Security.Установить SameSite/HttpOnly/Secure для cookies.Настроить CORS корректно (ограничить origin).WAF/IDS:
Внешний WAF (Web Application Firewall) может блокировать известные шаблоны SQLi/XSS, но не заменяет правильный код.CI/CD и конфигурация:
Управление секретами (не хранить creds в репозитории).Обновление зависимостей (SBOM, vulnerability scanning).Сеть и изоляция:
Минимизировать доступ к БД (только из приложений), firewall rules, сегментация.

C. Процессы и организация

Threat modeling и security requirements до разработки.Code review с фокусом на безопасность (проверка мест, где собирается SQL/HTML).Обязательный SAST в pipeline, динамическое тестирование (DAST) на этапе QA.Регулярный pentest внешних/внутренних приложений.Регулярная проверка зависимостей (SCA).Политика отката/патчирования и инцидент‑реакция.Обучение разработчиков безопасному кодированию (OWASP).Тестовые среды: тестировать SQLi/XSS только в изолированной среде с разрешением.

4) Примеры безопасного кода (расчленённо)

Не делать:
sql = "SELECT * FROM users WHERE username = '" + username + "';"Делать (псевдокод):
prepared = db.prepare("SELECT id, username, email FROM users WHERE username = ?")
prepared.execute([username])

(См. раздел "Уровень кода" для конкретных синтаксисов в PHP/Python/Java/Node.)

5) Дополнительные меры безопасности UX/бизнес

Оповещения о входах с новых устройств/IP.MFA для чувствительных операций.Защита восстановления пароля: одноразовые, короткоживущие токены, проверка по e‑mail, rate limiting, anti‑enumeration.Captcha при множественных неудачных попытках.Минимизация данных, которые отображаются (не показывать хеши/подробности БД).Прозрачность и уведомления при обнаружении уязвимости.

6) Методы проверки безопасности (тест‑план)

Статический анализ (SAST): найти конкатенации строк, SQL в коде, вызовы exec().Динамический анализ (DAST):
OWASP ZAP, Burp Suite: сканирование формы username на SQLi/XSS/CSRF.Автоматизированные скрипты для ввода payloads (включая time‑based payloads).Специализированные инструменты:
sqlmap (ответственное тестирование в разрешённой среде) — для поиска SQLi.Snyk/OSS‑scanners — для библиотек.Мануальное тестирование:
Попытки SQLi (тесты с кавычками, комментами, UNION).Blind SQLi: boolean/time tests.XSS: ввод и вариаций (JS URI, атрибуты, html entities).CSRF: попытка отправить запрос с другого сайта/файла без токена.Проверка ответов сервера на ошибки — информация о БД/структуре.Тест на username enumeration (во времени, ответах и кодах статуса).Интеграционные/юнит‑тесты:
Автоматические тесты, проверяющие, что интерфейсы используют параметризованные запросы (mock DB).Тесты входных валидаций.Pentest и Bug Bounty:
Регулярные независимые проверки и открытую программу вознаграждений (если уместно).

7) Контрольный чеклист (минимум)

[ ] Все SQL запросы параметризованы.[ ] Нет конкатенации user input в SQL/OS/LDAP/XPath.[ ] Все выводимые пользовательские данные закодированы по контексту.[ ] CSRF токены присутствуют для изменяющих операций.[ ] Cookies: Secure, HttpOnly, SameSite.[ ] БД‑пользователь с минимальными привилегиями.[ ] Ограничение по количеству попыток и защита от брутфорса.[ ] Логи и мониторинг настроены, алерты на аномалии.[ ] SAST/DAST и pentest в цикле релизов.[ ] Политики обработки ошибок: не раскрывать структуру БД/стеков.[ ] Политика управления зависимостями и обновлениями.

8) Примечания по ответственному тестированию

Никогда не атакуйте продакшн без письменного разрешения.Используйте изолированные стенды/дампы БД при тестах.Логируйте и уведомляйте команду безопасности о найденных уязвимостях.

Резюме: исправление указанной уязвимости — обязательная замена конкатенации на parameterized queries + серверная валидация входа + выходное кодирование и CSRF/авторизационные проверки. Дополнительные слои защиты: конфигурация БД, заголовки безопасности, мониторинг и процессные меры (SAST/DAST, code review, pentest). Если хотите, могу:

Привести конкретные пример‑реализации безопасного кода для вашего стека (укажите язык/фреймворк).Подготовить пошаговый план тестирования (SAST/DAST сценарии, payloadы) для вашей среды.