我应该清理托管 CMS 的 HTML 标记吗？答案

【问题标题】：Should I sanitize HTML markup for a hosted CMS?我应该清理托管 CMS 的 HTML 标记吗？
【发布时间】：2010-09-15 15:03:22
【问题描述】：

我正在考虑为客户启动类似 CMS 的托管服务。

就像这样，它需要客户输入文本，这些文本将提供给任何访问其网站的人。我计划使用 Markdown，可能与 WMD（SO 使用的实时 Markdown 预览）结合使用来处理大块文本。

现在，我应该清理他们的 html 输入吗？鉴于只有少数人编辑他们的“CMS”，所有付费客户，我应该去掉坏的 HTML，还是应该让他们疯狂？毕竟，这是他们的“网站”

编辑：我这样做的主要原因是让他们使用自己的 javascript，并拥有自己的 css 和 div 以及不用于输出的东西

【问题讨论】：

【解决方案1】：

你的问题是：

“编辑：我这样做的主要原因是让他们使用自己的 javascript，并拥有自己的 css 和 div 以及不用于输出的东西”。

如果您允许用户提供任意 JavaScript，那么清理输入是不值得的。 Cross-Site Scripting (XSS) 的定义基本上是“用户可以提供 JavaScript，有些用户是坏的”。

现在，一些网站确实允许用户提供 JavaScript，它们通过以下两种方式之一降低风险：

将单个用户的 CMS 托管在不同的域下。 Blogger 和 Tumblr（例如 myblog.blogspot.com 与 blogger.com）这样做是为了防止用户的模板窃取其他用户的 cookie。您必须知道自己在做什么，并且永远不要在根域下托管任何用户内容。
如果用户内容从未在用户之间共享，则恶意用户提供的脚本无关紧要。但是，CMS 是关于共享的，所以这可能不适用于这里

有一些黑名单过滤器可能有效，但它们仅在今天有效。 HTML 规范和浏览器会定期更改，这使得过滤器几乎无法维护。黑名单是解决安全和功能问题的可靠方法。

在处理用户数据时，始终将其视为不受信任。如果您没有在产品的早期解决这个问题并且您的场景发生了变化，那么几乎不可能返回并找到所有 XSS 点或修改产品以防止 XSS 而不会惹恼您的用户。

【讨论】：

【解决方案2】：

您还会再次保护心怀不满的员工、交叉客户攻击或任何其他类型的愚蠢行为。

无论用户或观众如何，您都应该始终进行消毒。

【讨论】：

【解决方案3】：

我认为您应该始终清理输入。大多数人使用 CMS 是因为他们不想从头开始创建自己的网站，并且希望轻松访问以编辑他们的页面。这些用户很可能不会尝试输入会被清理的文本，但通过防止它来保护他们的用户。

【讨论】：

【解决方案4】：

至少解析他们的条目，只允许 HTML 标记的某个“安全”子集。

【讨论】：

【解决方案5】：

为什么不你清理输入？

如果你不这样做，你就是在招致灾难——对你的客户或你自己，或两者兼而有之。

【讨论】：