Как нейтрализовать введенный удаленный контент Ajax?

Question

Я буду вставлять контент из удаленных источников в веб-приложение. Источники должны быть ограничены / доверены, но есть еще пара проблем:

Удаленные источники могут

1) быть взломанным и вводить плохие вещи

2) перезаписать объекты в моих глобальных именах пространство

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

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

Вот мой план на данный момент:

1) найти и удалить все встроенные обработчики событий

str.replace(/(<[^>]+\bon\w+\s*=\s*["']?)/gi,"$1return;"); // untested

Ex.

<a onclick="doSomethingBad()" ...

станет

<a onclick="return;doSomethingBad()" ...

2) удалить все вхождения этих тегов: скрипт, встраивание, объект, форма, iframe или апплет

3) найти все вхождения слова script в теге и замените слово script на html-сущности для него

str.replace(/(<[>+])(script)/gi,toHTMLEntitiesFunc);

позаботится

<a href="javascript: ..."

4) наконец, к любому атрибуту src или href, который не начинается с http, должно быть добавлено доменное имя удаленного источника

Мой вопрос: Я что-то упускаю? Другие вещи, которые я должен определенно делать или не делать?

---

Редактировать: У меня такое ощущение, что ответы пойдут в пару лагерей.

1) «Не делай этого!» ответ

Хорошо, если кто-то хочет быть на 100% безопасным, ему нужно отключить компьютер.

Это баланс между удобством использования и безопасностью.

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

2) «Я знаю об общих подвигах, и вы должны учитывать это ...» ответ ... или Вы можете предотвратить другой тип атаки, выполнив это ... или А как насчет этой атаки ...?

Я ищу второй тип, если кто-то не может указать конкретные причины, по которым my будет более опасным, чем то, что пользователь может сделать самостоятельно.

Answer 1

Похоже, вы хотите сделать следующее:

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

Если это так, то нет простых способов убрать «плохой» контент в JavaScript. Решение белого списка - лучшее, но оно может быть очень сложным. Я бы предложил прокси-запросы на удаленный контент через ваш собственный сервер и дезинфекции на стороне HTML-сервера. Существуют различные библиотеки, которые могут сделать это. Я бы рекомендовал либо AntiSamy , либо HTMLPurifier .

Для полностью браузерного способа этого можно использовать метод IE8 toStaticHTML . Однако ни один другой браузер в настоящее время не реализует это.

Answer 2

не забудьте также включить <frame> и <frameset> вместе с <iframe>

Answer 3

для санитарии, вы ищете это ?

если нет, возможно, вы могли бы узнать несколько советов из этого фрагмента кода .

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

В соответствующей заметке вы можете взглянуть на эту статью и ее обсуждение slashdot .

Answer 4

Вместо санации (черный список). Я бы посоветовал вам настроить белый список и разрешить ТОЛЬКО эти специфические вещи.

Причина этого в том, что вы никогда, никогда не поймаете все разновидности вредоносного скрипта. Их слишком много.