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

Question

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

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

Answer 1

номер

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

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

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

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

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

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 хорош, если вы выводите контекст IS или HTML вам нужно JavaScriptEncoding, или VBScriptEncoding, или AttributeValueEncoding, или ... и т. д.

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

.

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

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

Answer 8

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

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

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

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

Answer 9

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

<script/>

Вышеуказанное не может быть выполнено браузером.

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