Выполняю только ответ на вопрос — кратко, по шагам с пояснениями.
1) Анализ (как найти уязвимость)
- По коду: ищите конкатенацию входных данных в SQL, например строка
$q="SELECT\ast FROMusersWHERElogin{=}^{\prime }".\_POST{[}^{\prime }logi{n}^{\prime }].{"}^{\prime }";$.
Проверяйте все места, где используется \($_GET, $_POST, $_REQUEST, cookies, headers\).
- Статический анализ: запустите SAST (PHPStan/Exakat/SonarQube) и настроенные правила на поиск конкатенации в SQL-вызовах (mysqli->query, PDO->query, прямые mysql_query).
- Поиск в репозитории: grep/IDE-поиск по шаблонам вида "query(", ".\".\", mysql_query" и использованию пользовательских данных.
- Архитектура и права: определите уровень привилегий БД, используются ли ORM/пул соединений, есть ли централизованная работа с БД.
2) Доказательство наличия (без вреда, в авторизованной/тестовой среде)
- Не тестируйте на продакшне. Подготовьте изолированную копию БД и приложения.
- Документируйте доказательства через код-ревью: укажите файл, строку, показ конкатенации (скрин/фрагмент кода) — это достаточное доказательство плохой практики.
- Для динамической проверки используйте безопасные инструменты в тестовой среде: DAST-сканер с режимом «non-destructive» или специализированный сканер SQLi в тестовой среде. Результат — отчет сканера и лог веб-сервера/БД.
- Для воспроизведения показывайте отличие поведения при корректных и некорректных вводах в тестовой среде и логи запросов БД (без эксплойтов на живых данных).
3) Смягчение уязвимости (конкретные меры)
- Применить параметризованные запросы / подготовленные выражения. Пример в PDO:
$pdo = new PDO(...);
$stmt = $pdo->prepare("SELECT * FROM users WHERE login = :login");
$stmt->execute([':login' => $login]);
- Для mysqli:
$stmt = $mysqli->prepare("SELECT * FROM users WHERE login = ?");
$stmt->bind_param("s", $login);
$stmt->execute();
- Использовать ORM или query builder, которые по умолчанию параметризуют запросы.
- Валидация и белые списки: проверять формат логина (регулярные выражения), длину, запрещённые символы — но не как основную меру защиты от SQLi.
- Минимальные права в БД: учётная запись приложения должна иметь только нужные привилегии (SELECT/INSERT/UPDATE/DELETE по необходимым таблицам).
- Логирование и мониторинг: логировать аномальные запросы, настраивать оповещения по всплескам ошибок/ошибочных запросов.
- WAF как дополнительный слой (не замена параметризованным запросам).
- Регулярные обновления и библиотеки, отказ от устаревших mysql_* функций.
4) Внедрение процесса тестирования безопасности (процедуры)
- Политика и правовое: тестирование только с разрешения, фиксация границ тестовой среды.
- Включить SAST в CI: каждый PR должен проходить статический анализ; блокировать мердж при обнаружении критичных правил (конкатенация пользовательских данных в SQL).
- DAST в staging: регулярные автоматические сканы (nightly) и перед релизом.
- Модульные/интеграционные тесты безопасности: имитировать некорректные входы в тестовой БД и проверять, что код использует параметризованные запросы.
- Ротация секретов и проверка состава зависимостей (SCA).
- План реакций: регистрировать уязвимости, назначать ответственных, сроки исправлений, подтверждение исправления повторными тестами.
- Периодические ручные pentest'ы и code review security-focused (минимум ежегодно или перед крупными релизами).
- Обучение разработчиков: безопасные практики работы с БД и ревью PR на предмет уязвимых шаблонов.
Краткий чек-лист для быстрой проверки кода
- Нет конкатенации пользовательских данных в SQL.
- Все SQL-запросы — через подготовленные выражения/ORM.
- Ограниченные привилегии БД.
- SAST/DAST в пайплайне и тестовая среда для любых динамических тестов.
Если нужно, могу прислать образцы конфигураций SAST/DAST-проверок или шаблоны CI-правил для блокировки unsafe-запросов (в тестовой/защищённой форме).