Глоссарий
Что такое SQL-инъекция (SQLi) — когда ввод переписывает команды вашей базы данных
SQL-инъекция (SQLi) — это когда пользовательский ввод переписывает смысл запроса к базе данных (SQL), что ведёт к чтению, изменению или удалению данных. Как это работает и реальная защита (плейсхолдеры / подготовленные выражения, ORM, пользователи БД с минимумом привилегий) — изложено в защитном ключе, без шагов атаки.
«Текст, который вы ввели в поле поиска, становится „частью команды“ для базы данных» — это и есть SQL-инъекция. Вот как она работает и как её надёжно предотвратить (без шагов атаки).
Почему это происходит (механизм)
Корневая причина — построение SQL склейкой строк. Подмешайте ввод прямо в выражение, и он может пересечь «границу значения» и сработать как команда.
✗ Склейка строк (опасно)
Ввод склеен в выражение → ввод может быть прочитан как часть команды
✓ Плейсхолдеры (безопасно)
Значения передаются в слоты ? / $1 как данные → всегда остаются значениями
Ущерб — «всё, что может это соединение с БД». Если внутренняя БД достижима, это классический вход к массовым утечкам, наряду с RCE и SSRF.
Защита
Используйте плейсхолдеры / подготовленные выражения (самое важное)
Не стройте SQL склейкой. Передавайте значения через ? / именованные параметры как «данные». Уже это почти полностью устраняет весь класс.
Опирайтесь на ORM / конструктор запросов
Большинство ORM используют плейсхолдеры по умолчанию. Чем меньше сырого SQL вы пишете руками, тем безопаснее. Если приходится писать сырой SQL, всегда параметризуйте его.
Пользователь БД с минимумом привилегий
Не давайте пользователю БД приложения лишних прав (DROP, другие таблицы, админ-операции). Даже при взломе локализуйте ущерб.
Валидация ввода как дополнение
Проверки типа/длины/формата помогают, но не делайте их основной защитой — они стоят поверх плейсхолдеров.
Мнение этого сайта: перестаньте вообще строить сырой SQL руками
SQLi существует вечно, но не умирает — потому что подмешивать ввод в выражение «удобно». Позиция этого сайта проста: никогда не создавайте место, где значения склеиваются строками в SQL. Сделайте плейсхолдеры или ORM умолчанием, и эта уязвимость исчезает по конструкции. Не идите по дороге «постараться лучше с ручным экранированием».
Слепое пятно: плейсхолдеры несут только «значения»
Плейсхолдеры не панацея. Они несут только значения — не структуру запроса вроде имён таблиц, имён столбцов или направления ORDER BY (asc/desc).
Когда они нужны динамическими (например, дать пользователю выбрать «ключ сортировки» или «столбец фильтра»), не вставляйте ввод в SQL — выбирайте реальное имя из заранее заданного allowlist. «Столбец сортировки» и «столбец фильтра» — классические слепые пятна, где люди полагают, что плейсхолдеры их прикрыли.
Читать дальше
- Глоссарий: Что такое RCE · Что такое XSS
- Основы: Основы безопасности
FAQ
QЧто происходит при SQL-инъекции?
Атакующий меняет смысл запроса к базе данных — читает данные, которые должны быть скрыты, изменяет их или, в худшем случае, стирает всё либо обходит аутентификацию. Это классическая причина массовых утечек данных.
QКакая защита самая надёжная?
Передавать значения через плейсхолдеры (подготовленные выражения). Не стройте SQL склейкой строк; передавайте значения как «данные» по отдельному каналу, чтобы ввод никогда не мог быть прочитан как команда. Большинство ORM делают это по умолчанию.
QДостаточно ли экранировать ввод?
Ручное экранирование подвержено ошибкам и не рекомендуется. Используйте плейсхолдеры. Также дайте пользователю БД минимум привилегий, чтобы сократить радиус поражения, если что-то пройдёт.