Фильтрация JavaScript из HTML

Как указал Ли Теобальд, это очень опасный план. По определению вы не можете создать «безопасный» HTML-код путем фильтрации / занесения в черный список, поскольку пользователь может поместить в HTML-код, о котором вы не задумывались (или который даже не существует в вашей версии браузера, но есть в других).

Единственный безопасный способ - это занесение в белый список, т.е. удаление всего, кроме простого текста и определенных специфических HTML-конструкций. Кстати, вот что делает stackoverflow.com: -).

Если вы хотите изменить HTML, чтобы пользователи могли видеть сам HTML-код. Замените строку всех '<', '>', '&' и ';'. Например, '<' становится '& lt;'.

Если вы хотите, чтобы html работал, самый простой способ - удалить весь HTML и Javascript, а затем заменить только HTML. К сожалению, нет почти надежного способа удалить весь javascript и разрешить только HTML.

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

<img src='evilscript.js'>

, и он может запустить этот сценарий. Очень быстро становится очень небезопасно $. Вот почему большинство веб-сайтов, таких как Википедия и этот веб-сайт, используют специальный язык разметки. Это значительно упрощает форматирование, но не вредоносный javascript.

Вы можете проверить, как работают некоторые редакторы WYSIWYG на основе браузера, такие как TinyMCE . Обычно они удаляют JS и, кажется, делают с этим неплохую работу.

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

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

---

Внесение в белый список (хороший подход)

См. Эту статью о очистке HTML , который предлагает некоторые конкретные примеры того, почему вы должны занести в белый список, а не в черный. Цитата с этой страницы:

Вот неполный список потенциально опасных HTML-тегов и атрибутов:

• скрипт , который может содержать вредоносный скрипт
• апплет , встраивать , и объект , который может автоматически загружать и выполнять вредоносный код
• мета , который может содержать вредоносные перенаправления
• onload , onunload и все другие в атрибутах * , которые могут содержать вредоносный скрипт
• стиль , ссылка и атрибут стиль , который может содержать вредоносный скрипт

Здесь - еще одна полезная страница, предлагающая набор HTML-тегов и атрибутов, а также атрибутов CSS, которые обычно можно разрешить, а также рекомендуемые методы.

Внесение в черный список (как правило, плохой подход)

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

Например, эта страница дает список предположительно "всех" HTML-тегов, которые вы, возможно, захотите удалить. Просто взглянув на него вкратце, вы должны заметить, что он содержит очень ограниченное количество имен элементов; браузер может легко включить проприетарный тег, который непреднамеренно разрешает запуск сценариев на вашей странице, что по сути является основной проблемой при занесении в черный список.

---

Наконец, Я настоятельно рекомендую вам использовать библиотеку HTML DOM (например, хорошо известный HTML Agility Pack ) для .NET, а не RegEx для выполнения очистки / внесения в белый список, поскольку это было бы значительно надежнее. (Вполне возможно создать довольно сумасшедший запутанный HTML, который может обмануть регулярные выражения! Правильный читатель / писатель HTML в любом случае значительно упрощает кодирование системы.)

Надеюсь, это даст вам достойный обзор того, что вам нужно спроектировать так, чтобы полностью (или, по крайней мере, максимально) предотвратить XSS, и насколько важно, чтобы санация HTML выполнялась с учетом неизвестного фактора.

так как это было бы значительно надежнее. (Вполне возможно создать довольно сумасшедший запутанный HTML, который может обмануть регулярные выражения! Правильный читатель / писатель HTML в любом случае значительно упрощает кодирование системы.)

Надеюсь, это даст вам достойный обзор того, что вам нужно спроектировать так, чтобы полностью (или, по крайней мере, максимально) предотвратить XSS, и насколько важно, чтобы санация HTML выполнялась с учетом неизвестного фактора.

так как это было бы значительно надежнее. (Вполне возможно создать довольно сумасшедший запутанный HTML, который может обмануть регулярные выражения! Правильный читатель / писатель HTML в любом случае значительно упрощает кодирование системы.)

Надеюсь, это даст вам достойный обзор того, что вам нужно спроектировать так, чтобы полностью (или, по крайней мере, максимально) предотвратить XSS, и насколько важно, чтобы санация HTML выполнялась с учетом неизвестного фактора.