Кратко — уязвимость: SQL‑инъекция. В строке
$q = "SELECT * FROM users WHERE name = '".$_GET$${}^{\prime }nam{e}^{\prime }$$."'";
пользовательский ввод ($_GET['name']) напрямую конкатенируется в SQL-запрос без очистки или параметризации, поэтому злоумышленник может подделать запрос.

Какие атаки возможны $примерыполезныхполезадов$:

Простая логическая инъекция $авторизация/доступкданным$:
name=' OR '1'='1
=> WHERE name = '' OR '1'='1' — вернутся все записи.UNION‑инъекция $получениедополнительныхколонок$:
name=' UNION SELECT email, password FROM secrets --
$потребуетсяподобратьчислоитипыколонок$.Stacked queries $многозапросность$:
name='; DROP TABLE users; --
$вMySQLмногозапросывыполняютсяприиспользованиисоответствующихAPI/флагов—ноеслионивключены,можновыполнятьдополнительныекоманды$.Blind $слепая$ / временная инъекция для извлечения данных по битам/символам:
name=' OR IF$SUBSTRING((SELECTpasswordFROMusersWHEREname{=}^{\prime }admi{n}^{\prime }),1,1){=}^{\prime }{a}^{\prime },SLEEP(5),0$ --
— если сервер «задерживается», можно узнать символы пароля.Error‑based: специально вызвать ошибку и вывести содержимое через текст ошибки.

Последствия: утечка конфиденциальных данных $логины/пароли$, обход авторизации, уничтожение или изменение данных, получение управления БД/цепочки атак внутри сети.

Как защищаться — многоуровнево $defenseindepth$:

1) Подготовленные выражения $parameterizedqueries$ — основной способ предотвратить SQL‑инъекции:

Пример с MySQLi $рекомендованный$:
$stmt=$db->prepare${}^{\prime }SELECTid,name,emailFROMusersWHEREname={?}^{\prime }$;
$stmt->bind_param('s', $_GET['name']);
$stmt->execute;
$result=$stmt->get_result;Пример с PDO:
$stmt=$pdo->prepare${}^{\prime }SELECTid,nameFROMusersWHEREname=:nam{e}^{\prime }$;
$stmt->execute(['name' => $_GET['name']]);
$rows = $stmt->fetchAll();
Преимущество: драйвер отделяет структуру SQL от данных, значения не интерпретируются как SQL.

2) Валидация и нормализация входа:

Белый список допустимых значений там, где возможно (например, имена, ID, перечисления).Регулярные выражения и длина: например, допустимы только буквы/цифры и ограничение длины.Нормализация кодировок и использование set_charset('utf8mb4') для соединения — предотвращает обходы через мультибайтовые кодировки.

3) Экранирование как запасной вариант:

mysqli_real_escape_string() — работает, но менее надежно, чем параметризованные запросы, и чувствительно к настройкам кодировки.
$name = mysqli_real_escape_string($db, $_GET['name']);
$q = "SELECT ... WHERE name = '$name'";

4) Ограничение привилегий $принципнаименьшихпривилегий$:

Пользователь БД, от имени которого выполняется веб‑приложение, должен иметь минимально необходимые права: обычно SELECT $итольконанужныетаблицы/колонки$. Не давать DROP, DELETE, ALTER, GRANT и т.п., если они не нужны.Разделение ролей: один пользователь для чтения, другой — для администрирования.

5) Закрытие возможности выполнения нескольких запросов:

Не допускайте использование multi‑statement, если не нужно. В PDO можно отключить эмуляцию и т. п.; в MySQLi — не использовать mysqli_multi_query и не включать соответствующие клиентские флаги.

6) Не позволять параметризовать идентификаторы:

Подставлять имена таблиц/столбцов через параметры нельзя. Для таких случаев используйте белые списки допустимых идентификаторов и строгую проверку.

7) Обработка ошибок и логирование:

Не показывайте пользователю подробные SQL‑ошибки $этооблегчаетerror‑basedинъекции$. Логи ошибок сохраняйте и анализируйте.Мониторьте аномальные запросы, медленные запросы и повторные неудачные попытки $IDS/WAF$.

8) Дополнительные слои защиты:

Веб‑файервол $WAF$ — может блокировать типичные payload'ы, но не заменяет безопасное кодирование.Ограничение частоты запросов, капча для подозрительных сценариев.Хранение конфиденциальных данных в хешированном/шифрованном виде $например,пароли—passwor{d}_{h}ash$.Использование ORM или проверенных библиотек, которые по умолчанию параметризуют запросы.

9) Защита от вторичных инъекций:

Вторичные $second‑order$ – когда неочищенные данные сохраняются и используются в другом контексте позже. Всегда параметризуйте запросы при их формировании, а не надеяться на раннюю очистку.

10) Безопасность на уровне БД/сети:

Отключите удалённый доступ к базе, используйте firewall, bind-address, chroot/контейнеризацию, шифрование каналов $TLS$.Регулярные обновления СУБД и библиотек.

Короткий пример безопасного варианта $MySQLi$:
$db->set_charset('utf8mb4');
$stmt = $db->prepare('SELECT id, name, email FROM users WHERE name = ? LIMIT 1');
$stmt->bind_param('s', $_GET['name']);
$stmt->execute();
$res = $stmt->get_result();

Итого: самая серьёзная уязвимость — SQL‑инъекция. Правильный базовый ответ — использовать подготовленные выражения + валидация входа + принцип наименьших привилегий + дополнительные слои (экранирование как запасной вариант, WAF, логирование, ограничение многозапросности, запрет вывода ошибок пользователю).