Що ви робите, коли клієнт вимагає редагування Rich Text на своєму веб-сайті?

Як ми всі знаємо на даний момент, атаки XSS небезпечні та їх легко зняти . Різні рамки полегшують кодування HTML, як ASP.NET MVC:

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

Але що відбувається, коли ваш клієнт вимагає, щоб він міг завантажувати свій вміст безпосередньо з документа Microsoft Word?

Ось такий сценарій: люди можуть копіювати та вставляти вміст із слова Microsoft у редактор WYSIWYG (у цьому випадку tinyMCE ), а потім ця інформація розміщується на веб-сторінці.

Веб-сайт є загальнодоступним, але лише члени цієї організації матимуть доступ до розміщення інформації на веб-сторінці.

Як я захищаю ці вимоги безпечно? В даний час не проводиться перевірка того, що публікує клієнт (оскільки лише "довірені" користувачі можуть публікувати публікації), але я не особливо задоволений цим і хотів би ще більше заблокувати його у випадку, якщо обліковий запис буде зламаний.

Єдиний концептуальний метод, який мені відомо, що відповідає цим вимогам, - це додати білі теги HTML і дозволити їм пройти . Чи є інший спосіб? Якщо ні, то який безпечний спосіб дозволити користувачу зберігати вхід у Базі даних у будь-якій формі, а лише відображати його правильно закодованим та позбавленим поганих тегів?

Супутнє запитання

Запобігання крос-скрипту (XSS)

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

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

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

Про ваші інші запитання:

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

Я не думаю, що це може спрацювати. Для цього вам потрібен код на сервері, і RTE працює на клієнті.

TinyMCE фільтрує теги, якщо ви хочете, але оскільки це відбувається в браузері, ви не можете йому довіряти. Див. Розширені_валидні_елементи . TinyMCE (Moxie) також пропонує білі списки, дивіться тут .

Чи варто навіть хвилюватися з цього приводу, оскільки це буде лише для "приватного розміщення"

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

це найкращий спосіб дозволити їм зберігати його в Базі даних у будь-якому вигляді, а лише відображати їх правильно закодованим та позбавленим поганих тегів?

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

Я роблю те саме. Я використовую 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;
    }

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

Це редактор WYSIWYM HTML для .NET, який підтримує лише підмножину елементів HTML , за винятком<script> елементи: таким чином він виступає як білий список.

Якщо він призначений для внутрішнього використання (тобто, інтранет-сайт), то керування можна вбудувати у веб-сторінку .

Я не інтегрував підтримку вставки з Word, але у мене є компонент, який є кроком у цьому напрямку: перетворювач Doc в HTML ; тому у мене є ті будівельні блоки, які ви могли використовувати в ASP.NET для перетворення Doc у HTML, відображення HTML у редакторі тощо.

Мій ІМХО продовжуйте довіряти своїм користувачам, поки ви не опублікуєте загальнодоступність.

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

Моя точка зору полягає в тому, що якщо ви можете довіряти своїм користувачам, просто дозвольте все, просто попередити користувачів, якщо є ЗНАТИ небезпечну розмітку (щоб уберегти їх від помилок).

Якщо ви не довіряєте, використовуйте якусь спеціальну розмітку (наприклад, Markdown).

У моєму проекті ми використовуємо спеціальні типи для потенційно небезпечного контенту та спеціальні методи надання та прийняття такого контенту. Цей код має високу оцінку в нашій моделі потоку, і увага до нього дуже велика (наприклад, кожну зміну слід переглянути двома незалежними кодерами, у нас є комплексний набір тестів тощо).