有没有支持 XSS 攻击的所见即所得编辑器?

发布于 2024-07-29 22:36:31 字数 133 浏览 1 评论 0原文

我们使用所见即所得编辑器的时间已经超出了我的记忆。 在这种编辑器中轻松粘贴 JavaScript 使其成为 XSS 攻击的靶子。

有人知道任何所见即所得编辑器与 XSS 预防集成吗?

欢迎提供解决方案和建议。

We ve been using WYSIWYG Editor for more than i can remember. Easily pasting a javascript in this kind of editor make it a sitting duck for XSS attacks.

Any one know any WYSIWYG Editor than integrated with XSS preventions?

Solutions and suggestions are welcome.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

茶花眉 2024-08-05 22:36:31

所见即所得编辑器都是客户端的(除非它与某些特定于平台的服务器组件一起打包)。 您无法防范来自客户端的用户攻击; 用户始终可以跳过编辑器并直接在 HTTP 请求中发布 XSS。

您永远不想在输入或存储阶段丢弃信息。 当您将用户输入写回到屏幕时,您为防止 XSS 所做的一切都应该发生。 最简单的方法是对所有内容进行简单编码。 显然,在像 Stackoverflow 这样的网站上,一些用户输入最终需要编写为标记,因此需要首先对其进行清理。

如果我们更多地了解您正在使用的平台,我们可能会推荐一些经过充分测试、经过验证的库来满足您的需求。

A WYSIWYG editor is all client-side (unless it's packaged along with some server component, which would be platform-specific). You cannot protect against user attacks from the client-side; users can always skip the editor and post their XSS right in the HTTP request.

You never want to throw away information at the input or storage phases. Everything you do to prevent XSS should happen when you write user input back out to the screen. The simplest way is to simply encode everything. Obviously on a site like Stackoverflow, where some user input needs to be written eventually as markup, it needs to be scrubbed first.

If we know some more about what platform you're using, we could probably recommend some well-tested, proven libraries that do what you need.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文