Коротко: исходная строковая конкатенация в коде приводит к множеству уязвимостей (в первую очередь — SQL‑инъекции) и сопутствующим проблемам. Ниже — список уязвимостей, способы их эксплуатации и архитектура безопасной обработки входных данных.
Уязвимости (что именно и почему)
- SQL‑инъекция (динамическая конкатенация делает запрос управляемым вводом). Результат — раскрытие/изменение/удаление данных, обход аутентификации, выполнение произвольных запросов.
- Stacked queries / множественные запросы (если СУБД/драйвер поддерживают несколько выражений в одном запросе) — можно выполнить дополнительный DDL/DML.
- Blind SQL‑инъекция (если ответы схемы не выдаются явно) — побитовая/по времени эксфильтрация данных.
- Вторичные (second‑order) инъекции — сохранённые вредоносные строки в БД, которые затем подставляются в другие динамические запросы.
- Логическая и кодировочная уязвимость (charset/encoding tricks, unicode‑обходы) — обход фильтров и нормализации.
- Неправильная обработка ошибок — подробные SQL‑ошибки дают подсказки для инъекций.
- Привилегии и конфигурация — утилита с высокими правами в сочетании с инъекцией приводит к эскалации ущерба.
Примеры методов эксплуатации (payload‑примеры)
- Аутентификация / обход фильтра: ${}^{\prime }OR{}^{\prime }{1}^{\prime }{=}^{\prime }{1}^{\prime }--$ (вставляется в поле name, превращая WHERE в всегда истинное условие).
- UNION‑эксплуатация (вытягивание столбцов): ${}^{\prime }UNIONSELECTusername,passwordFROMadmin--$ - Blind boolean (построение побитовой проверки): подставлять условия и смотреть изменения в поведении/ответе сервера, например ${}^{\prime }AND(SELECTCASEWHEN(SUBSTRING((SELECTpasswordFROMusersWHEREname{=}^{\prime }admi{n}^{\prime }),1,1){=}^{\prime }{a}^{\prime })THEN1ELSE0END)--$ - Time‑based blind (по задержке): ${}^{\prime }ORIF((SELECTSUBSTRING(password,1,1)FROMusersWHEREname{=}^{\prime }admi{n}^{\prime }){=}^{\prime }{a}^{\prime },SLEEP(5),0)--$ - Stacked queries (если разрешены): ${}^{\prime };DROPTABLEusers;--$ - Second‑order: сохраняется безопасно выглядящая строка, затем используется в другом динамическом SQL и вызывает инъекцию.
Архитектура безопасной обработки входных данных (рекомендуемая многослойная схема)
- Входной слой (приём и нормализация):
- Канонизация/нормализация кодировок (всё к UTF‑8), удаление невидимых символов.
- Ограничение длины и типов данных (строки, числа, форматы) — по белому списку.
- Валидатор (бизнес‑логика):
- Проверка по allow‑list (только разрешённые символы/паттерны для конкретного поля).
- Приведение типов (типизировать вход: если ожидается integer — преобразовать/отклонить).
- Слой доступа к данным (DAO/Repository):
- Единственный путь к БД через централизованный модуль, использующий параметризованные запросы / подготовленные выражения.
- Пример безопасного шаблона: подготовить запрос с плейсхолдером, затем привязать значение:
- SQL: "SELECT * FROM users WHERE name = ?" — затем bind(name).
- Не использовать ручную конкатенацию для SQL. Если используется ORM — использовать API, автоматически экранирующее параметры.
- Отключить возможность выполнения нескольких команд в одном запросе (disable multi‑statements) в конфигурации драйвера, если возможно.
- Минимизация прав:
- Для приложения использовать отдельного DB‑пользователя с минимально необходимыми привилегиями (только SELECT/INSERT/UPDATE там, где нужно).
- Логирование и мониторинг:
- Логировать аномалии и бот‑активность, включить аудит SQL‑запросов (особенно неудачные/подозрительные).
- Настроить WAF/IDS/IPS для блокировки типовых payload‑ов и аномалий.
- Защита ошибок и ответы:
- Не показывать подробные SQL‑ошибки пользователям; логировать их в защищённое хранилище.
- Тесты и процессы:
- SAST/DAST и регулярные аудитные тесты (включая автоматические тесты на SQL‑инъекции).
- Code review политики: запрет на шаблонную конкатенацию SQL в PR.
- Дополнительные меры:
- Если нужен динамический SQL — применять строгую белую фильтрацию частей, которые вставляются в идентификаторы (имена таблиц/столбцов), и использовать параметризацию для значений.
- Использовать prepared statements / parameter binding / ORM queries / stored procedures с параметрами — только как набор параметров, не как строковая подстановка.
- В качестве дополнительного барьера — WAF и ограничение частоты запросов.
Короткое резюме практических действий для разработчика сейчас
- Немедленно заменить конкатенацию на параметризованный запрос (prepared statement).
- Настроить DB‑аккаунт с минимальными правами.
- Ввести валидацию и нормализацию входа по белому списку.
- Включить логирование и тестирование на инъекции в CI.
Если нужно — могу дать краткий пример кода безопасного запроса для конкретного языка/СУБД.