Следует ли очищать разметку HTML для размещенной CMS?

Я собираюсь создать для клиентов услугу, подобную размещенной CMS.

Как бы то ни было, потребовалось бы, чтобы клиент ввел текст, который будет доставлен всем, кто зайдет на их сайт. Я планирую использовать Markdown, возможно, в сочетании с WMD (предварительный просмотр уценки в реальном времени, который использует SO) для больших блоков текста.

Теперь я должен очистить их ввод для html? Учитывая, что только горстка людей будет редактировать свою «CMS», все платящие клиенты, следует ли мне удалять плохой HTML или просто позволить им разойтись? В конце концов, это их "сайт"

Изменить: Основная причина, по которой я бы это сделал, - это позволить им использовать свой собственный javascript и иметь свои собственные css и div, а не то, что не для вывода.


person Josh Hunt    schedule 06.10.2008    source источник


Ответы (5)


Почему не очистить ввод?

Если вы этого не сделаете, вы навлечете беду - либо на своего клиента, либо на себя, либо на обоих.

person warren    schedule 06.10.2008
comment
Если он разрешает сторонний Javascript, может ли что-нибудь быть действительно безопасным? - person Joe Skora; 07.10.2008
comment
возможно, нет, но он может внести свой вклад, чтобы помочь :) - person warren; 07.10.2008

Ваш вопрос спрашивает:

«Изменить: основная причина, по которой я бы это сделал, - это позволить им использовать свой собственный javascript и иметь свои собственные CSS и div, а также то, что не используется для вывода».

Если вы разрешаете пользователям использовать произвольный код JavaScript, дезинфекция ввода не стоит затраченных усилий. Определение межсайтового скриптинга (XSS) в основном таково: «пользователи могут предоставлять JavaScript, а некоторые пользователи плохие».

Теперь некоторые веб-сайты позволяют пользователям предоставлять JavaScript, и они снижают риск одним из двух способов:

  1. Разместите CMS отдельного пользователя в другом домене. Blogger и Tumblr (например, myblog. blogspot .com или blogger.com) делают это, чтобы предотвратить кражу пользовательскими шаблонами файлов cookie других пользователей. Вы должны знать, что делаете, и никогда не размещать какой-либо пользовательский контент в корневом домене.
  2. Если пользовательский контент никогда не передается пользователям, то не имеет значения, какой скрипт предоставляют злоумышленники. Однако CMS предназначены для совместного использования, поэтому здесь это, вероятно, не применяется.

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

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

person Chris Clark    schedule 02.06.2009

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

Вы всегда должны дезинфицировать, независимо от пользователей или зрителей.

person Carlton Jenke    schedule 06.10.2008

По крайней мере, проанализируйте их запись и разрешите только определенное «безопасное» подмножество HTML-тегов.

person Ken Ray    schedule 06.10.2008

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

person Joshua Hudson    schedule 06.10.2008