Сравните проверку входных данных и контекстное экранирование как защиты от XSS: какой механизм должен остановить выполнение пользовательского значения в HTML-атрибуте?
Основной защитой в HTML-атрибуте должно быть контекстное экранирование при выводе: специальные символы пользовательского значения превращаются в безопасное текстовое представление именно для контекста атрибута. Проверка входных данных может уменьшить набор допустимых значений, но сама по себе не гарантирует безопасность, поскольку вредоносная интерпретация возникает в момент вывода.
XSS стал следствием того, что веб-приложения начали смешивать пользовательские данные с HTML, JavaScript и другими языками, которые браузер интерпретирует как код. Изначально разработчики часто доверяли данным после поверхностной проверки или пытались удалять отдельные опасные фрагменты.
Такой подход оказался ненадёжным: безопасность зависит не только от значения, но и от места, куда оно вставляется. Поэтому сформировался принцип экранировать данные на границе вывода с учётом контекста.
Одно и то же значение может быть безопасным в обычном HTML-тексте, но опасным внутри атрибута, JavaScript-кода, CSS или URL. Например, символы кавычек особенно важны внутри атрибута: без экранирования они могут завершить значение атрибута и изменить структуру документа.
Неверное решение позволяет внедрить разметку или сценарий в страницу. Последствия зависят от контекста и полномочий пользователя: кража данных из страницы, выполнение действий от имени жертвы, подмена интерфейса или фишинг.
Проверка входных данных отвечает на вопрос, соответствует ли значение бизнес-правилам: например, является ли имя допустимым идентификатором. Она полезна для снижения поверхности атаки, но не заменяет защиту вывода: допустимые по формату данные тоже могут оказаться опасными в конкретном синтаксическом контексте.
Контекстное экранирование должно выполняться непосредственно перед выводом. Для HTML-текста и HTML-атрибутов применяются разные правила; отдельные правила нужны для JavaScript, CSS и URL. Нельзя безопасно использовать одну универсальную функцию экранирования во всех контекстах.
Тестировщик должен определить точку вывода и проверить, сохраняется ли пользовательское значение именно как данные. Проверка должна учитывать отражённый и хранимый XSS, разные позиции в разметке, кавычки, специальные символы, декодирование и повторную обработку значения браузером.
Важно отличать экранирование от санитизации. Если приложение намеренно разрешает ограниченный HTML, нужна контекстно корректная санитизация с белым списком допустимых элементов и атрибутов; простое экранирование в этом случае превратит разметку в текст. CSP может снизить последствия ошибки, но не устраняет дефект в обработке данных.
В профиле пользователя отображалось поле «отдел» внутри значения HTML-атрибута. Рассматривались три варианта: запретить все специальные символы на входе, удалять подозрительные фрагменты или экранировать значение при формировании атрибута.
Запрет символов был простым, но ломал легитимные значения и не решал проблему в других местах вывода. Удаление фрагментов оказалось хрупким: оно зависело от регистра, кодировок и порядка декодирования. Выбрали контекстное экранирование в общем механизме шаблонизации, запретив небезопасные способы вставки разметки.
При проверке выяснилось, что обычный вывод был защищён, но один административный экран использовал ручную вставку значения. После исправления этого участка тесты проверили как отображение в браузере, так и отсутствие исполняемой структуры в итоговом DOM. Результатом стала единообразная защита без ограничения допустимых названий отделов.
Нет. Значение может быть сохранено в базе, передано между сервисами или выведено в нескольких разных контекстах. Экранирование на входе либо испортит исходные данные, либо окажется неподходящим для другого места вывода; безопаснее хранить данные в исходном виде и применять нужное экранирование при каждом выводе.
Нет. HTML-экранирование рассчитано на правила HTML и не покрывает синтаксис JavaScript или требования безопасного формирования URL. Для каждого контекста нужен соответствующий безопасный API или механизм сериализации; особенно опасны динамические фрагменты кода и схемы URL, позволяющие выполнить сценарий.
Нет. Результат зависит от контекста, браузерной обработки, декодирования и последующих операций над DOM. Нужно проверять фактическую точку вставки, разные варианты представления данных и защиту всех путей вывода, включая хранимые значения и административные интерфейсы.