Какие меры предосторожности следует предпринять, чтобы предотвратить использование XSS в HTML, отправленном пользователем?

Question

Я планирую создать веб-приложение, которое позволит пользователям размещать целые веб-страницы на моем веб-сайте. Я думаю об использовании HTML Purifier , но я не уверен, потому что HTML Purifier редактирует HTLM, и важно, чтобы HTML поддерживал только то, как он был опубликован. Поэтому я подумал сделать какое-нибудь регулярное выражение, чтобы избавиться от всех тегов сценария и всех атрибутов javascript, таких как onload, onclick и т. Д.

Я недавно видел видео Google, в котором было решение для этого. Их решение состояло в том, чтобы использовать другой веб-сайт для публикации javascript, чтобы он не мог получить к нему доступ. Но я не хочу покупать новый домен только для этого.

Answer 1

будьте осторожны с доморощенными регулярными выражениями для такого рода вещей

регулярное выражение типа

s/(<.*?)onClick=['"].*?['"](.*?>)/$1 $3/

похоже, что он может избавиться от событий onclick, но вы можете обойти его с помощью

<a onClick<a onClick="malicious()">="malicious()">

запуск регулярного выражения, который даст вам что-то вроде

<a onClick ="malicious()">

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

Answer 2

Самая критическая ошибка, которую люди делают при проверке, это на входе .

Вместо этого вы должны проверить на дисплее .

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

Учтите, что нечто, составляющее 'XSS', будет другим, когда вход помещен в '<a href="HERE">, а не <a>here!</a>.

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

Answer 3

Если вы можете найти любой другой способ разрешить пользователям публиковать контент, который не включает HTML, сделайте это. Существует множество систем разметки на стороне пользователя, которые можно использовать для создания HTML.

Так что я подумывал сделать несколько регулярных выражений, чтобы избавиться от всех тегов сценария и всех атрибутов javascript, таких как onload, onclick и т. Д.

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

Если вы можете убедить своих пользователей вводить XHTML, это намного проще разобрать. Вы все еще не можете сделать это с помощью регулярных выражений, но вы можете бросить его в простой XML-анализатор и пройтись по результирующему дереву узлов, чтобы проверить, что каждый элемент и атрибут безопасны, и удалить все, которые не являются, затем повторно -serialise.

Очиститель HTML редактирует HTLM, и важно, чтобы HTML поддерживался так, как он был опубликован.

Почему?

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

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

Но я не хочу покупать новый домен только для этого.

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

Доверяете ли вы своим пользователям возможность написания сценариев? Если нет, не позволяйте им иметь его, или вы получите скрипты атаки и фреймы для русских сайтов с эксплойтами и вредоносными программами повсюду ...

Answer 4

Убедитесь, что пользовательский контент не содержит ничего, что могло бы вызвать запуск Javascript на вашей странице.

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

Полагаю, вы можете просто использовать поддомен текущего домена для размещения Javascript, и вы получите те же преимущества безопасности для AJAX. Не печенье, однако.

---

В вашем конкретном случае фильтрация тега <script> и действий Javascript, вероятно, будет лучшим выбором.

Answer 5

Вам следует отфильтровать ВСЕ HTML и белый список только тех тегов и атрибутов, которые безопасны и семантически полезны. WordPress хорош в этом, и я предполагаю, что вы найдете регулярные выражения, используемые WordPress, если будете искать их исходный код.

Answer 6

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

2) Патч сервера. Убедитесь, что вы обновляете свой сервер всеми последними обновлениями безопасности для всех служб, работающих на этом сервере.

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

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

5) Проверить маяки в представленном коде. Этот шаг требует предыдущего шага и может быть очень сложным, потому что он может происходить в коде скрипта, который требует выполнения плагина браузера, такого как Action Script, но является такой же уязвимостью, как и возможность выполнения JavaScript из кода, предоставленного пользователем. Если пользователь может передать код, который может быть передан третьему лицу, тогда ваши пользователи и, возможно, ваш сервер будут полностью подвержены потере данных злоумышленником.