1

我已经阅读了关于防止 XSS 的 OWASP 指南。该指南似乎仅涉及具有白名单和编码输出。然而，这留下了所谓的自由文本字段的问题，例如我写这篇文章的文本框。

在接受自由文本字段时，除了可以在服务器端完成的黑名单（不可取）之外，是否还有任何预防措施。

从 OWASP 指南中，我得到的印象是应该只允许将 xss 存储在数据库中，并在它显示到前端时对其进行清理。然而，我对此有点不舒服。还是我错了，有没有更好的方法？

4

4 回答 4

3

XSS 是一个输出问题。您不能拥有适用于所有 xss 的所有编码或输入验证功能。即使通过将输入字符串转换为它们的 htmlentities，您的应用程序仍然容易受到dom 事件以及其他向量中的 xss 的攻击。很难保持所有这些规则的正确性。确保测试您的代码，有免费的 XSS 扫描程序，例如Sitewatch和Skipfish。

在数据库中存储 HTML 不是漏洞，但显示它是持久性 XSS。这是最糟糕的 xss 形式。将未编码的版本存储在数据库中是很常见的，因为它可以使数据保持一致并且更好地进行文本比较和匹配。在 MS-SQL 的 SQL 注入中，您可以堆叠查询，以便将 xss 有效负载引入数据库。例如 select...; insert into comments (post)values('<script>alert(xss)</script>'). 不要相信你的数据库。

于 2011-09-30T06:37:10.717 回答
2

我的印象是应该只允许将 xss 存储在数据库中，并在它显示到前端时对其进行清理

那是对的。无论您使用哪个反 XSS 编码库/函数进行编码，都将阻止 XSS 尝试工作，方法是防止在将狡猾的代码添加到页面输出时将其呈现为 HTML。

您不应该在存储之前尝试清理输入，原因与您不维护黑名单的原因大致相同 - 太容易出错，并且清理太多或不够。如果您要尝试清除输入，您最好知道自己在做什么。

于 2011-09-30T00:28:59.440 回答
2

我领导 OWASP 指南，自从指南 2.0 于 2004/2005 年编写以来，我对此的看法已经成熟。

在我看来，您需要处理两个阶段：

输入验证- 如果可能，您应该始终避免让 XSS 向量侵入您的数据。我有 Views™，但老实说，最好的办法是尽可能地严格限制类型和长度。允许将布尔变量或整数变量存储为文本列是没有意义的。剩余风险将是存储在文本块中的文本区域，这在对表示层进行编码时应该是显而易见的，无论是什么。

输出编码- 在编写原始指南时（2002 年），我们正在做 Big 5，这不再是真的。您需要为上下文正确输出编码，因此如果您要输出到 Ajax，则需要使其既安全 JSON 和 JavaScript 又安全 HTML。

该指南的新版本正在开发中，OWASP 指南 2013。我将确保正确更新。

请在我们项目的问题跟踪器上记录问题，因为您有一个非常有效的问题：

在 OWASP Guide 2013 问题跟踪器中记录问题

简单地为大 5 编码的日子已经结束了。特别是，因为 HTML 不太可能成为未来的主要表示层。

Andrew van der Stock，OWASP Guide 2.0 / 2013 Guide Lead。

于 2012-06-29T11:28:44.667 回答
1

所以这里有两点需要注意。

输入验证是为了确保数据根据域是有效的，这可以阻止一些攻击，但绝对不是全部。

完成输出编码以确保数据不会以某种方式被解析为 HTML 或 javascript。因此，正如 Rook 所描述的，这是一个输出问题。您应该看到OWASP XSS 预防备忘单，它解释了如何直接在 HTML 页面中避免 XSS，以及基于 OWASP DOM 的 XSS 预防备忘单，以了解如何避免由 javascript 读取和写入未经处理或未编码的数据触发的 XSS。

正如 Rook 所提到的，不要在输入的过程中受到编码或清理数据的诱惑，除非根据您的域它当然是无效的。在输出之前确实没有办法正确编码，因为那是你知道你正在编码的上下文的时候。它是 HTML 属性、javascript 字符串、HTML 属性中的 javascript 字符串等。

正如 OWASP XSS 预防备忘单中的规则#6 所述，如果您想允许某些 HTML 用户使用基于白名单的引擎，例如 OWASP AntiSamy 或 HTMLPurifier。

于 2011-09-30T10:11:08.257 回答