如何使用 Laravel 允许 WYSIWYG 编辑器并禁用 XSS 攻击？答案

【问题标题】：How can I allow WYSIWYG editors and disable XSS attacks using Laravel?如何使用 Laravel 允许 WYSIWYG 编辑器并禁用 XSS 攻击？
【发布时间】：2013-06-23 06:52:42
【问题描述】：

我有一个企业级应用程序，其中登录用户有权使用所见即所得编辑器将文章发布到页面。（您可以将此应用程序视为网站构建器。）

一切正常，但问题是；

WYSIWYG 编辑器发布包含 HTML 的文章，以及 Laravel 不喜欢的一些本地化字符串字符，因此 Laravel 的 alpha_num 检查无法通过。（因此我们不在验证检查中使用它。）
我们需要允许<、"、> 等字符，因为他们可能想使用所见即所得编辑器进行一些基本的样式设置，因此在回显/清理值时，htmlspecialchars() 不是一个选项，因为像<br>'s break 这样有害的东西。
用户可以发布诸如<script type="text/javascript>alert('Hello');</script> 或</div></div></div><div style="width: 100%, height: 100% z-index: 999999"> 之类的内容，我知道这是一个巨大的安全风险，但我们无法真正清理/逃避任何内容。用户仍然可以写<script> 并通过检查。

所以，简而言之，我们不能依赖一些内置的 Laravel 和 PHP 函数。我们也不能禁用 WYSIWYG 编辑器，因为它经常用于口语应用的大部分领域。

避免这种情况的最佳方法是什么？

我正在考虑在 Laravel 上的 alpha_num 之上创建一个自定义规则，该规则将被称为 alpha_num_localised_characters_plus_allowed_html_tags 并将该规则添加到任何包含所见即所得编辑器的输入中。

这是一个好方法吗？有没有更好的选择？您自己如何处理这些问题？

注意：请注意，我们已经开发了一个大型应用程序，我们将依赖最快和最可维护的解决方案。

【问题讨论】：

我想补充一点。我们目前将任何未经 Laravel 验证的输入（例如 email|alpha|alpha_dash|custom_validations）传递给 HTMLPurifier::purify() 验证。让我知道是否有更快的方法！
我不会使用 htmlpurifier “验证” - 而是使用它来确保输入是“安全的”。如果该字段是必需的，我将对 laravel 进行的唯一验证是“必需”。 - 有关更多详细信息，请参阅下面的答案

标签： php laravel laravel-4 laravel-3

【解决方案1】：

我相信 xss 攻击是一个输出问题。

存储没有安全风险

<script>alert('Hacking your website in 3...2...')</script>

在您的数据库中 - 它只是文本 - 它没有任何意义。我鼓励转义所有输出，不管它来自哪里。这是一个很好的讨论，进一步说明了为什么应该过滤输出而不是输入：

html/XSS escape on input vs output

【讨论】：

【解决方案2】：

使用 Laravel，您可能还需要清理刀片模板的内容。您不希望用户输入如下内容：{{{phpInfo()}}}。

构建所见即所得的编辑器需要用户有一定程度的信任。如果您根本不信任用户，那么您最好的选择就是前面提到的使用自定义标签。

【讨论】：

【解决方案3】：

您可以使用类似于 BBCode 或 Markdown 的标签系统来允许您的用户进行某些操作。通过这种方式，您可以确保输入将针对各种恶意脚本进行净化，只需在显示用户内容时使用词法分析器和 XSS 保护。

编辑：要明白我的意思，您可以使用 CKEditor 作为您的所见即所得编辑器，并结合BBCode plugin：

【讨论】：

好的，这感觉很棒。一个编辑发布一个BBCode，同时还提供所见即所得？地狱是的。非常感谢。从现在开始将它包含在我的项目中！我一直在寻找这个解决方案。

【解决方案4】：

您可以通过strip_tags 运行所有内容并只允许尽可能少的标签吗？

您可能还想查看html purifier，它应该为您提供更多选择，包括对 css 的控制

我通常做的是保存两份所见即所得的内容：

未经过滤的原始内容
过滤后的内容

如果我发现重要的内容已被删除，这允许我重新处理原始内容，并在编辑时向用户显示他们的原始 html。显然，我会在网站上显示的任何地方显示过滤后的内容。

【讨论】：

【解决方案5】：

我不知道这对您来说有多可行，但一种快速简便的解决方案是使用 httpOnly cookie。它通过注入恶意 javascript 来解决 XSS 攻击，因为 javascript 无法访问这些 cookie。您可以尝试将敏感数据放在 httpOnly cookie 中，而将不那么敏感的数据放在普通 cookie 中。看到这个：http://www.codinghorror.com/blog/2008/08/protecting-your-cookies-httponly.html

【讨论】：

我不关心cookies。无论如何，必须完全禁用 Javascript。