Проблема: конкатенация: `query = "SELECT * FROM users WHERE name = '" + name + "'";` — делает приложение уязвимым к SQL‑инъекциям и связанным атакам.
1) Возможные уязвимости и векторы эксплуатации
- Прямая SQL‑инъекция (вставка логики): пример полезной нагрузки `name = "' OR '1'='1"` → выполняется `SELECT * … WHERE name = '' OR '1'='1'` — возврат всех строк.
- UNION‑инициация для чтения других таблиц: `name = "' UNION SELECT credit_card FROM cards --"`.
- Stacked queries / множественные запросы (если драйвер/БД поддерживают): `name = "a'; DROP TABLE users; --"` — удаление таблицы.
- Error‑based, boolean‑based и time‑based blind‑injection (извлечение данных при отсутствии явного вывода).
- Second‑order injection: вредоносные данные сохраняются затем используются в другом месте.
- SQL‑инъекция через идентификаторы (таблицы/столбцы): если имя таблицы/поля формируется из входа.
- Смежные последствия: утечка конфиденциальных данных, обход авторизации, эскалация привилегий, выполнение команд на сервере (через расширения), компрометация целостности данных.
2) Примеры полезной нагрузки (для понимания механики, не для эксплуатации в проде)
- Тривиальная: `name = "' OR '1'='1' -- "`
- UNION: `name = "' UNION SELECT username, password FROM admins -- "`
- Time‑based: `name = "'; IF (SUBSTR(password,1,1)='a') WAITFOR DELAY '0:0:10' --"`
3) Меры предотвращения — на уровне кода
- Параметризованные запросы / prepared statements (binding): всегда передавать значения как параметры, не конкатенировать.
Пример: `SELECT * FROM users WHERE name = ?` с привязанным параметром.
- Отказ от ручного экранирования как основного механизма (экранирование ошибочно и ненадежно).
- Whitelist валидация для полей, используемых как идентификаторы (имя таблицы/столбца/категории): проверять по списку разрешённых значений и механически подставлять через безопасный маппинг.
- Ограничение длины и нормализация ввода (вспомогательное).
- Не хранить чувствительные данные в виде открытого текста; логирование входа — без отображения сырых параметров (чтобы не логировать вредоносные полезные нагрузки).
- Отключить/не давать клиентскому соединению возможность выполнять несколько запросов за один вызов (multi‑statements) в драйвере, если не нужно.
4) На уровне ORM
- Использовать стандартные API ORM для запросов (фильтры, методы поиска), а не форматировать строки.
- Не использовать "raw SQL" или использовать привязанные параметры в raw‑вызовах.
- Для динамических идентификаторов — сопоставление через словарь/enum (whitelist), а не строковая подстановка.
- Проверьте, как ORM компилирует запросы — убедитесь, что параметры действительно передаются как bind‑variables, а не подставляются.
5) На уровне БД и инфраструктуры
- Принцип минимальных привилегий: учётная запись приложения — только необходимые права (обычно SELECT/INSERT/UPDATE/DELETE на нужные таблицы). Ни в коем случае не админ/дбадмин.
- Отключение опасных расширений/функций (например, `xp_cmdshell` в MSSQL, LOAD_FILE и подобные).
- Разделение прав между сервисами (чтение / запись, бэкап/админ).
- Включить журналирование и аудит запросов, мониторинг аномалий запросов.
- Настроить сетевой доступ к БД (firewall, приватные сети).
- Ограничить возможность multi‑statement на уровне драйвера/конфигурации сервера, если не требуется.
6) Тестирование и контроль
- SAST/DAST сканеры, автоматические тесты на SQLi (fuzzing), тестовые кейсы на крайние значения.
- Ревью кода с фокусом на места, где формируются SQL‑строки.
- Регулярные пентесты и использование инструментов типа sqlmap в контролируемой среде.
7) Политика раскрытия уязвимостей для образовательного проекта
- Сообщать уязвимость приватно администраторам проекта и/или через указанный канал (email/issue/bugtracker).
- В сообщении: краткое описание, шаги воспроизведения (POC) в тестовой среде, оценка риска, рекомендованные исправления. Не публиковать рабочие эксплойты против живых/производственных данных.
- Договориться о разумном сроке на исправление; типично договорённый период — например, $90$ дней — до публичного раскрытия, если иное не согласовано.
- Если проект образовательный и цель — обучение, согласовать с владельцами формат публичного описания (санitized POC, учебные примеры на стенде).
- Действовать в рамках закона и этики: не эксплуатировать уязвимость на реальных данных, не разглашать чувствительную информацию.
Краткая рекомендация: прекратите конкатенацию запросов; замените на параметризованные запросы/ORM‑API и настройте минимальные привилегии в БД — это закрывает большинство рисков.