SQL Injection — одна из самых известных уязвимостей веб-приложений. Она возникает, когда пользовательский ввод напрямую попадает в SQL-запрос без безопасной обработки. В результате злоумышленник может изменить логику запроса, получить доступ к данным, обойти авторизацию или даже удалить таблицы.
Как это работает
Типичный сценарий — форма входа. Если приложение собирает запрос строкой вроде:
SELECT * FROM users WHERE login = 'user' AND password = 'pass'то атакующий может подставить специальные конструкции в поля ввода. Если фильтрации нет, база выполнит уже изменённый запрос, а не тот, который задумал разработчик.
Чем опасна SQL-инъекция
Она может привести к:
- краже логинов, паролей, персональных данных
- обходу аутентификации
- чтению, изменению и удалению записей
- получению административного доступа
- компрометации всей системы при связке с другими уязвимостями
Основные виды SQL Injection
- In-band — результат атаки сразу виден в ответе приложения
- Blind SQLi — прямого вывода нет, но уязвимость определяется по логике ответа или времени отклика
- Error-based — через сообщения об ошибках БД
- Union-based — через добавление
UNION SELECTдля извлечения данных - Time-based — через искусственные задержки, например
SLEEP()⏱️
Где чаще всего встречается
- формы логина и поиска
- GET/POST-параметры
- фильтры и сортировки
- API с небезопасной обработкой параметров
- legacy-код, где SQL собирается конкатенацией строк
Как защититься
Главное правило: никогда не вставлять пользовательский ввод напрямую в SQL.
Надёжные меры защиты:
- использовать prepared statements и параметризованные запросы
- применять ORM, но не считать её абсолютной защитой
- валидировать входные данные по типу, длине и формату
- ограничивать права аккаунта БД по принципу минимально необходимых привилегий
- скрывать подробные ошибки SQL от пользователя
- использовать WAF как дополнительный, а не основной слой защиты
- регулярно проводить SAST/DAST-анализ и code review 🔍
Практический антипример
Плохо: запрос собирается через конкатенацию строк из login и password.
Хорошо: значения передаются как параметры, а структура SQL остаётся неизменной независимо от ввода пользователя.
Как понять, что приложение уязвимо
Косвенные признаки:
- странные ошибки БД на спецсимволах
- изменение поведения при вводе кавычек
- задержки ответа на нестандартные параметры
- различия в ответах при логически истинных и ложных условиях
Вывод
SQL Injection — не «старая» проблема, а всё ещё актуальный риск для сайтов, CRM, админок и внутренних сервисов. Большинство успешных атак происходит не из-за сложности техники, а из-за базовых ошибок разработки. Безопасный доступ к БД должен быть стандартом, а не опцией. 🚨
📌 Ниже стоит посмотреть подборку каналов про IT — там много полезного по backend, security, DevOps и разработке.