将 WMD 编辑器的预览 HTML 与服务器端 HTML 验证保持一致(例如,不嵌入 JavaScript 代码)
有很多 Stack Overflow 问题(例如白名单、防止使用 C# 进行 WMD 控制的 XSS 和 WMD Markdown 和服务器-side)关于如何对WMD编辑器生成的Markdown进行服务器端清理,以确保生成的HTML不包含恶意脚本,如下所示:
<img onload="alert('haha');"
src="http://www.google.com/intl/en_ALL/images/srpr/logo1w.png" />
但我没有找到好的方法也可以堵住客户端的漏洞。当然,客户端验证并不能替代服务器上的清理验证,因为任何人都可以假装是客户端并 POST 你讨厌的 Markdown。如果您在服务器上清理 HTML,攻击者将无法保存错误的 HTML,因此其他人以后将无法看到它,从而导致他们的 cookie 被盗或会话被错误的脚本劫持。因此,有一个有效的案例表明,在 WMD 预览窗格中也可能不值得强制执行无脚本规则。
但想象一下,攻击者找到了一种将恶意 Markdown 获取到服务器上的方法(例如,来自另一个站点的受损源,或者在修复 XSS 错误之前添加的内容)。将 Markdown 翻译为 HTML 时应用的服务器端白名单通常会阻止向用户显示不良 Markdown。但是,如果攻击者可以让某人编辑该页面(例如,通过发布另一个条目,声称该恶意条目的链接已损坏,并要求某人修复它),那么任何编辑该页面的人都会被劫持他们的 cookie。诚然,这是一个极端案例,但仍然值得防范。
另外,允许客户端预览窗口允许与服务器允许的 HTML 不同的 HTML 可能不是一个好主意。
Stack Overflow 团队通过对 WMD 进行更改来堵住这个漏洞。他们是怎么做到的?
[注意:我已经弄清楚了这一点,但它需要一些棘手的 JavaScript 调试,所以我在这里回答我自己的问题,以帮助其他可能想做同样事情的人]。
There are many Stack Overflow questions (e.g. Whitelisting, preventing XSS with WMD control in C# and WMD Markdown and server-side) about how to do server-side scrubbing of Markdown produced by the WMD editor to ensure the HTML generated doesn't contain malicious script, like this:
<img onload="alert('haha');"
src="http://www.google.com/intl/en_ALL/images/srpr/logo1w.png" />
But I didn't find a good way to plug the hole on the client side too. Client validation isn't a replacement for scrubbing validation on the server of course, since anyone can pretend to be a client and POST you nasty Markdown. And if you're scrubbing the HTML on the server, an attacker can't save the bad HTML so no one else will be able to see it later and have their cookies stolen or sessions hijacked by the bad script. So there's a valid case to be made that it may not be worth enforcing no-script rules in the WMD preview pane too.
But imagine an attacker found a way to get malicious Markdown onto the server (e.g. a compromised feed from another site, or content added before an XSS bug was fixed). Your server-side whitelist applied when translating markdown to HTML would normally prevent that bad Markdown from being shown to users. But if the attacker could get someone to edit the page (e.g. by posting another entry saying the malicious entry had a broken link and asking someone to fix it), then anyone who edits the page gets their cookies hijacked. This is admittedly a corner case, but it still may be worth defending against.
Also, it's probably a bad idea to allow the client preview window to allow different HTML than your server will allow.
The Stack Overflow team has plugged this hole by making changes to WMD. How did they do it?
[NOTE: I already figured this out, but it required some tricky JavaScript debugging, so I'm answering my own question here to help others who may want to do ths same thing].
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
一种可能的修复方法是在 wmd.js 中的
pushPreviewHtml()
方法中。以下是来自 GitHub 上 WMD 的 Stack Overflow 版本的原始代码:您可以将其替换为一些清理代码。以下是 Stack Overflow 使用响应本文的代码的改编版,限制为标签白名单,对于 IMG 和 A 元素,限制为属性白名单(并且也按特定顺序!)。请参阅 Meta Stack Overflow 帖子Stack Overflow、服务器故障和超级用户允许使用哪些 HTML 标签?< /em> 有关白名单的更多信息。
注意:此代码当然可以改进,例如允许按任何顺序将属性列入白名单。它还禁止 mailto: URL,这在 Internet 站点上可能是一件好事,但在您自己的 Intranet 站点上可能不是最好的方法。
另请注意,此修复不在 GitHub 上的 Stack Overflow 版本的 WMD 中 - 显然,更改是后来制作的,没有检查回 GitHub。
更新:为了避免破坏输入 URL 时自动创建超链接的功能,您还需要对 showdown.js 进行更改,如下所示:
原始代码:
固定代码:
One possible fix is in wmd.js, in the
pushPreviewHtml()
method. Here's the original code from the Stack Overflow version of WMD on GitHub:You can replace it with some scrubbing code. Here's an adaptation of the code that Stack Overflow uses in response to this post, which restricts to a whitelist of tags, and for IMG and A elements, restricts to a whitelist of attributes (and in a specific order too!). See the Meta Stack Overflow post What HTML tags are allowed on Stack Overflow, Server Fault, and Super User? for more info on the whitelist.
Note: this code can certainly be improved, e.g. to allow whitelisted attributes in any order. It also disallows mailto: URLs which is probably a good thing on Internet sites but on your own intranet site it may not be the best approach.
Also note that this fix is not in the Stack Overflow version of WMD on GitHub-- clearly the change was made later and not checked back into GitHub.
UPDATE: in order to avoid breaking the feature where hyperlinks are auto-created when you type in a URL, you also will need to make changes to showdown.js, like below:
Original code:
Fixed code:
只要任何第三方不可能提供脚本,允许本地用户在页面上下文中执行脚本就不是安全问题。
如果没有编辑器这样做,用户总是可以在页面上输入
javascript:
url 或使用 Firebug 或类似的东西。It is not a security issue to allow the local user to execute scripts in the page context as long as it's impossible for any third party to provide the script.
Without the editor doing it, the user could always enter a
javascript:
url while on your page or use Firebug or something similar.