Код
$query = "SELECT * FROM users WHERE id=".$_GET$${}^{\prime }i{d}^{\prime }$$;
— является типичным примером небезопасной генерации SQL и открывает много векторов атак и утечек. Ниже — полный разбор уязвимостей, практические безопасные шаблоны реализации и архитектурные меры с оценкой ограничений.

1) Какие уязвимости и риски здесь возможны

Классическая SQL‑инъекция
Примеры полезных полезов: id=1 OR 1=1 — вернёт все записи; id=1 UNION SELECT ... — получить другие колонки/таблицы; id=1; DROP TABLE users — при разрешённых многозапросных выполнениях $mysql{i}_{m}ult{i}_{q}uery$ — удаление таблицы.Виды: error‑based, boolean‑based, time‑based, UNION‑based, stacked queries, out‑of‑band $DNS/HTTPexfiltrationприналичиифункций/расширений$.Инъекция типов / неявные преобразования
Если ожидался integer, но передаётся строка, конкатенация формирует валидный SQL $id{=}^{\prime }1OR1=1^{\prime }илиid{=}^{\prime }{0}^{\prime }O{R}^{\prime }{a}^{\prime }{=}^{\prime }{a}^{\prime }$, что даёт инъекцию.Проблемы с различными кодировками/charset и экранированием $например,UTF‑8/utf8mb4особенности$, многобайтовые символы.Вторичные $second‑order$ инъекции
Если вредоносная строка сохранена в БД и позже используется для формирования SQL без параметризации — повторная инъекция.Утечка данных
SELECT * возвращает все колонки $включаяpasswor{d}_{h}ash,email,PII$.Ошибки СУБД в ответе $stacktrace,SQLошибки$ раскрывают структуру схемы и версию СУБД.С помощью error‑based или information_schema можно вытянуть структуру БД и данные.Разграничение привилегий
Если DB‑учётка имеет слишком широкие права (DROP, SELECT на все таблицы, LOAD_FILE, FILE, >), успешная инъекция может привести к утечке файлов, удалению, исполнению out‑of‑band exfil.Логирование/инцидент
Неудалённые логи с чувствительной информацией $полныеSQL‑запросыспараметрами$ могут утекать.Другие векторы
XSS/CSRF не прямо связаны, но если вывод данных не экранируется, данные из DB могут привести к XSS.Инъекции в части, которые нельзя параметризовать $именастолбцов/таблиц,ORDERBY,LIMIT$ — если формируются динамически без allow‑list.

2) Практические безопасные шаблоны $PHP+MySQL$ — что делать обязательно

Всегда использовать параметризованные запросы $preparedstatements$. Ни в коем случае не конкатенировать пользовательский ввод в SQL.
PDO $рекомендуется$:
Пример безопасно:
$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT);
if ($id === false || $id === null) { / 400 / not found / }
$stmt = $pdo->prepare('SELECT id, username, email FROM users WHERE id = :id LIMIT 1');
$stmt->bindValue(':id', $id, PDO::PARAM_INT);
$stmt->execute();
$user = $stmt->fetch();mysqli:
$id = filter_input$INPU{T}_{G}ET{,}^{\prime }i{d}^{\prime },FILTE{R}_{V}ALIDAT{E}_{I}NT$;
$stmt=$mysqli->prepare${}^{\prime }SELECTid,username,emailFROMusersWHEREid=?LIMIT{1}^{\prime }$;
$stmt->bind_param('i', $id);
$stmt->execute;Явная валидация / allow‑list
Проверяйте типы и диапазоны: id должен быть положительным целым, в пределах ожидаемого $например,\mathrm{1..}{2}^{3}1-1$.Используйте filter_input с FILTER_VALIDATE_INT или ctype_digit после trim. Не полагайтесь только на $int$ cast — он «съедает» строки и может скрыть злоупотребление.Минимизация возвращаемых данных
Не использовать SELECT * — перечисляйте только нужные колонки.LIMIT 1, если ожидается одна строка.Ограничение прав БД
Для веб‑приложения используйте отдельного DB‑пользователя с минимальными правами $толькоSELECT/INSERT/UPDATEдлянужныхтаблиц$. Не давайте DROP, FILE, SUPER и т. п.Обработка ошибок и логирование
Не показывайте SQL‑ошибки пользователю. Логируйте в защищённые логи $безпаролей,безконфиденциальныхPII$.Подготовленные выражения на уровне ORM
Используйте ORM/Query Builder, которые по умолчанию параметризуют запросы $нопроверяйте,чтовыневставляетестрокичерезrawSQL$.Экранирование идентификаторов через allow‑list
Если нужно динамически выбирать столбец для ORDER BY, используйте allow‑list $массивдопустимыхимёнстолбцов$ и не подставляйте напрямую пользовательский ввод.HSTS, TLS
Шифруйте соединение к БД и между клиентом/сервером $HTTPS$.Защита на уровне приложения
Rate limiting, блокировка подозрительных последовательностей запросов, CAPTCHA при подозрении на автоматизацию.WAF / DB‑файрвол
WAF может блокировать простые шаблоны SQLi, но не заменяет parameterized queries.Обновление/патчи
Держите СУБД и драйвера в актуальном состоянии.

