Риски (при подстановке введённого email в HTML без экранирования)
- XSS (рефлекторный / хранимый / DOM): злоумышленник вводит payload вроде `">...` или `">` и скрипт выполняется в браузере жертвы — кража cookie, сессии, CSRF-перегрузки, подмена контента.
- Контекстные инъекции:
- в атрибуте (`href`, `value`, `title`) — можно закрыть кавычки и вставить атрибуты/скрипты; в `href` возможен `javascript:` или специально сформированные `mailto:` с фишинговым телом;
- в JS-коде — если email вставляют как литерал (например `var e = "USER_INPUT";`) — возможен JS-инъекшн;
- в URL/HTML-структуре — ломание DOM, подмена форм (form-jacking).
- Фишинг и UI‑подмена: отображаемый Email может ввести в заблуждение (например в списке пользователей), подменить адреса в письмах/ссылках, показать доверительный email с мусорным HTML.
- SMTP/заголовки почты: если email используется при формировании заголовков письма небезопасно, возможна инъекция заголовков (header injection).
- Логирование/поиск: незакодированные вводы в логи/отчёты могут раскрыть чувствительные данные или испортить отчёты.
- Боковые эффекты: обход ограничений браузера/фреймворка при отсутствии CSP, отсутствие HttpOnly/secure приведёт к усилению последствий XSS.
Исправления на стороне сервера (обязательные и контекстно-зависимые)
- Валидация и нормализация входа:
- проверять формат email через `filter_var($email, FILTER_VALIDATE_EMAIL)` или специализированную библиотеку; применять allowlist символов и длины; обрезать и нормализовать (например нормализация Unicode).
- отклонять либо явным образом нормализовать подозрительные значения (нулевые байты, управляющие символы).
- Выходное кодирование по контексту (главное правило):
- текстовый узел HTML: `echo htmlspecialchars($email, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');`
- HTML-атрибут: тоже `htmlspecialchars(..., ENT_QUOTES, 'UTF-8')`; дополнительно проверять отсутствие `javascript:` протокола при вставке в href.
- URL/параметр: `rawurlencode($email)` при формировании URL; для `mailto:` — разрешать только безопасные символы и %‑кодирование тела/тема.
- JavaScript-контекст: использовать `json_encode($email, JSON_HEX_TAG | JSON_HEX_APOS | JSON_HEX_QUOT | JSON_HEX_AMP)` или вывод через `json_encode()` и затем вставлять без `innerHTML`.
- CSS-контекст: избегать вставки в CSS; при необходимости использовать CSS-эскейпинг.
- Использовать фреймворки/шаблонизаторы с авто-эскейпинг (Twig, Blade) и не отключать авто-экранирование.
- Отдельно: для отправки почты — пользоваться проверенными библиотеками (PHPMailer, Symfony Mailer) чтобы избежать header injection; не конкатенировать заголовки вручную.
- Ограничения и политика: применять длину поля, whitelist доменов (если релевантно), rate‑limit на ввод, CAPTCHA для массовых попыток.
- Заголовки безопасности: Content-Security-Policy (без `unsafe-inline`/`unsafe-eval`), X-Content-Type-Options: nosniff, X-Frame-Options/SameOrigin, Strict-Transport-Security.
- Куки: HttpOnly, Secure, SameSite для снижения эффекта кражи сессии.
Исправления на стороне клиента (вспомогательные, не заменяют сервер)
- Валидация на клиенте (type="email", pattern) — удобство UX, но не безопасность.
- Никогда не вставлять пользовательский ввод через `innerHTML` — использовать `textContent` или `element.setAttribute(...)`.
- Пример: `element.textContent = userEmail;`
- Для вставки в атрибут: `link.setAttribute('href', 'mailto:' + encodeURIComponent(userEmail));` — с проверкой протокола.
- Блокировка опасных протоколов при создании ссылок (`javascript:`, `data:`).
- CSP + CSP reporting для обнаружения попыток выполнения запрещённого скрипта.
- При рендере в JS — использовать безопасное сериализованное значение с `JSON.stringify(email)` при вставке в шаблон.
Автоматические тесты и политики (CI/процессы)
- Unit-тесты:
- тесты валидации email (валидные/невалидные/угрозные строки);
- тесты функций эскейпинга: проверить, что известные XSS‑payloadы выводятся закодированными.
- Integration / E2E-тесты (headless браузер):
- сценарии: ввод злонамеренного payload в поле email, переход на страницу, проверка что скрипт не выполняется (например, payload пытается изменить DOM элемент с id, тест проверяет отсутствие изменения).
- тесты для разных контекстов (вставка в атрибут href, value, JS-контекст).
- DAST / автоматическое сканирование: OWASP ZAP, Burp в CI (регулярные сканы), автоматические сигнатуры на XSS.
- SAST: анализатор кода (PHPStan, SonarQube, RIPS, Snyk) — находить места использования `echo`/`print`/`innerHTML` без эскейпинга.
- Линтеры и правила в кодбазе: правило/PR‑чеклист запрещает использовать `innerHTML`, `eval`, небезопасные шаблоны; ревью чеклист для вывода пользовательского ввода.
- Регрессионные тесты: набор известных payload‑ов (OWASP XSS cheat sheet) прогонять в CI и контролировать отсутствие исполнения.
- Фаззинг и mutation‑testing: генерация случайных и специально сконструированных вводов.
- Мониторинг и инцидент-реакция:
- CSP report-uri / reporting API для выявления блокированных попыток;
- логирование подозрительных вводов, алерты при аномалиях;
- WAF с правилами на XSS / header injection как защитный слой.
- Политики разработки:
- secure-by-default шаблонизаторы, обязательное кодирование по контексту;
- обучение разработчиков и чек-листы PR;
- регулярные pentest/ревью безопасности и обновление зависимостей.
Краткие примеры (PHP)
- безопасный вывод в HTML: `echo htmlspecialchars($email, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');`
- безопасная вставка в JS: `?>const email = ;<?php`
- в URL/mailto: `$safe = rawurlencode($email); $href = 'mailto:' . $safe;`
Итог: первоочередная мера — выходное кодирование по контексту + строгая серверная валидация/нормализация; дополнительно — шаблонизатор с автo‑эскейпингом, CSP, тесты (unit, E2E, DAST, SAST), политики код‑ревью и мониторинг.