asp.net - 允许双 URL 编码的请求路径有效

Question

我有一个在 IIS 7.0 上运行的标准 ASP.Net WebForms 应用程序，带有集成的托管管道。我们网站上的许多图像的文件名中都有空格(例如 './baseball drawing.gif' )。当我们将这些图像放入我们的 html 页面时，我们对路径进行 url 编码，以便我们的 html img 标签看起来像这样 < img src='./baseball%20drawing.gif' />
现在，当某些搜索引擎和网络爬虫试图索引我们的网站时，问题就出现了。当他们抓取我们的页面时，他们将对我们已经 html 编码的路径进行 html 编码，从而获得这样的图像链接 './baseball%2520drawing.gif'在哪里 %25是 '%' 的 url 编码。这会导致两个问题:

当用户从这些搜索引擎获得结果时，他们会收到损坏的链接。

当用户试图导航到这些损坏的链接时，它会在我们的系统中引发错误。

正如你所看到的，这是一个双输的局面。用户的链接断开，我们的错误日志中出现噪音。

我一直在试图弄清楚如何在没有运气的情况下纠正这个问题。这是我尝试过的:

设置 <requestFiltering allowDoubleEscaping='true'>在 web.config 中防止“404.11 URL 双转义错误”。这修复了第一个错误，但导致了一个新错误，“发现了潜在危险的 Request.Path”。

从 <httpRuntime requestPathInvalidChars> 中删除了 '%'以防止“潜在危险的 Request.Path”错误。这修复了第二个错误，但现在我们有了第三个错误，“找不到资源”。

我在我的代码中设置了一个中断来观看 Request.Path .看起来它的值是“Ball Image.gif”而不是“Ball%2520Image.gif”是正确的。在这种情况下，我不确定为什么它不起作用。

我觉得我有一个 super 黑客，我不得不在没有真正理解为什么没有任何工作的情况下禁用所有东西。所以我想我的问题是三倍

为什么解决方案尝试 1 没有解决问题？

为什么解决方案 2 没有解决这个问题？

为什么我的 Request.Path 在第 3 步中看起来正确，但它仍然不起作用？

任何人都可以提供的任何帮助将不胜感激。

Answer 1

好的，经过大量的互联网搜索和大量的实验，我想我终于明白发生了什么。我的主要问题是极端确认偏差的案例。我读到的所有内容都表达了我想听到的内容，而不是实际内容。为了回答我的问题，我将大大总结我需要理解的关键点。

首先，我需要了解 IIS 和 ASP.Net 是两个不同的应用程序。简而言之，IIS 所做的就是接收请求，将该请求路由到处理它的应用程序，从处理应用程序获取输出，然后将应用程序的输出发送回请求者。 ASP.Net 所做的是从 IIS 接收请求，处理它，然后将响应传回 IIS。这是对整个过程的过度概括，但就我的目的而言，这已经足够好了。 1

传入的 ASP.Net 请求必须通过两个网守。 IIS7 RequestFiltering 模块(在 system.webserver/requestFiltering 2 中配置)，然后是 ASP.Net HttpRuntime 请求过滤器(在 system.web/httpRuntime 3 中配置)。

IIS RequestFiltering 模块是唯一一个标准化传入请求的模块，它只应用一次标准化。我再重复一遍，它只应用一次。即使<requestFiltering allowDoubleEscaping="true" />它仍然只会应用一次标准化。所以这意味着“%2520”将被规范化为“%20”。此时，如果 allowDoubleEscaping 为 false IIS 将不会让请求通过，因为 '%20' 仍然可以被规范化。但是，如果 allowDoubleEscaping 设置为 true，则 IIS7 会将请求“%20”传递给下一个网守 ASP.Net。这是第一个错误的原因。

Asp.net 过滤器是检查 requestPathInvalidCharacters 的地方。所以现在我们的 '%20' 是无效的，因为默认情况下 '%' 是 requestPathInvalidCharacters 的一部分。如果我们从该列表中删除“%”，我们将通过第二个网守，ASP.Net 将尝试处理我们的请求。这是第二个错误的原因。

现在 ASP.net 将尝试将我们的虚拟路径转换为服务器上的物理路径。不幸的是，我们的路径中仍然有一个 '%20' 而不是我们想要的 ' '，因此 ASP.Net 无法找到我们想要的资源并抛出“找不到资源错误”。当我破坏我的代码时，路径对我来说是正确的原因是因为我在 Request.Url 属性上放置了一个监视。此属性试图通过在其 ToString() 方法中应用其自己的规范化来提供帮助，从而使我们的 %20 看起来像我们想要的 ' '，即使它不是。这就是最终错误的原因。

为了完成这项工作，我们可以编写自己的自定义模块，在前两个网守之后接收请求，并在将其交给 ASP.Net 之前对其进行完全规范化。这样做虽然允许任何字符通过，只要它是 URL 编码的。例如，我们通常不希望在我们的路径中允许使用“<”或“>”，因为它们可用于将标签插入到我们的代码中。由于现在一切正常，< 和 > 不会通过 ASP.Net 过滤器，因为它们是 requestPathInvalidCharacters 的一部分。然而，编码为 %253C 和 %253E 如果我们打开前两个门，然后在我们自己的自定义模块中规范化请求，然后将其交给 ASP.Net，则它们可以。

总之，如果不产生大的安全漏洞，就无法完全规范化 %2520。如果可以告诉 RequestFiltering 模块在针对前两个网守测试该请求之前完全规范化它收到的每个请求，那么它会更安全，但现在该功能不可用。

如果我有任何问题，请告诉我，我希望这对某人有所帮助。