SQL-инъекция (SQLi)
Вulnerable пример (PHP, mysqli, небезопасная конкатенация):
<?php
$id = $_GET['id']; // например "0 OR 1=1"
$sql = "SELECT * FROM users WHERE id = $id";
$result = $mysqli->query($sql);
while ($row = $result->fetch_assoc()) {
echo $row['username'];
}
?> Механизм атаки: при запросе вроде `/user.php?id=0+OR+1=1` строка запроса становится `"SELECT * FROM users WHERE id = 0 OR 1=1"`, что возвращает все записи — злоумышленник управляет синтаксисом SQL. (пример логического выражения: $1=1$).
Исправление (PDO + подготовленные выражения):
<?php
$id = $_GET['id'];
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");
$stmt->execute([':id' => $id]);
while ($row = $stmt->fetch()) {
echo htmlspecialchars($row['username'], ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
}
?> Комментарий: подготовленные выражения отделяют структуру запроса и данные — любые метасимволы в параметре интерпретируются как данные, а не как часть SQL.
Доп. меры защиты (сервер):
$1$ Использовать параметризованные запросы или ORM.
$2$ Проверять и принудительно приводить типы (напр., $(int)$ для id) — но не как единственная мера.
$3$ Минимизировать привилегии БД (учётная запись с правами только на нужные операции).
$4$ Логи и мониторинг аномалий (необычные длинные входные строки, повторные ошибки).
$5$ WAF/фильтры на уровне приложения как дополнительный слой.
$6$ Ограничение выдачи ошибок клиенту (не раскрывать текст SQL/стек).
XSS (reflected и stored)
Reflected (прямой) XSS — пример (PHP):
<?php
// /search.php?q=helloalert(1) $q = $_GET['q'];
echo "Результаты для: $q";
?> Здесь при запросе `?q=alert(1)` скрипт выполняется в браузере жертвы (пример alert: $1$). Это reflected XSS — полезная нагрузка приходит в URL и немедленно отражается.
Stored XSS — пример (комментарии):
- Пользователь отправляет комментарий `fetch('/cookie').then(...)`; комментарий сохраняется в БД; при отображении на странице всем посетителям скрипт исполнится.
Защита от XSS (многоуровневая)
Клиент (браузер/фронтенд):
$1$ Никогда не вставлять пользовательский HTML через `innerHTML`. Использовать `textContent` / `value` или шаблонизацию, которая кодирует выход.
$2$ Для случаев, где нужно разрешить часть HTML — применять проверенные библиотеки, например DOMPurify, и конфигурировать белый список тегов/атрибутов.
$3$ Content Security Policy (CSP): ограничить источники скриптов, стилей, включить `script-src 'self'` и по возможности `nonce`/`hash`-политику.
$4$ Использовать встроенные механизмы фреймворков (React, Vue) — они экранируют данные по умолчанию.
Сервер:
$1$ Всегда кодировать выход (output encoding) согласно контексту: HTML-экранирование, атрибут, JavaScript-литерал, URL-энкодинг. В PHP: `htmlspecialchars($s, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8')`.
$2$ Валидировать и нормализовать вход (whitelist вместо blacklist), но не полагаться на это как единственную меру.
$3$ При необходимости сохранять HTML — хранить как чистый (санитизированный) HTML и повторно очищать при выводе.
$4$ HTTP-only и Secure для куки, SameSite по возможности.
$5$ Установить заголовки: `Content-Security-Policy`, `X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY`/SAMEORIGIN, `Referrer-Policy`.
$6$ Логи и обнаружение аномалий.
Скратч-лист защиты (общее, defense-in-depth)
$1$ Отделять данные от кода: параметризованные запросы для SQL, экранирование для вывода в HTML/JS/CSS/URL.
$2$ Валидировать вход по белому списку и нормализовать.
$3$ Минимизировать привилегии сервисов (БД, файлы).
$4$ CSP и безопасные заголовки.
$5$ Использовать проверенные библиотеки (DOMPurify, ORM, подготовленные выражения).
$6$ Логи, мониторинг, тестирование (автоматические сканеры, код-ревью, регулярные пентесты).
$7$ Обновления зависимостей и патчинг.
Краткий вывод: главная идея — разделять код и данные (параметры в SQL, экранирование при выводе), использовать защиту на нескольких уровнях (клиент, сервер, инфраструктура), и не полагаться на одну технику.