0

好吧，我们都知道将来总会发现 XSS 漏洞，这些漏洞会破坏 ASP.net 的默认请求验证安全性。

但是，默认情况下，validateRequest 为 true。因此，很多 html 值首先不能输入到 ASP.net 文本框和其他输入中，对吗？

因此，虽然它不是针对 XSS 的 100% 可靠安全性，但它肯定涵盖了其中的大部分，对吧？

我不相信每次我从数据库中向 ASP.net html（通过 .Text = ...）吐出一些东西时，我都需要做进一步的 HtmlEncodes() 或自定义的 plainText() 函数，对吗？

4

3 回答 3

3

我不相信每次我从数据库中向 ASP.net html（通过 .Text = ...）吐出一些东西时，我都需要做进一步的 HtmlEncodes() 或自定义的 plainText() 函数，对吗？

我强烈建议不要这样做。

首先，ASP.NET 请求验证不会阻止 JavaScript 或 SQL 注入。

其次，请记住，XSS 漏洞的发生是由于您的代码中的错误——例如，无法正确地对用户输入进行 HTML 编码或 JavaScript 编码的代码。仅仅因为您启用了请求验证，并且 ASP.NET 阻止了一些恶意输入，并不能神奇地从您的代码中删除错误！

请求验证是一种纵深防御措施，可以帮助防止您的应用程序在您犯错时被利用。编写始终正确编码用户输入的无错误代码，您可以放心，攻击者必须跳过两圈才能破坏您的应用程序。

于 2012-05-03T20:15:06.010 回答
2

输入过滤不能解决输出转义问题。抵挡不经意的攻击者充其量只是一种局部且不可靠的防御。在我看来，框架提供商将其作为针对 XSS 问题的可靠防御是错误的和不负责任的。

您必须对放入 HTML 字符串的任何文本内容进行 HTML 编码。同样，您必须对您放入 JS 字符串的任何文本内容进行 JavaScript-string-literal-encode。您必须对放入 SQL 查询的任何文本内容进行 SQL 转义。等等。

这完全取决于您创建的输出格式；它无法在您不知道输出目标格式将是什么的输入层处理。

如果您从 HTTP 参数输入以外的来源获取任何内容并将其包含在输出中，那么您根本不受保护；相反，如果您使用 HTTP 输入来创建 HTML 以外的内容，那么您的内容就会受到不必要的破坏。另外，当然，您正在阻止完全有效的输入——如果 SO 使用请求验证，我们将无法进行此对话，因为它会在我们提到的任何时候中断<script>。

明智的编码人员使用现有的库/框架层来避免手动调用转义函数的需要，因为很容易忘记这样做。因此建议使用参数化查询，而不是从字符串连接创建 SQL。HTML 也是如此：使用精心设计的模板语言或 Web 控件集将避免您必须做任何事情，因为默认情况下会发生 HTML 转义。

ASP.NET 和 Web 窗体在这方面部分设计得很好。如果您设置TextBox.Text=...为是，则内容将根据您的需要进行转义，无需执行更多操作。另一方面，如果您将Literal.Text=...其设置为不编码，则默认情况下（这可以通过LiteralMode属性进行更改）。这种不一致是非常不幸的。

于 2012-05-04T08:56:36.013 回答
1

如果您启用了请求验证，则大多数情况下您应该受到保护。不幸的是，如果您需要保存标记，则必须先将其剥离，否则验证将抛出HttpRequestValidationException：

在此处输入图像描述

有关详细信息，请参阅白皮书：请求验证 - 防止脚本攻击

于 2012-05-03T19:55:37.550 回答