3) Примеры «плохого» и «хорошего» кода $коротко$

Плохо:
$query = "SELECT * FROM users WHERE id=".$_GET$${}^{\prime }i{d}^{\prime }$$;Лучше $PDO,подготовка+валидация,явныеполя$:
$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT);
if ($id === false || $id === null) { http_response_code(400); exit; }
$stmt = $pdo->prepare('SELECT id, username, email FROM users WHERE id = :id LIMIT 1');
$stmt->bindValue(':id', $id, PDO::PARAM_INT);
$stmt->execute();
$user = $stmt->fetch(PDO::FETCH_ASSOC);

4) Архитектурные меры и модель угроз

Определите модель угроз: кто атакует, какие у них возможности, какие активы защищаем
Примеры активов: PII пользователей, пароли/хэши, финансовые данные, конфигурации.Атакующие: а) внешний анонимный, б) аутентифицированный пользователь, в) внутренний сотрудник, г) компрометированный сервер.Входные точки: GET/POST, cookies, заголовки, файлы, 3rd‑party интеграции, админ интерфейс, API.Возможные последствия: массовая утечка данных, разрушение данных, получение доступа к файлам/операционной системе.Меры:
Защита на уровне кода (обязательная parameterization + валидация).Разделение прав (минимальные права для БД).Контроль доступа / RBAC на уровне приложения и таблиц.Сетевые сегменты: доступ к БД только из приложенческого слоя, не из интернета.Мониторинг и детекция аномалий (IDS/IPS, логирование запросов, alerting при всплесках SELECT * или большого количества ошибок).Резервное копирование и план восстановления.Ревью кода и автоматические SAST тесты (инструменты поиска SQLi).Регулярные Pentest / Bug bounty.WAF как дополнительный слой (но воспринимать как вспомогательный).Data Loss Prevention (DLP) / ограничение вывода крупных наборов данных.Шифрование чувствительных полей в БД и токенизация.Secrets management: не хранить пароли/ключи в репозитории; rotate credentials.

5) Особые случаи и ограничения защит

Параметризованные запросы не позволяют параметризовать идентификаторы (имена таблиц/столбцов), для этого нужен allow‑list.WAF может блокировать только известные паттерны — sophisticated payloads и multi‑stage attacks могут его обойти.Валидация может быть ошибочной: белые списки лучше чёрных; фильтры могут некорректно обрабатывать разные кодировки.Prepared statements защищают от SQLi, но не от логических ошибок в приложении (например, неправильная проверка прав доступа).Минимизация привилегий может усложнить операции администрирования и потребовать архитектурных изменений (например, отдельные учетные записи для репликации/backup).Логирование SQL‑запросов с параметрами может раскрывать конфиденциальные данные в логах — нужно балансировать между forensics и безопасностью логов (маскировать чувствительное).Вторичные инъекции: данные, сохранённые в БД, при последующем использовании должны всегда обрабатываться снова как потенциально опасные.Legacy code: заменять все небезопасные места может быть дорого; план поэтапного исправления с тестами обязателен.

6) Практический чек‑лист для команды (кратко)

[ ] Везде заменить конкатенацию пользовательского ввода на подготовленные выражения.[ ] Добавить валидацию входных данных (тип/диапазон/regex/allow‑list).[ ] Пересмотреть SELECT * — перечислить колонки.[ ] Проверить права БД — создать минимальную роль для приложения.[ ] Отключить многозапросное выполнение, если не нужно.[ ] Убрать показ SQL‑ошибок пользователям; централизованно логировать.[ ] Настроить WAF/IDS и мониторинг аномалий.[ ] Регулярные ревью и тесты (SAST, DAST, pentests).[ ] План восстановления/бэкапы и ротация секретов.

7) Заключение — что делать прямо сейчас (практический минимум)

Немедленно заменить текущую строковую конкатенацию на параметризованный запрос + проверить валидацию id.Ограничить DB‑учётку приложению минимальными правами.Заменить SELECT * на явный список колонок и добавить LIMIT 1 при обращении по id.Отключить вывод SQL‑ошибок в ответе пользователю и настроить логирование.Планировать WAF/мониторинг и pen‑test как дополнительные уровни защиты.

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

показать готовые примеры для PDO и mysqli (с обработкой ошибок и логикой 404),составить Threat Model (STRIDE/OWASP) и конкретный план поэтапного исправления для вашего кода/инфраструктуры,проверить другие места приложения на похожие уязвимости.

Какой вариант предпочитаете?