Должен ли я дезинфицировать HTML-разметку для размещенной CMS?

Question

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

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

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

Edit: Основная причина, почему я хотел бы сделать это, чтобы позволить им использовать свои собственные JavaScript, и имеют свои собственные CSS и дивы и что не для выхода

Answer 1

Почему не будет Вы дезинфицируете вход?

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Answer 5

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

«Edit: Основная причина, почему я хотел бы сделать это, чтобы позволить им использовать свои собственные JavaScript, и имеет свои собственные CSS и див, а что нет для вывода».

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

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

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

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

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