Кейс (PHP + SQL): найдите уязвимость и исправьте её в коде, который формирует SQL-запрос из пользовательского ввода: $query = "SELECT * FROM users WHERE name = '".$_GET['name']."'"; $res = mysqli_query($conn, $query); — какие угрозы существуют и как их нейтрализовать?

14 Ноя в 10:32
2 +1
0
Ответы
1
Уязвимость: прямое встраивание пользовательского ввода в SQL-запрос — SQL‑инъекция. В коде
$query = "SELECT * FROM users WHERE name = '".$_GET['name']."'";
пользователь может подставить строку с SQL‑контентом (например `' OR '1'='1`), что изменит логику запроса.
Какие угрозы:
- несанкционированный доступ к данным / утечка (SELECT с UNION, error‑based, blind/time‑based),
- изменение или удаление данных (INSERT/UPDATE/DELETE или при поддержке мультизапросов),
- обход аутентификации (логические инъекции),
- эскалация привилегий / выполнение нежелательных команд через уязвимые функции,
- вторичные/second‑order инъекции при повторном использовании данных.
Как нейтрализовать (рекомендации, по приоритету):
1) Параметризованные запросы (prepared statements) — основной и безопасный метод.
Пример с mysqli:
$stmt = $conn->prepare("SELECT * FROM users WHERE name = ?");
$stmt->bind_param("s", $_GET['name']);
$stmt->execute();
$res = $stmt->get_result();
Пример с PDO:
$stmt = $pdo->prepare("SELECT * FROM users WHERE name = :name");
$stmt->execute([':name' => $_GET['name']]);
$result = $stmt->fetchAll();
2) Установка корректной кодировки соединения:
mysqli_set_charset($conn, 'utf8mb4');
(важно, чтобы mysqli_real_escape_string работал корректно при fallback'е).
3) Валидация и ограничение входных данных:
- whitelist (регулярные выражения) для допустимых символов,
- длина: например обрезать до 100100100 символов: $name = mb_substr($_GET['name'], 0, 100);
Пример валидации:
if (!preg_match('/^[\p{L}\d\s\-_]+$/u', $name)) { /* reject */ }
4) Если по какой‑то причине нельзя использовать prepared statements — экранировать:
$name = mysqli_real_escape_string($conn, $_GET['name']);
$query = "SELECT * FROM users WHERE name = '$name'";
(но это уступает prepared statements и требует правильной кодировки).
5) Минимизация прав БД: аккаунт приложения должен иметь только необходимые привилегии (например только SELECT для чтения).
6) Дополнительно: логирование подозрительных запросов, защита от вторичных инъекций (очищать и при хранении, и при последующем использовании), использование WAF при необходимости.
Короткая проверка для числовых параметров (без SQL‑инъекции):
$id = (int)$_GET['id'];
$query = "SELECT * FROM users WHERE id = $id"; // безопасно для целых, но prefer parameterize
Итог: используйте подготовленные выражения + правильную кодировку + валидацию/ограничение входа и минимальные привилегии — это нейтрализует основную угрозу SQL‑инъекций.
14 Ноя в 10:40
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Прямой эфир