Что вы делаете, когда клиент требует Rich Text Editing на своем веб-сайте?


18

Как мы все знаем к настоящему времени, XSS-атаки опасны и их действительно легко осуществить . Различные фреймворки позволяют легко кодировать HTML, как это делает ASP.NET MVC:

<%= Html.Encode("string"); %>

Но что происходит, когда ваш клиент требует, чтобы он мог загружать свой контент прямо из документа Microsoft Word?

Вот сценарий: люди могут копировать и вставлять содержимое из Microsoft Word в редактор WYSIWYG (в данном случае tinyMCE ), а затем эта информация публикуется на веб-странице.

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

Как мне справиться с этими требованиями безопасным способом? В настоящее время не выполняется проверка того, что клиент публикует (поскольку только «доверенные» пользователи могут публиковать сообщения), но я не особенно доволен этим и хотел бы заблокировать его в дальнейшем в случае взлома учетной записи.

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

Связанный вопрос

Предотвращение межсайтового скриптинга (XSS)


Хороший вопрос - вот похожий,
хотя

Согласовано. Это похоже, но это запутанный вопрос (вопрос трудно найти), и в нем конкретно не спрашивается, есть ли другой способ. Если есть другой способ рендеринга HTML без белого списка, я все об этом. Если есть ASP.NET MVC View Engine, который позаботится об этом, это тоже полезно знать.
Джордж Стокер

На заметке, не связанной с безопасностью, фильтрация тегов, вероятно, будет полезна с точки зрения пользовательского интерфейса. Очень легко случайно набрать угловую скобку и забыть ее избежать. Поскольку мы говорим о пользователях, которые копируют из Word, хорошей идеей будет отловить то, что выглядит как плохие теги, и соответствующим образом их кодировать (например, & amp; lt;), чтобы все работало.

Что касается пункта № 4: Вы держите пари, что это все еще проблема! В конце концов, большинство хаков - это внутренняя работа. Что касается конкретного редактора, мне повезло с использованием FreeTextBox, но я не могу сказать, насколько он соответствует вашим требованиям, особенно MVC.
Джоэл Коухорн

1
@gnat Спасибо; изм. Похоже, мой вопрос привлек внимание какой-то клики; три отрицательных голоса в быстрой последовательности, и ваша защита и запрос на редактирование.
Джордж Стокер

Ответы:


8

Самый простой способ (для вас, как разработчика) - это реализовать один из многих вариантов Markdown , например Markdown.NET или, что еще лучше (imho), wmd-редактор .

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


Я считаю, что StackOverflow использует собственный редактор без необходимости синтаксиса ОМУ
Джон

1
StackOverflow действительно использует ОМУ. blog.stackoverflow.com/2008/05/… stackoverflow.com/questions/98852/…

Что вы подразумеваете под синтаксисом ОМУ? Насколько я могу сказать, весь синтаксис ОМУ работает. И я еще не нашел ничего, что не работает ...

2
Проблема с использованием Markdown заключается в том, что markdown допускает произвольный HTML; так что само по себе это не решение.
Джордж Стокер

7

Белый список действительно является лучшим способом предотвращения XSS-атак, когда пользователи могут вводить HTML либо напрямую, либо с помощью Rich Text Editor.

О других ваших вопросах:

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

Я не думаю, что это может сработать. Для этого вам необходим код на стороне сервера, и RTE работает на клиенте.

TinyMCE фильтрует теги, если вы хотите, но так как это происходит в браузере, вы не можете доверять ему. Смотрите extended_valid_elements . TinyMCE (Moxie) также предлагает белый список, см. Здесь .

Должен ли я беспокоиться об этом, потому что это будет только для «частной публикации»

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

лучший способ позволить им хранить его в базе данных в любой форме, но отображать только правильно закодированные и лишенные плохих тегов?

Это способ, которым я предпочитаю это. Я не люблю менять пользовательский ввод перед вставкой в ​​базу данных по разным причинам.


-1

Я делаю то же самое. Я использую TinyMCE и разрешаю вставку из документов Word. Только определенные люди, которые поддерживают сайт, могут сделать это через область администратора. Это обеспечивается членством ASP.Net. Я просто делаю HTML.Encode, когда он отправляется на публичный сайт.

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

 /// <summary>
    /// Strip HTML
    /// </summary>
    /// <param name="str"></param>
    /// <returns></returns>
    public static string StripHTML(string str)
    {
        //Strips the HTML tags from strHTML 
        System.Text.RegularExpressions.Regex objRegExp = new System.Text.RegularExpressions.Regex("<(.|\n)+?>");

        // Replace all tags with a space, otherwise words either side 
        // of a tag might be concatenated 
        string strOutput = objRegExp.Replace(str, " ");

        // Replace all < and > with < and > 
        strOutput = strOutput.Replace("<", "<");
        strOutput = strOutput.Replace(">", ">");

        return strOutput;
    }

Если они хранят текст, такой как <script> alert ("hey") </ script>, и вы делаете Html.Encode (<script> alert ("hey") </ script>), он просто распечатает его на странице, не запустив оповещение
Джон

Я не использую белый список, я просто храню его как есть. Вышеприведенная функция могла бы помочь, но я не знаю, какой удар по ней повлияет. Хотелось бы знать, что вы решили. Почему мой пост помечен как отрицательный?
Джон

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

4
Белый список - это хорошая идея, но ваш метод, безусловно, нет. Regex не является надежным способом обнаружения тегов в тексте, так как HTML может быть довольно запутанным. Гораздо лучше использовать библиотеку, такую ​​как HTML Agility Pack.
Нолдорин

-1

Одним из вариантов может быть HTML Edit Control для .NET (который я написал).

Это WYSIWYM HTML-редактор для .NET, который поддерживает только подмножество элементов HTML , исключая <script>элементы: таким образом, он действует как белый список.

Если это для внутреннего использования (то есть сайт интрасети), то элемент управления может быть встроен в веб-страницу .

Я не интегрировал поддержку вставки из Word, но у меня есть компонент, который является шагом в этом направлении: конвертер Doc в HTML ; поэтому у меня есть строительные блоки, которые вы можете использовать в ASP.NET для преобразования документа в HTML, отображения HTML в редакторе и т. д.


-2

Мое ИМХО продолжаю доверять вашим пользователям, пока вы не станете публичным

Ну, нет надежного способа удовлетворить ваши потребности. Например, любой редактор WYSIWYG не может защитить форму, вставляя изображения с URL-адресами (отслеживание косвенного использования, недопустимый контент) или текстом (недопустимый текст, текст с ошибками, пропущенный текст).

Моя точка зрения заключается в том, что если вы можете доверять своим пользователям, просто разрешите все, просто предупредите пользователей, если есть ЗНАНИЯ опасной разметки (чтобы избежать их ошибок).

Если вы не доверяете, используйте специальную разметку (например, Markdown).

В моем проекте мы используем специальные типы для потенциально опасного контента и специальные методы для рендеринга и приема такого контента. Этот код имеет высокую оценку в нашей модели потоков, и внимание к нему очень высокое (например, каждое изменение должно проверяться двумя независимыми программистами, у нас есть комплексный набор тестов и т. Д.).

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.