Основанная на JavaScript X / HTML & CSS очистка - PullRequest
4 голосов
/ 07 апреля 2011

Прежде чем все скажут мне, что я не должен проводить дезинфекцию на стороне клиента (на самом деле я намереваюсь сделать это на клиенте, хотя это может работать и в 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 для облегчения обхода, а затем беспокоиться о фильтрации нежелательных элементов, атрибутов и значений атрибутов.

Спасибо!

1 Ответ

2 голосов
/ 14 апреля 2011

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

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

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

Очиститель HTML ловит этот смешанный хак кодирования

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

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

<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 </p>

<
%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
...