Что такое SQL-инъекция и как от неё защититься? Какие ещё уязвимости API нужно знать?
Короткий ответ
- Инъекция — пользовательский ввод попадает в SQL как код
- Защита — параметризованные запросы, никакой конкатенации строк
- ORM и query builder экранируют параметры автоматически
- Принцип наименьших привилегий для учётки базы
- Рядом по OWASP: XSS, CSRF, сломанная авторизация (IDOR), утечки в ошибках
- Валидация ввода — дополнение, а не замена параметризации
Единственная надёжная защита от SQL-инъекции — параметризованные запросы; остальное — дополнительные слои.
Как сказать вслух
пример ответаSQL-инъекция — это когда строка от пользователя подставляется прямо в текст запроса и становится его частью: классический пример — кавычка и OR 1=1 в поле логина. Защита одна и простая: параметризованные запросы, где значения передаются отдельно от текста SQL и база никогда не интерпретирует их как код. ORM это делает за нас. Дополнительно — минимальные права у учётки приложения и валидация ввода. Из соседних уязвимостей стоит знать XSS, CSRF и ошибки авторизации, когда по чужому id можно получить чужие данные.
Подробный ответ
Основной ответ
Инъекция возникает при склейке SQL из строк: ввод 'admin' OR '1'='1' меняет логику запроса, а UNION SELECT вытаскивает чужие таблицы. Защита — подготовленные выражения (prepared statements): запрос с плейсхолдерами компилируется отдельно, значения передаются отдельно и всегда трактуются как данные. ORM и строители запросов используют их под капотом, но сырые строки с конкатенацией остаются дырой даже внутри ORM. Дополнительные слои: учётка приложения без DDL и доступа к чужим схемам, скрытие текстов ошибок БД от клиента, WAF как подстраховка. Важно помнить, что имена таблиц и колонок параметризовать нельзя — для динамических полей нужен белый список. Смежный минимум по OWASP API Security: broken object level authorization (IDOR), слабая аутентификация, избыточная выдача данных, отсутствие rate limiting.
Ключевые моменты
- Параметризация — не экранирование. Prepared statement разделяет план запроса и данные на уровне протокола; ручное экранирование хрупко и зависит от кодировок.
- Динамические идентификаторы. Сортировку по колонке из запроса (order_by=name) защищают белым списком допустимых значений — плейсхолдеры тут не работают.
- IDOR. GET /orders/123 без проверки владельца — самая частая дыра в API: авторизацию проверяют на каждом объекте, а не только на входе.
Практический контекст
В работе это код-ревью на сырые SQL-строки, линтеры и SAST, тесты на кавычку в полях ввода. Интервьюер на джуниорском уровне ждёт слов «параметризованные запросы» и примера атаки; на уровне выше — понимания, что инъекция бывает и в NoSQL, LDAP, командной строке, и что валидация ввода сама по себе инъекцию не закрывает. Хороший бонус — упомянуть OWASP Top 10 как чек-лист.
Частые ошибки
- Предлагают «экранировать кавычки вручную» вместо параметризации
- Считают, что ORM защищает всегда — raw-запросы с конкатенацией всё ломают
- Сводят безопасность API только к инъекциям, забывая авторизацию на уровне объектов