SQL‑инъекции — что и какие побочные эффекты

Суть: внедрение управляемых пользователем фрагментов SQL в конструкцию запроса, приводящее к изменению логики запроса.Типы: классические (встроенные в параметры), blind (информационный по побочным каналам), time‑based (через задержки), UNION/stacked queries, second‑order (в базе сохранён вредоносный ввод).Побочные эффекты:
Чтение конфиденциальных данных (эксфильтрация).Модификация/удаление данных.Эскалация привилегий и создание новых пользователей.Выполнение команд на сервере БД (через расширения, UDF, xp_cmdshell и т.п.).Разглашение структуры БД через подробные ошибки.DoS: тяжёлые запросы/блокировки, потребление ресурсов.Косвенные утечки через побочные каналы (тайминги, разная длина ответов).

Практические способы защиты от SQL‑инъекций

Параметризованные запросы / Prepared statements: всегда передавать параметры отдельно от текста запроса; это главная и обязательная защита.ORM и query builders: безопасны при использовании API без ручной конкатенации строк; нельзя полагаться на ORM, если вы вставляете raw SQL или динамически формируете идентификаторы.Белые списки (allowlist) для имён таблиц/столбцов и допустимых операций; избегать валидации через регулярные выражения «наугад».Экранирование как запасной вариант, только с проверенной библиотекой и в контексте конкретного драйвера.Ограничение функционала БД: отключить/запретить выполнение файловых операций, внешних процедур, хранимых функций, которые не используются.Отключать поддержку нескольких инструкций в одном запросе, если драйвер это позволяет.Минимизация раскрываемой информации: в проде отключать подробные SQL‑ошибки и стектрейсы.Логи и мониторинг: IDS/WAF, поведенческий анализ запросов, ограничения по частоте запросов, аудит привилегированных команд.Тестирование: SAST/DAST, регулярные пентесты и fuzzing, сценарии blind/time‑based тестов.

Принцип наименьших привилегий для БД

Для приложения использовать отдельного пользователя БД с минимальными правами: только нужные таблицы и операции (SELECT/INSERT/UPDATE/DELETE) — разделять роли для чтения и записи.Запретить DDL/DCL (CREATE, DROP, ALTER, GRANT) для приложений.Не хранить административные учётные данные в коде; управлять секретами через хранилище секретов (vault).Ротация учетных данных и ключей доступа.

Аутентификация и хранение паролей — основные проблемы

Нельзя хранить пароли в открытом виде; нельзя использовать одиночные быстрые хэш‑функции (MD5, SHA‑1, SHA‑256) без соли и растягивания.Надёжная практика:
Хранить только соль+адаптивный KDF (password hashing): Argon2id (предпочтительно), bcrypt, scrypt.Уникальная случайная соль длиной, например, (\,16\ \text{байт}\,) для каждой записи.Адаптивный параметр стоимости: выбирайте рабочий параметр так, чтобы хэш вычислялся медленно, но приемлемо для сервера (пример для bcrypt — cost (\,12), для Argon2 — выставлять время/память/параллелизм в зависимости от оборудования).Рассмотреть «pepper» — глобальный секрет, хранящийся отдельно (в секретном хранилище), добавляемый перед хешированием; это повышает защиту при компрометации БД.Проверка breached passwords: проверять пароли по сервисам типа Have I Been Pwned с k‑анонимностью.Политика паролей: отдавать предпочтение длине (passphrase) вместо сложных требований; предотвращать слишком слабые и часто используемые пароли.Многофакторная аутентификация (MFA) — обязать для критичных операций / админов; поддерживать резервные методы восстановления контролируемо.Password reset: одноразовые однонаправленные токены с коротким сроком действия; хранить токены безопасно, одноразовыми; не отправлять старые пароли по e‑mail.Защита от брутфорса: rate limiting, progressive delays, CAPTCHAs, блокировки по подозрению (с учётом UX).Сессии: безопасные cookies (HttpOnly, Secure, SameSite=strict/ lax в зависимости от требований); менять идентификатор сессии после логина; истечение/ревокация сессий; хранить минимально необходимые данные в сессии.Логирование и приватность: никогда не логировать пароли; логировать попытки входа без персональных данных; шифрование бэкапов.Защита каналов: TLS для веба и межсерверного трафика (включая соединения с БД, если возможно).Хранение секретов: использовать Vault/Secret Manager, не хранить секреты в репозитории или в явных конфигурационных файлах.

Дополнительные рекомендации по безопасности

Защитите административные интерфейсы и API (IP‑фильтры, MFA, VPN).Уменьшайте площадь атаки: минимизируйте открытые порты/функции БД, минимальный набор привилегий у приложений и сервисов.Регулярные обновления: ОС, СУБД, драйверы и библиотеки.Безопасная обработка пользовательского ввода в других контекстах: различать SQL‑энкодинг и HTML/JavaScript‑энкодинг (XSS).Инструменты: использовать prepared statements, ORM/Query builders корректно, WAF, SIEM/DBAM для аналитики активности.

Краткий чек‑лист (тот, что выполнить обязательно)

Параметризованные запросы во всём приложении.Уникальная соль и адаптивный KDF (Argon2id/bcrypt/scrypt) для паролей.Принцип наименьших привилегий для БД-пользователей.TLS на всех каналах, хранение секретов в vault.Логи, мониторинг, ограничение по частоте и MFA.

Если нужно — могу дать краткие примеры кода для prepared statements на конкретном языке или рекомендованные параметры Argon2/bcrypt под вашу нагрузку.