Отключение javascript в конкретном блоке / div (содержащем подозрительный HTML)?


Можно ли каким-либо образом отключить выполнение браузерами скрипта внутри блока/раздела/элемента ?

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

Я более или менее отказался от попыток "санировать" входящий XHTML, увидев, сколько известных "векторов атаки" существует.: http://ha.ckers.org/xss.html

На самом деле я ищу что-то вроде:

Подозреваемый HTML

6 2

6 ответов:

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

Но если вы должны принять HTML, используйте библиотеку, подобную OWASP ANTI-SAMY или HTML Purifier. Они были построены именно для этой цели.

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

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

Даже если вы использовали тег "noscript" или тег "textarea" его sill xss. Что удерживает злоумышленника от введения закрывающих меток?

< div id="userContent">< scriptOFF>

<?=$_GET['xss']?>

< /scriptOFF>< /div>

Но его все еще xss:

http://localhost/xss.php?xss=< /scriptOFF>< /div> <script> alert(/still_xss/) </script>

Да, но этот "белый список" был бы огромным - и я далеко не достаточно компетентен, чтобы обнаружить тонкие лазейки, аля те, которые описаны здесь: http://ha.ckers.org/xss.html

Это должно быть "усилиями сообщества" - глядя на HTML-очиститель (http://htmlpurifier.org ) теперь...

Я просто подумал, что было бы здорово иметь такой тег, чтобы предотвратить 99% XSS "векторов"

  • Может ли "кто-нибудь у власти", пожалуйста, убедить создателей браузеров реализовать его : )

Править: Хорошо. HTML-очиститель это! - спасибо всем за ответ :)

@sri упомянула, где найти информацию о песочнице html5 iframe, вот тестовый сценарий .

То, что вы должны увидеть, это "браузер поддерживает атрибут iframe sandbox:)", который вы просматриваете в Chromium.

Может также получить положительные результаты в браузерах на основе khtml / webkit, таких как телефонные браузеры. Opera 11, Firefox 3.6 и Firefox4 еще не реализовали атрибут sandbox.

Статья, объясняющая фон и текущее состояние на gnubyexample.blogspot.com

Нет, но опять же, вы определенно не должны позволять вашим пользователям вручную вводить код на страницу.

Не пытайтесь санировать Javascript; не разрешайте Javascript. На самом деле, не разрешайте HTML вообще. Напишите свой собственный ограниченный язык разметки (ala BBCode) или разрешите выбрать несколько HTML-тегов, если это действительно необходимо.

То есть будьте аддитивны, а не вычитаемы в ваших усилиях по обеспечению безопасности.