Очистка X/HTML и CSS на основе JavaScript

Прежде чем все будут говорить мне, что я не должен выполнять очистку на стороне клиента (на самом деле я собираюсь сделать это на клиенте, хотя это может работать и в SSJS), позвольте мне пояснить, что я пытаюсь сделать.

Мне нужно что-то вроде Google Caja или HTMLPurifier, но для JavaScript: подход к безопасности на основе белого списка, который обрабатывает HTML и CSS (конечно, еще не вставленный в DOM, что было бы небезопасно, но сначала полученный в строковой форме), а затем выборочно отфильтровывает небезопасные теги или атрибуты, игнорируя их или, при необходимости, включая в качестве экранированного текста или иным образом позволяя сообщить о них приложению для дальнейшей обработки, в идеале в контексте. Было бы здорово, если бы он мог сократить любой JavaScript до безопасного подмножества, как в Google Caja, но я знаю, что это требует многого.

В моем случае используется доступ к ненадежным данным XML/XHTML, полученным через JSONP (данные из вики Mediawiki до обработки вики , тем самым допуская необработанный, но ненадежный ввод XML/HTML) и позволяя пользователю выполнять запросы и преобразования этих данных (XQuery, jQuery, XSLT и т. д.), используя преимущества HTML5 для обеспечения автономного использования, хранилища IndexedDB и т. д., и который затем может разрешить предварительный просмотр результатов на той же странице, где пользователь просматривал источник ввода и создавал или импортировал свои запросы.

Пользователь может производить любой вывод, который он хочет, поэтому я не буду дезинфицировать то, что они делают — если они хотят внедрить JavaScript на страницу, вся власть на них. Но я действительно хочу защитить пользователей, которые хотят быть уверенными, что они могут добавить код, который безопасно копирует целевые элементы из ненадежного ввода, не позволяя им копировать небезопасный ввод.

Это определенно должно быть выполнимо, но мне интересно, есть ли какие-либо библиотеки, которые уже делают это.

И если я застрял в реализации этого самостоятельно (хотя мне любопытно в любом случае), я хотел бы иметь доказательства того, что использование innerHTML или создание/добавление DOM ПЕРЕД вставкой в ​​документ безопасно во всех отношениях. Например, могут ли события быть случайно вызваны, если я сначала запустил DOMParser или полагался на синтаксический анализ HTML браузера, используя innerHTML для добавления необработанного HTML к невставленному элементу div? Я считаю, что это должно быть безопасно, но не уверен, что события манипуляции с DOM могут произойти каким-то образом перед вставкой, которую можно использовать.

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

Спасибо!


person Brett Zamir    schedule 07.04.2011    source источник


Ответы (1)


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

Версия OWASP ESAPI для JavaScript: http://code.google.com/p/owasp-esapi-js

Проверка ввода чрезвычайно сложна для эффективного выполнения, HTML, безусловно, является худшим сочетанием кода и данных всех времен, поскольку существует так много возможных мест для размещения кода и так много различных допустимых кодировок. HTML особенно сложен, потому что он не только иерархичен, но и содержит множество различных парсеров (XML, HTML, JavaScript, VBScript, CSS, URL и т. д.). Хотя проверка ввода важна и должна выполняться всегда, она не является полным решением для атак путем внедрения. В качестве основной защиты лучше использовать побег. Я раньше не использовал HTML Purifier, но он выглядит хорошо, и они, безусловно, потратили на него много времени и усилий. Почему бы сначала не использовать их серверную часть решения, а затем применить любые дополнительные правила, которые вы хотите после этого. Я видел некоторые хаки, которые используют только комбинации [ ] ( ) для написания кода. Еще сотни примеров можно найти здесь Шпаргалка по XSS (межсайтовому скриптингу) и Открытый проект безопасности веб-приложений (OWASP). На что следует обратить внимание в памятке по предотвращению XSS на основе DOM.

HTML Purifier ловит этот взлом смешанной кодировки

<A HREF="h
tt  p://6&#9;6.000146.0x7.147/">XSS</A>

И это фоновое изображение DIV с эксплойтом XSS в юникоде

<DIV STYLE="background-image:\0075\0072\006C\0028'\006a\0061\0076\0061\0073\0063\0072\0069\0070\0074\003a\0061\006c\0065\0072\0074\0028.1027\0058.1053\0053\0027\0029'\0029">

Немного о том, с чем вы столкнулись: все 70 возможных комбинаций символа «‹» в HTML и JavaScript.

<
%3C
&lt
&lt;
&LT
&LT;
&#60
&#060
&#0060
&#00060
&#000060
&#0000060
&#60;
&#060;
&#0060;
&#00060;
&#000060;
&#0000060;
&#x3c
&#x03c
&#x003c
&#x0003c
&#x00003c
&#x000003c
&#x3c;
&#x03c;
&#x003c;
&#x0003c;
&#x00003c;
&#x000003c;
&#X3c
&#X03c
&#X003c
&#X0003c
&#X00003c
&#X000003c
&#X3c;
&#X03c;
&#X003c;
&#X0003c;
&#X00003c;
&#X000003c;
&#x3C
&#x03C
&#x003C
&#x0003C
&#x00003C
&#x000003C
&#x3C;
&#x03C;
&#x003C;
&#x0003C;
&#x00003C;
&#x000003C;
&#X3C
&#X03C
&#X003C
&#X0003C
&#X00003C
&#X000003C
&#X3C;
&#X03C;
&#X003C;
&#X0003C;
&#X00003C;
&#X000003C;
\x3c
\x3C
\u003c
\u003C
person SavoryBytes    schedule 14.04.2011
comment
Спасибо... в данный момент я слишком занят, чтобы присмотреться и убедиться, что он по-прежнему позволит мне поместить безопасный HTML на страницу, а не экранировать, поскольку моя цель - разрешить предварительный просмотр HTML результатов измененного запроса, но кажется, это может быть полезно. Я действительно думаю, что JavaScript нуждается в такой библиотеке, если это не так. Я не хочу совершать ненужные обходы, особенно если речь идет об автономном приложении. Спасибо! - person Brett Zamir; 14.04.2011