Риск
- Запрос вида `SELECT * FROM users WHERE name = ' + name + ';` вставляет пользовательский ввод прямо в SQL. Злоумышленник может подставить строку, которая изменит синтаксис запроса (SQL‑инъекция), например:
`name = "'; DROP TABLE users; --"` — итоговый SQL выполнит удаление таблицы.
- Последствия: утечка/изменение/удаление данных, обход авторизации, удалённое выполнение команд базы данных.
Как предотвращать (кратко, с пояснениями и компромиссами)
- Параметризованные запросы / Prepared statements
- Идея: разделяют код (SQL) и данные (параметры). База воспринимает параметр как значение, даже если он содержит кавычки/SQL‑ключевые слова.
- Примеры:
- PHP PDO: `$stmt = $pdo->prepare("SELECT * FROM users WHERE name = ?"); $stmt->execute([$name]);`
- Python (psycopg2): `cur.execute("SELECT * FROM users WHERE name = %s", (name,))`
- Плюсы: надёжно защищает, низкая накладная, стандартный подход.
- Минусы: требует использовать API корректно; нельзя динамически параметризовать имена таблиц/столбцов (требуются отдельные меры).
- ORM (Object‑Relational Mapping)
- Идея: формируете запрос через API высокого уровня (фильтры/методы), ORM генерирует безопасный SQL с параметрами.
- Плюсы: удобство, меньше «ручного» SQL, автоматическая параметризация большинства запросов.
- Минусы: при использовании "сырых" SQL внутри ORM — риск; возможна неоптимальная производительность; абстракция может скрывать дорогостоящие запросы (N+1).
- Валидация и белые списки (whitelisting)
- Идея: проверять формат/допустимые символы/длину: например, если name должен быть только буквы/цифры, отклонять всё остальное. Ограничение длины: $\text{len(name)}\le 50$.
- Плюсы: снижает поверхность атаки, полезно для специфичных полей (email, id).
- Минусы: валидация дополняет, но не заменяет параметризацию; слишком жесткая валидация может отвергать легитимные данные.
- Экранирование (escaping)
- Идея: вручную экранировать кавычки и специальные символы с помощью функций драйвера.
- Плюсы: может помочь, если параметризация недоступна.
- Минусы: легко ошибиться; различается между СУБД; менее надёжно, чем параметры.
- Применение принципов безопасности на уровне БД и инфраструктуры
- Привилегии: дать приложению минимум прав (только SELECT/UPDATE нужных таблиц).
- Разделение пользователей БД, использование ролей.
- WAF/IDS как дополнительный уровень защиты (не замена корректной реализации).
- Хранимые процедуры (stored procedures)
- Могут уменьшить риск, если параметры корректно обрабатываются. Но хранимые процедуры тоже уязвимы при конкатенации внутри них.
Компромиссы и рекомендации
- Надёжность VS удобство: параметризованные запросы + валидация дают лучший баланс. ORM повышает продуктивность, но требует понимания, когда использовать "сырые" запросы.
- Производительность: параметризация обычно не даёт заметных потерь; ORM может добавить накладные расходы и генерировать неоптимальные запросы.
- Защита в глубину: не полагайтесь на один метод. Рекомендуется сочетать: параметры/ORM + валидация + минимум привилегий + аудит/логирование.
- Практическое правило: никогда не конкатенировать пользовательский ввод в SQL для формирования синтаксиса. Если нужно подставлять имена таблиц/столбцов, используйте белые списки и строгое разрешение заранее известных значений.
Коротко: замените конструкцию на параметризованный запрос (или безопасный ORM‑вызов), добавьте валидацию и минимальные привилегии — это даёт надёжную защиту при небольших компромиссах по сложности кода и возможной накладной ORM.