Ребят, пару лет назад в одном проекте, с которым работал, была старая SQL-инъекция через один из параметров, баг работал без проблем. Сейчас глянул свежую версию сайта – этих дыр уже нет, код поправили, запросы с подготовленными выражениями сделали. Вроде всё чётко теперь. Я раньше пробовал разными спсообами проверять, типа запускал скрипты с payload’ами через Burp Suite, и именно старый вариант запроса спокойно отрабатывал в уязвимость, пока они не переделали всю работу с БД.

Потом, чтобы убедиться, что не появилось чего-то нового, прокатился по всему API с sqlmap, но результаты у меня вызывают скепсис. Сканер ругается на пару эндпойнтов с непонятными False Positive, и какие-то нестандартные параметры вроде JSON body обрабатываются странно – похоже, в новых местах применили другие проверки. Но я не настолько уверен, что закрыл вопрос полностью, потому что в любой момент могут внедриться новые дырки из-за изменения бизнес-логики или сторонних библиотек. Лично я теперь почти всегда на проекте пилию Unit/Integration тесты с фокусом на злых данных и следом manually проверяю, чтобы не всплыли старые косяки.

Кстати, ещё была идея прицепить какой-нибудь WAF с кастомными правилами на парсинг запросов, чтобы отлавливать хоть что-то на входе, но с ним постоянно колхозить приходится, чтобы не рубить легитимные данные. И сомневаюсь, что комплексный подход с подготовленными выражениями и WAF сработает навсегда, потому что баги постоянно переезжают в новые нюансы. В общем, исправить SQL-инъекцию – не проблема, а вот гарантировать, что она никогда больше не появится, в реальных условиях почти невозможно.