Будет ли HTML-кодирование предотвращать все виды XSS-атак?

https://stackoverflow.com/questions/53728

09-06-2019
|

Вопрос

Меня не беспокоят другие виды атак.Просто хочу знать, может ли HTML Encode предотвратить все виды XSS-атак.

Есть ли способ провести XSS-атаку, даже если используется HTML Encode?

Решение

Нет.

Оставляя в стороне тему разрешения некоторых тегов (на самом деле это не суть вопроса), HtmlEncode просто НЕ покрывает все атаки XSS.

Например, рассмотрим клиентский javascript, генерируемый сервером: сервер динамически выводит значения в кодировке html непосредственно в клиентский javascript, htmlencode будет не останавливайся введенный скрипт от выполнения.

Далее рассмотрим следующий псевдокод:

<input value=<%= HtmlEncode(somevar) %> id=textbox>

Теперь, если это не сразу очевидно, если какая-то переменная (конечно, отправленная пользователем) установлена, например, на

a onclick=alert(document.cookie)

результирующий результат

<input value=a onclick=alert(document.cookie) id=textbox>

что явно сработает.Очевидно, это может быть (почти) любой другой сценарий...и HtmlEncode не сильно поможет.

Есть несколько дополнительных векторов, которые следует учитывать...включая третий вариант XSS, называемый XSS на основе DOM (где вредоносный сценарий генерируется динамически на клиенте, напримерна основе # значений).

Также не забывайте про атаки типа UTF-7 — как выглядит атака

+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-

Кодировать там особо нечего...

Решение, конечно (в дополнение к правильной и ограничительной проверке входных данных белого списка), состоит в том, чтобы выполнить контекстно-зависимый кодировка:HtmlEncoding отлично подходит, ЕСЛИ ваш выходной контекст ЯВЛЯЕТСЯ HTML, или, может быть, вам нужно JavaScriptEncoding, или VBScriptEncoding, или AttributeValueEncoding, или...и т. д.

Если вы используете MS ASP.NET, вы можете использовать их библиотеку Anti-XSS, которая предоставляет все необходимые методы кодирования контекста.

Обратите внимание, что все кодирование не должно ограничиваться пользовательским вводом, а также хранить значения из базы данных, текстовых файлов и т. д.

Да, и не забудьте явно указать кодировку как в заголовке HTTP, так и в теге META, иначе у вас все равно будут уязвимости UTF-7...

Еще немного информации и довольно подробный список (постоянно обновляемый) можно найти в шпаргалке RSnake: http://ha.ckers.org/xss.html

Другие советы

Если вы систематически кодируете весь пользовательский ввод перед отображением ~~тогда да, ты в безопасности~~ вы все еще не на 100% в безопасности.
(Подробнее см. в сообщении @Avid)

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

Вам придется настроить систему принятия решений, чтобы решить, какие теги разрешены, а какие нет, и всегда возможно, что кто-то найдет способ пропустить неразрешенный тег.

Будет полезно, если вы последуете совету Джоэла: Сделать неправильный код неправильным или если твой язык помогает тебе предупреждая/не компилируя при выводе необработанных пользовательских данных (статическая типизация).

Если вы все закодируете, так и будет.(в зависимости от вашей платформы и реализации htmlencode). Но любое полезное веб-приложение настолько сложно, что легко забыть проверить каждую его часть.Или, возможно, сторонний компонент небезопасен.Или, может быть, какой-то путь кода, который вы кодировали, не сработал, поэтому вы забыли его где-то еще.

Так что, возможно, вам захочется проверить и входную сторону.И вы, возможно, захотите проверить то, что вы читаете из базы данных.

Как уже упоминалось всеми остальными, вы в безопасности, пока кодируете все пользовательский ввод перед его отображением.Сюда входят все параметры запроса и данные, полученные из базы данных, которые могут быть изменены пользователем.

Как упомянуто Пэтом иногда вам может потребоваться отображать некоторые теги, но не все теги.Один из распространенных способов сделать это — использовать язык разметки, например Текстиль, Уценка, или BBCode.Однако даже языки разметки могут быть уязвимы для XSS, просто имейте это в виду.

# Markup example
[foo](javascript:alert\('bar'\);)

Если вы решите пропустить «безопасные» теги, я бы порекомендовал найти какую-нибудь существующую библиотеку для анализа и очистки вашего кода перед выводом.Есть много векторов XSS которые вам придется обнаружить, прежде чем ваше дезинфицирующее средство станет достаточно безопасным.

Я поддерживаю совет Metavida найти стороннюю библиотеку для фильтрации вывода.Нейтрализация HTML-символов — хороший способ остановить XSS-атаки.Однако код, который вы используете для преобразования метасимволов, может быть уязвим для атак уклонения;например, если он неправильно обрабатывает Unicode и интернационализацию.

Классическая простая ошибка самодельных выходных фильтров — улавливать только < и >, но пропускать такие вещи, как ", что может нарушить вывод, контролируемый пользователем, в пространство атрибутов тега HTML, где Javascript может быть прикреплен к DOM.

Нет, простое кодирование обычных HTML-токенов НЕ ПОЛНОСТЬЮ защитит ваш сайт от XSS-атак.См., например, эту XSS-уязвимость, найденную на google.com:

http://www.securiteam.com/securitynews/6Z00L0AEUE.html

Важная особенность этого типа уязвимости заключается в том, что злоумышленник может закодировать свою полезную нагрузку XSS с использованием UTF-7, и если вы не указали другую кодировку символов на своей странице, браузер пользователя может интерпретировать полезную нагрузку UTF-7 и выполнить сценарий атаки.

Еще одна вещь, которую вам нужно проверить, — это откуда поступает ваш ввод.Вы можете использовать строку реферера (в большинстве случаев), чтобы проверить, что она взята с вашей собственной страницы, но ввод скрытого случайного числа или чего-то еще в вашу форму, а затем проверка его (возможно, с помощью переменной набора сеанса) также помогает узнать, что данные поступают с вашего собственного сайта, а не с какого-то фишингового сайта.

Я хотел бы предложить очиститель HTML (http://htmlpurifier.org/) Он не просто фильтрует HTML, он по сути токенизирует и перекомпилирует его.Это действительно индустриальная сила.

Его дополнительное преимущество заключается в том, что вы можете гарантировать корректный вывод html/xhtml.

Кроме того, это не касается текстиля, это отличный инструмент, и я использую его все время, но я бы запустил его и через очиститель html.

Я не думаю, что вы поняли, что я имел в виду, говоря о токенах.HTML Purifier не просто «фильтрует», он фактически реконструирует HTML. http://htmlpurifier.org/comparison.html

Я так не думаю.Html Encode преобразует все функциональные символы (символы, которые могут интерпретироваться браузером как код) в ссылки на сущности, которые не могут быть проанализированы браузером и, следовательно, не могут быть выполнены.

&lt;script/&gt;

Невозможно выполнить вышеописанное в браузере.

**Если, конечно, это не ошибка в браузере.*

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow