Код
$query = "SELECT * FROM users WHERE login='".$_GET['login"]."'";
содержит классическую уязвимость SQL-инъекции. Ниже — разбор: какие атаки возможны, к каким последствиям это может привести, конкретные способы исправления (с примерами кода) и дополнительные меры безопасности на уровне приложения и БД.

1) Каковы возможные атаки и примеры полезной полезной нагрузки

Простая обход проверки / аутентификации:
Пример payload: ' OR '1'='1
Результат: WHERE login='' OR '1'='1' — вернёт все строки, возможен обход логина.UNION-инъекция (чтение других таблиц):
Пример: ' UNION SELECT password, ... --Временные (blind) инъекции для извлечения данных:
Пример: ' OR IF(SUBSTR((SELECT password FROM users WHERE id=1),1,1)='a', SLEEP(5), 0) --Стекинг запросов (если разрешён): '; DROP TABLE users; --
Последствия: удаление таблиц, модификация данных.Запись/чтение файлов (в зависимости от СУБД): LOAD_FILE(), INTO OUTFILE() — получение файлов с сервера.Second‑order SQLi: вредоносные данные сначала сохраняются, потом используются в другом месте без параметризации.

2) Возможные последствия

Утечка конфиденциальных данных (пароли, e‑mail, PII).Полный компромисс приложения или базы данных — модификация/удаление данных.Обход аутентификации и получение прав администратора.Выполнение удалённых команд/получение файлов (в зависимости от возможностей СУБД/серверной конфигурации).Финансовые убытки, репутационные потери, штрафы за несоблюдение требований защиты данных.

3) Конкретные исправления (рекомендуется в первую очередь)

Использовать подготовленные выражения (prepared statements / parameterized queries). Ниже — примеры.

a) PDO (рекомендуемый способ)
Пример безопасного запроса:
<?php
$pdo = new PDO('mysql:host=localhost;dbname=test;charset=utf8mb4', $user, $pass, [
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES => false, // важно — использовать реальные prepares
]);
$stmt = $pdo->prepare('SELECT * FROM users WHERE login = :login');
$stmt->execute([':login' => ${}_{G}ET{[}^{\prime }logi{n}^{\prime }]]);$user = $stmt->fetch(PDO::FETCH_ASSOC);
?>

b) mysqli (подготовленные выражения)
<?php
$mysqli = new mysqli('localhost', $user,$pass, 'test');
$stmt=$mysqli->prepare('SELECT * FROM users WHERE login = ?');
$stmt->bind_param('s', $_GET['login']);
$stmt->execute();
$result=$stmt->get_result();
$row=$result->fetch_assoc();
?>

Важно: подготовленные выражения гарантируют, что введённые данные трактуются как параметры, а не как часть SQL.

4) Дополнительные меры валидации и защиты входных данных

Белый список (allowlist) допустимых значений для поля login (например, только латиница, цифры, подчёркивание).
Пример:
if (!pregmatch('/^[A-Za-z0-9]{3,30}${/}^{\prime },$_GET['login'])) {
// отклонить запрос
}Ограничение длины и форматирование (trim, mb_substr).Преобразование/нормализация данных перед использованием.Для динамических частей SQL (например, имена колонок) — не подставлять напрямую; использовать явный список допустимых значений (map).

5) Когда используют mysqli_real_escape_string / addslashes

mysqli_real_escape_string делает экранирование, но:
это менее надёжно, чем подготовленные выражения;требует правильной кодировки соединения;легко ошибиться и пропустить место подстановки.Рекомендуется как резерв только там, где нет возможности подготовить выражение, но лучше переходить на parameterized queries.

6) Другие меры безопасности на уровне приложения и БД

Принцип наименьших привилегий: учётная запись БД, которую использует приложение, должна иметь только необходимые права (напр. только SELECT/INSERT/UPDATE для конкретных таблиц; категорически не давайте CREATE/DROP/DELETE, если не нужно).Отключить поддержку множественных запросов (multi statements) в клиентской библиотеке, если не требуется.Хранение паролей: не храните пароли в открытом виде — используйте password_hash / password_verify (bcrypt/argon2).Логи и мониторинг: логировать подозрительные запросы, аномалии, задержки — и мониторить.Система обнаружения вторжений / WAF: правило для выявления SQLi (например, ModSecurity).Ограничения на уровне БД: views с ограниченным доступом, stored procedures с проверкой прав, триггеры — как доп. уровень защиты (но не заменяет параметризацию).Ограничение возврата результатов (limit), пагинация — уменьшает вред, если запрос возвращает много строк.Обработка ошибок: не выводить пользователям полные сообщения об ошибках SQL (иначе даёте подсказки атакующему).Тестирование: регулярный статический анализ кода, SAST/DAST, ручное/автоматизированное тестирование (sqlmap).Регулярные обновления: использовать актуальные версии PHP, драйверов и СУБД.

7) Примеры уязвимых и безопасных вариантов

Уязвимый:
$query = "SELECT * FROM users WHERE login='".$_GET['login']."'";Безопасный (PDO):
$stmt=$pdo->prepare('SELECT * FROM users WHERE login = ?');
$stmt->execute([$_GET['login']]);Валидация + подготовленный запрос:
$login = trim($_GET['login']);
if (!pregmatch('/^[A-Za-z0-9]{3,30}$/', $login)) { / error / }
$stmt->execute([$login]);

8) Специальные замечания

Для LIKE-запросов: нужно экранировать спецсимволы и использовать параметризацию, например: WHERE login LIKE CONCAT('%', ?, '%') в подготовленном запросе.PDO::ATTR_EMULATE_PREPARES = false — чтобы использовать настоящие подготовленные выражения драйвера, а не эмуляцию на стороне PHP.Не полагайтесь на client-side валидацию (JS) — всегда проверяйте на сервере.

9) Контрольный чек-лист для исправления данной уязвимости

[ ] Заменить конкатенацию строк в SQL на подготовленные выражения по всему коду.[ ] Ввести валидацию/нормализацию входных данных (allowlist).[ ] Ограничить права БД-учётной записи.[ ] Отключить multi‑statements, если не нужны.[ ] Хешировать пароли безопасными алгоритмами.[ ] Логи, мониторинг, WAF и тестирование на SQLi.[ ] Обработку ошибок сделать безопасной (без утечек SQL).

Если хотите, могу:

показать конкретный безопасный рефакторинг вашего условия в вашем проекте (покажите используемую библиотеку/версию PHP),или дать скрипт для автоматической проверки похожих уязвимых паттернов в кодовой базе.