Проанализируйте уязвимость в PHP-подобном примере: $query = "SELECT * FROM users WHERE name = '$name'"; $result = mysqli_query($conn, $query); — опишите возможные атаки, проиллюстрируйте реальные эксплуатационные сценарии и предложите набор мер по защите (парадигмы защиты, конкретные приёмы, проверки и изменения архитектуры)

5 Ноя в 15:03
3 +3
0
Ответы
1
Коротко: в строке
$query = "SELECT * FROM users WHERE name = '$name'";
есть классическая SQL‑инъекция — пользовательский ввод вставляется в запрос без параметризации и проверки. Ниже — возможные атаки, реальные сценарии эксплуатации и конкретные меры защиты.
Что может быть использовано 공격ом
- SQL‑инъекция (вставка произвольного SQL) — получение/модификация данных, обход аутентификации, удаление таблиц.
- Блайнд‑инъекция (boolean / time‑based) — извлечение конфиденциальных данных побуквенно.
- Union‑/error‑based эксфильтрация — вытянуть столбцы через UNION или вызвать ошибку с содержимым.
- Stacked queries (если СУБД и драйвер поддерживают) — выполнение нескольких команд (DROP, INSERT).
- Second‑order injection — ввод сохраняется безопасно, затем используется в другом контексте уязвимо.
- Логическая инъекция в бизнес‑правила (например, подмена параметра поиска для обхода фильтров).
Примеры полезных полезных полезных полезных полезных полезных нагрузок (payload)
- Быстрый обход фильтра/аутентификации:
name = ' OR '1'='1
(в оригинальном запросе даст: SELECT * FROM users WHERE name = '' OR '1'='1')
- Извлечение через UNION:
name = ' UNION SELECT username, password FROM users --
- Time‑based блайнд (проверка символа пароля):
name = ' OR IF(SUBSTRING(password,111,111) = 'a', SLEEP(555), 0) --
(анализ происходит по задержке ответа)
- Stacked (если разрешено):
name = ' ; DROP TABLE users; --
Реальные эксплуатационные сценарии
- Брутфорс/автоматизация: сканеры (sqlmap) автоматически подбирают и извлекают таблицы, колонки, значения.
- Обход авторизации: форма поиска/вход использует тот же фрагмент — злоумышленник получает список пользователей, или логин проходит как любой пользователь.
- Экспфильтрация конфиденциальных данных: экспорт пассов/почт/карточных данных через UNION или последовательные запросы.
- Подрыв целостности/доступности: удаление таблиц, внедрение фальшивых записей, создание бекдоров в БД (UDF/файлы), если привилегии широкие.
Набор мер по защите (парадигмы + конкретные приёмы)
1) Парадигма: параметризация запросов (prepared statements)
- Всегда использовать подготовленные выражения с параметризацией, а не конкатенацию. Пример mysqli:
$stmt = mysqli_prepare($conn, "SELECT * FROM users WHERE name = ?");
mysqli_stmt_bind_param($stmt, "s", $name);
mysqli_stmt_execute($stmt);
$result = mysqli_stmt_get_result($stmt);
- PDO с PDO::prepare / bound parameters — предпочтительнее.
2) Парадигма: принцип наименьших привилегий
- Для приложения создать отдельного пользователя БД с правами только на необходимые операции (обычно SELECT/INSERT/UPDATE для конкретных таблиц). Исключить право DROP, CREATE, FILE, SUPER и т.д.
3) Парадигма: валидация и белые списки
- Ограничить формат входа: длину, допустимые символы (например, имя — только буквы/цифры/дефис). Белые списки безопаснее черных.
- Устанавливать максимальную длину (например, поле name max 100100100 символов).
4) Парадигма: экранирование как запасной вариант
- mysqli_real_escape_string только если невозможно использовать prepared statements; не полагаясь на него как на единственную защиту.
5) Парадигма: многослойная защита (defense in depth)
- WAF/IPS для блокировки известных паттернов SQLi.
- Ограничение частоты запросов, капча на подозрительных формах.
- Логи запросов и IDS/алерты на аномалии (много длинных запросов/много 5xx/много медленных ответов).
6) Конфигурационные меры
- Отключить поддержку многозапросов/stacked queries в драйвере, если не нужна.
- Ограничить подробность ошибок клиенту — не показывать стек/SQL‑тексты.
- Использовать TLS, защиту от MITM (не относ directly to SQLi, но важно).
7) Архитектурные изменения
- Разделение слоёв: валидация на API‑слое, бизнес‑логика в сервисах, доступ к данным через слой с подготовленными запросами/ORM.
- Использовать ORM/QueryBuilder с встроенной параметризацией (Eloquent, Doctrine etc.).
- Хранение чувствительных данных (пароли) только в хешированном виде (bcrypt/argon2) — даже если украдут таблицу, пароли безопаснее.
Проверки и тестирование
- Code review и статический анализ (SAST) на шаблоны конкатенации SQL.
- DAST / автоматические сканеры и специализированные инструменты (sqlmap, Burp) — тесты на проде только в контролируемой среде.
- Unit/integration тесты покрывают сценарии ввода с мета‑символами.
- Fuzzing полей формы.
Краткий список действий для исправления данного кода (минимум шагов)
- Заменить конкатенацию на prepared statement (см. пример выше).
- Ограничить DB‑user права.
- Ввести валидацию и ограничение длины поля.
- Логи и мониторинг на аномалии/медленные ответы (для блайнд‑атак).
Если нужно, могу прислать готовые исправления кода на mysqli и PDO, шаблоны политик прав БД и примеры тестовых payloadов для безопасного тестирования.
5 Ноя в 15:37
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Прямой эфир