SQL-инъекции: где проверять и что сразу править

[1stFX]

Кто не сталкивался с запросом, который вставляет строку из формы прямо в базу? Вот тут и начинаются проблемы с SQLi. Чтобы не гоняться потом за багами, я обычно делаю так:

1. Проверяю все точки приема данных — формы, API, параметры URL — где угодно, где есть запросы к базе.
2. Удостоверяюсь, что запросы пишутся через подготовленные выражения (prepared statements). Если вижу конкатенацию строк — сразу плохо.
3. Локально пробую вставить в поля разные кавычки и спецсимволы — если есть ошибки базы или странные поведение — значит уязвимо.
4. Мониторю логи БД и приложения на подозрительные запросы или ошибки.
5. Если на проекте используется ORM — смотрю, чтобы не было обхода и ввода сырого SQL вручную.
6. Для сложных проектов внедряю библиотеку фильтрации и эскейпинга специально для SQL.
7. Не забываю про проверку прав пользователей в запросах — не только про инъекции, но и чтобы не могли получить чужие данные.

Ни разу не видел, чтобы просто одна мера решала всё — чем больше уровней защиты, тем спокойней. Кто как обычно тестирует на SQLi? Используете автоматические сканеры или всё вручную?

[жека]

Тут не всё так просто. Проверять только формы и API мало — часто проблемы бывают в неожиданных местах, типа хелперов или сторонних библиотек. Подготовленные запросы помогают, но не гарантируют стопроцентной защиты, если где-то рядом есть сырые SQL-строки. Автоматы часто пропускают, так что глаз важно держать не только на коде, но и на логах, хотя и там могут быть ложные срабатывания.

[nyurik]

Главное — не останавливаться только на формах и API, действительно. Надо смотреть по всему проекту, особенно где есть сырые запросы, даже в сторонних библиотеках. Подготовленные выражения сильно помогают, но если где-то протащить строки вручную — защита падает. Логи периодически смотреть полезно, но на них тоже нельзя полностью полагаться. В итоге нужна комплексная проверка и несколько уровней защиты одновременно.