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

Ответ 1

Нет.

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

Например, рассмотрим созданный сервером javascript на стороне клиента - сервер динамически выводит значения htmlencoded непосредственно на javascript на стороне клиента, htmlencode будет не останавливаться, введенный script из исполняемого файла.

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

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

Теперь, если его не сразу видно, если somevar (посланный пользователем, конечно) задан, например, на

a onclick=alert(document.cookie)

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

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

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

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

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

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

Ничего особенного в кодировке...

Разумеется, решение (в дополнение к правильной и ограничительной проверке входных данных белого списка) заключается в выполнении контекстно-зависимой кодировки: HtmlEncoding велик, если вы выработаете контекст IS HTML или возможно, вам нужно JavaScriptEncoding, или VBScriptEncoding, или AttributeValueEncoding, или... и т.д.

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

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

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

Дополнительная информация и довольно окончательный список (постоянно обновляется), проверьте RSnake Cheat Sheet: http://ha.ckers.org/xss.html

Ответ 2

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

Ответ 6

Нет, просто кодирование общих HTML-токенов НЕ полностью защищает ваш сайт от атак XSS. См., Например, эту уязвимость XSS, найденную в google.com:

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

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

Ответ 7

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

У этого есть дополнительное преимущество, позволяющее гарантировать действительный выход html/xhtml.

Также n'thing текстиль, его отличный инструмент, и я использую его все время, но я бы запускал его, хотя html очиститель тоже.

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

Ответ 8

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

Ответ 9

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

<script/>

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

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