.NET Framework 4.7 Web 应用程序中的 AntiXSS - 如何应用它
AntiXSS in .NET Framework 4.7 web application - how to apply it
我创建了一个在 .NET 4.7.2 上运行的简单 .NET Web 表单应用程序。
此应用程序有一个文本框、一个提交按钮和一个标签。当您单击提交按钮时，应用程序会显示文本框内容。
为了使此应用程序容易受到跨站点脚本攻击，我在其 web.config 中禁用了请求验证 (validateRequest=false)。这允许我在文本字段中输入值：XSS
并提交。
单击“提交”后，我会看到弹出窗口
为了防止 XSS 攻击，我去获取了 AntiXss 库的 NUGet 包，并按照 Microsoft AntiXss document 的说明在我的 web.config 中引用它。
但是，在我对代码中的值进行显式编码之前，我的 Web 应用程序仍未进行任何编码并且我的 Web 应用程序仍然容易受到 XSS 攻击。
protected void Button1_Click(object sender, EventArgs e)
{
//Label1.Text = TextBox1.Text;
Label1.Text = AntiXssEncoder.HtmlEncode(TextBox1.Text,true);
}
对于使用 AntiXss 库编码的值，应用程序现在显示该值而不是执行该脚本并创建弹出窗口。
所以我有三个问题：
- web.config是什么
encoderType="System.Web.Security.AntiXss.AntiXssEncoder" 确实如此
因为它不会改变我的测试结果，无论我把它放进去还是
将其从我的 web.config 中移除。根据 Micrsoft document，这设置了 HTML 和 URL 编码任务的默认处理程序。
- 如果我必须对每个文本字段进行编码以防止 XSS 攻击，是否有一种站点范围的方法来对其所有字段进行编码？似乎没有
就像具有数百个页面的站点（不是 MVC）的实用解决方案
无数的输入字段遍布各处，不得不HTML一个一个地编码。
- 除了显示之外，validateRequest 如何与 XSS 预防一起使用
标准.NET 检测危险请求页面？我可以抓住它吗
异常并在我的页面上显示错误消息而不是显示
默认错误页面如下所示。
好的，首先，从 .Net 4.5 开始，（大部分）AntiXSS 库是框架本身的一部分，它在 System.Web.Security.AntiXss 中，您不需要单独提供 dll。
默认情况下，框架 html 在使用 @ 从 Razor 或从 asp.net 使用 <%:（而不是 <%=）写入时对输出进行编码.它所做的是 html 编码，.Net 默认使用它以前的基于黑名单的方法执行此操作，该方法具有要编码的字符列表（例如 < 等），然后离开剩下的一个人。这对于许多用例来说是可以的，但是切换到带有 encoderType="System.Web.Security.AntiXss.AntiXssEncoder" 的 AntiXss 会启用基于白名单的编码器，这意味着它有一个“无害”字符列表，如字母和数字，并对 其他所有内容进行编码 ，在更多场景下更加安全。
不过请注意一些事情。
- 框架中包含的 AntiXSS 不支持 AntiXSS 库中先前存在的 html 清理功能。你通常不需要它，它的用例是当你故意有 html 用户输入时，你也想将其显示为 html （例如网络上的富文本编辑器 ui)，即便如此，AntiXss 中的方法也不是非常健壮和安全，我想这就是它被排除在外的原因。
- 不同的上下文需要不同的编码。在 html 上下文中（在 html 标记之间）仅在 Razor 中使用
@myVar 或在 asp 中使用 <%: myVar %> 是可以的，并且将被正确编码。对于 html 属性也基本没问题，但在属性中您可能希望使用特定的属性编码方法 AntiXssEncoder.HtmlAttributeEncode。对于 Javascript（在脚本标记中，或在 on* 之类的事件属性中），您需要 JavascriptEncode，即使这样也只有在带引号的字符串中使用才安全（这就是为什么默认情况下它会添加引号）。
- 请求验证一般不会阻止 xss。它确实阻止了一些基本的攻击媒介，但许多都没有被请求验证所触及，你必须手工处理这些（尤其是但不完全是 javascript 相关的）。
所以简而言之，没有针对 XSS 的灵丹妙药。你不能只在一个地方修复它然后忘记它，如果可能的话，框架可能已经这样做了。您需要在用户输入进入页面的每个地方应用正确的编码。唯一的帮助是，如果您使用正确的输出方法（@ 和 <%:），基本的 html 编码会自动应用，但如上所述，这不适用于 javascript，以及某些其他场景（例如，在 link 中编写用户提供的 url 可能会导致用户能够提供 javascript:alert(1) - 并且没有编码会删除它，这简直令人讨厌）。
据此，回答你的明确问题：
- 标准编码输出标签（
@ 和 <%:）应用基本 html 编码。这是基于较旧的标准黑名单，还是基于更安全的白名单取决于您 select AntiXss 编码器是否已经在框架中。
- 不，但如果您使用正确的标签，会有一些帮助。但总的来说，您必须检查每个变量输出。
- validaterequest 所做的只是在任何用户输入（url 变量或表单字段中查找紧跟字母的小于字符，但不是例如 cookie 值和请求 headers，这也可能成为攻击媒介）。你不应该太依赖它。不幸的是，我不知道如何显示自定义错误页面（自从我使用 .Net 以来已经有一段时间了），但我很确定这是可能的。 :)
我创建了一个在 .NET 4.7.2 上运行的简单 .NET Web 表单应用程序。
此应用程序有一个文本框、一个提交按钮和一个标签。当您单击提交按钮时，应用程序会显示文本框内容。
为了使此应用程序容易受到跨站点脚本攻击，我在其 web.config 中禁用了请求验证 (validateRequest=false)。这允许我在文本字段中输入值：XSS 并提交。
单击“提交”后，我会看到弹出窗口
为了防止 XSS 攻击，我去获取了 AntiXss 库的 NUGet 包，并按照 Microsoft AntiXss document 的说明在我的 web.config 中引用它。
但是，在我对代码中的值进行显式编码之前，我的 Web 应用程序仍未进行任何编码并且我的 Web 应用程序仍然容易受到 XSS 攻击。
protected void Button1_Click(object sender, EventArgs e)
{
//Label1.Text = TextBox1.Text;
Label1.Text = AntiXssEncoder.HtmlEncode(TextBox1.Text,true);
}
对于使用 AntiXss 库编码的值，应用程序现在显示该值而不是执行该脚本并创建弹出窗口。
所以我有三个问题：
- web.config是什么 encoderType="System.Web.Security.AntiXss.AntiXssEncoder" 确实如此 因为它不会改变我的测试结果，无论我把它放进去还是 将其从我的 web.config 中移除。根据 Micrsoft document，这设置了 HTML 和 URL 编码任务的默认处理程序。
- 如果我必须对每个文本字段进行编码以防止 XSS 攻击，是否有一种站点范围的方法来对其所有字段进行编码？似乎没有 就像具有数百个页面的站点（不是 MVC）的实用解决方案 无数的输入字段遍布各处，不得不HTML一个一个地编码。
- 除了显示之外，validateRequest 如何与 XSS 预防一起使用 标准.NET 检测危险请求页面？我可以抓住它吗 异常并在我的页面上显示错误消息而不是显示 默认错误页面如下所示。
好的，首先，从 .Net 4.5 开始，（大部分）AntiXSS 库是框架本身的一部分，它在 System.Web.Security.AntiXss 中，您不需要单独提供 dll。
默认情况下，框架 html 在使用 @ 从 Razor 或从 asp.net 使用 <%:（而不是 <%=）写入时对输出进行编码.它所做的是 html 编码，.Net 默认使用它以前的基于黑名单的方法执行此操作，该方法具有要编码的字符列表（例如 < 等），然后离开剩下的一个人。这对于许多用例来说是可以的，但是切换到带有 encoderType="System.Web.Security.AntiXss.AntiXssEncoder" 的 AntiXss 会启用基于白名单的编码器，这意味着它有一个“无害”字符列表，如字母和数字，并对 其他所有内容进行编码 ，在更多场景下更加安全。
不过请注意一些事情。
- 框架中包含的 AntiXSS 不支持 AntiXSS 库中先前存在的 html 清理功能。你通常不需要它，它的用例是当你故意有 html 用户输入时，你也想将其显示为 html （例如网络上的富文本编辑器 ui)，即便如此，AntiXss 中的方法也不是非常健壮和安全，我想这就是它被排除在外的原因。
- 不同的上下文需要不同的编码。在 html 上下文中（在 html 标记之间）仅在 Razor 中使用
@myVar或在 asp 中使用<%: myVar %>是可以的，并且将被正确编码。对于 html 属性也基本没问题，但在属性中您可能希望使用特定的属性编码方法AntiXssEncoder.HtmlAttributeEncode。对于 Javascript（在脚本标记中，或在on*之类的事件属性中），您需要JavascriptEncode，即使这样也只有在带引号的字符串中使用才安全（这就是为什么默认情况下它会添加引号）。 - 请求验证一般不会阻止 xss。它确实阻止了一些基本的攻击媒介，但许多都没有被请求验证所触及，你必须手工处理这些（尤其是但不完全是 javascript 相关的）。
所以简而言之，没有针对 XSS 的灵丹妙药。你不能只在一个地方修复它然后忘记它，如果可能的话，框架可能已经这样做了。您需要在用户输入进入页面的每个地方应用正确的编码。唯一的帮助是，如果您使用正确的输出方法（@ 和 <%:），基本的 html 编码会自动应用，但如上所述，这不适用于 javascript，以及某些其他场景（例如，在 link 中编写用户提供的 url 可能会导致用户能够提供 javascript:alert(1) - 并且没有编码会删除它，这简直令人讨厌）。
据此，回答你的明确问题：
- 标准编码输出标签（
@和<%:）应用基本 html 编码。这是基于较旧的标准黑名单，还是基于更安全的白名单取决于您 select AntiXss 编码器是否已经在框架中。 - 不，但如果您使用正确的标签，会有一些帮助。但总的来说，您必须检查每个变量输出。
- validaterequest 所做的只是在任何用户输入（url 变量或表单字段中查找紧跟字母的小于字符，但不是例如 cookie 值和请求 headers，这也可能成为攻击媒介）。你不应该太依赖它。不幸的是，我不知道如何显示自定义错误页面（自从我使用 .Net 以来已经有一段时间了），但我很确定这是可能的。 :)