.NET Framework 4.7 Web 应用程序中的 AntiXSS - 如何应用它

Question

我创建了一个在 .NET 4.7.2 上运行的简单 .NET Web 表单应用程序。

该应用程序有一个文本框、一个提交按钮和一个标签。当您单击提交按钮时，应用程序将显示文本框内容。

为了使该应用程序容易受到跨站点脚本攻击，我在其 web.config 中禁用了请求验证 (validateRequest=false)。这允许我在文本字段中输入值： XSS<img src=x onerror=confirm("HACKED")> 并提交。

单击“提交”后，我会看到弹出窗口

为了防止 XSS 攻击，我获取了 AntiXss 库的 NUGet 包，并按照Microsoft AntiXss 文档中的说明在我的 web.config 中引用它。

然而，没有任何编码，并且我的 Web 应用程序仍然容易受到 XSS 攻击，直到我在代码中显式编码该值。

        protected void Button1_Click(object sender, EventArgs e)
        {
            //Label1.Text = TextBox1.Text;
            Label1.Text = AntiXssEncoder.HtmlEncode(TextBox1.Text,true);

        }

通过使用 AntiXss 库编码的值，应用程序现在显示该值而不是执行该脚本并创建弹出窗口。

所以我有三个问题：

1. web.configencoderType="System.Web.Security.AntiXss.AntiXssEncoder" 的真正作用是什么，因为无论我将其放入还是从 web.config 中删除，它都不会改变我的测试结果。根据Micrsoft 文档，这设置了 HTML 和 URL 编码任务的默认处理程序。
2. 如果我必须对每个文本字段进行编码以防止 XSS 攻击，是否有一种站点范围的方法对其所有字段进行编码？对于一个拥有数百个页面、大量输入字段遍布各处并且必须逐一进行 HTMLEncode 的网站（不是 MVC）来说，这似乎不是一个实用的解决方案。
3. 除了显示标准 .NET 检测危险请求页面之外，validateRequest 如何与 XSS 防护配合使用？我可以将其捕获为异常并在我的页面上显示错误消息，而不是显示如下所示的默认错误页面吗？

Answer 1

好的，首先，从 .Net 4.5 开始，（大部分）AntiXSS 库是框架本身的一部分，它位于 .Net 中System.Web.Security.AntiXss，您不需要单独提供 dll。

@默认情况下，当从 Razor 使用或从 asp.net 使用<%:（而不是）写入时，框架 html 会对输出进行编码<%=。它所做的是 html 编码，而 .Net 默认使用以前的基于黑名单的方法来执行此操作，该方法有一个要编码的字符列表（例如等<），而忽略其余部分。这对于许多用例来说是可以的，但是切换到 AntiXss 可以启用encoderType="System.Web.Security.AntiXss.AntiXssEncoder"基于白名单的编码器，这意味着它有一个“无害”字符（例如字母和数字）列表，并对其他所有内容进行编码，这使得它在更多场景中更加安全。

但请注意一些事项。

• 框架中包含的 AntiXSS 不支持 AntiXSS 库中先前存在的 html 清理功能。你通常不需要这个，这样做的用例是当你故意有 html 用户输入时，你也想将其显示为 html（例如 Web ui 上的富文本编辑器），即使如此，AntiXss 中的方法是对于这个目的来说不是很健壮和安全，我想这就是它被排除在外的原因。
• 不同的上下文需要不同的编码。在 html 上下文中（在 html 标签之间），只需@myVar在 Razor 或<%: myVar %>asp 中使用就可以了，并且将被正确编码。对于 html 属性来说，大多数情况下也是可以的，但是在属性中，您可能想要使用特定的属性编码方法 AntiXssEncoder.HtmlAttributeEncode。对于Javascript（在脚本标记中，或在事件属性中，例如on*），您需要JavascriptEncode，甚至只有在带引号的字符串中使用时才是安全的（这就是默认情况下它添加引号的原因）。
• 一般来说，请求验证并不能防止 xss。它确实可以防止一些基本的攻击向量，但许多攻击向量不会受到请求验证的影响，你必须手动处理这些攻击向量（特别是但不限于与 javascript 相关的攻击向量）。

简而言之，没有针对 XSS 的灵丹妙药。你不能只是在一个地方修复它然后忘记它，如果可能的话，框架可能已经这样做了。您需要在用户输入进入页面的每个位置应用正确的编码。唯一的帮助是，如果您使用正确的输出方法 (@和<%:)，则会自动应用基本 html 编码，但如上所述，这不适用于 javascript 和某些其他场景（例如在链接中编写用户提供的 url）可能会导致用户能够提供javascript:alert(1)- 并且没有编码会删除它，这只是令人讨厌）。

基于此，明确回答您的问题：

1. 标准编码输出标签 (@和<%:) 应用基本 html 编码。这是基于较旧的标准黑名单，还是基于更安全的白名单，取决于您是否选择框架中已有的 AntiXss 编码器。
2. 不，但是如果您使用正确的标签，会有一些帮助。但一般来说，您必须检查每个变量输出。
3. validaterequest 所做的只是在任何用户输入（url 变量或表单字段，但不包括 cookie 值和请求标头，它们也可能成为攻击向量）中查找紧跟字母的小于字符。你不应该过分依赖它。不幸的是，我不知道如何显示自定义错误页面（自从我使用.Net以来已经有一段时间了），但我很确定这是可能的。:)