ASP.NET MVC具有有效URL的“潜在危险Request.Path”

Question

在我的生产ASP.NET MVC 3站点上，我注意到偶尔会出现“从客户端检测到一个潜在危险的Request.Path值（％）”。 Windows应用程序日志中的未处理异常。

虽然这些在常规站点使用（即/随机web机器人）下完全有效，但许多请求似乎来自有效的本地ISP用户。

在例外的请求详细信息中，请求URL与请求路径不同：

请求URL： http ： //www.somesite.com/Images/Image With Space.jpg

请求路径：/Images/Imagehttp://www.somesite.com/Images/Image With Space.jpgWithhttp：//www.somesite.com/Images/Image With Space.jpgSpace.jpg

请注意，在“请求路径”中，路径中存在“空格”的任何位置都会替换为请求URL的精确副本！

在网站内，实际链接如下所示：

<img src="/Images/Image%20With%20Space.jpg" />

知道可能导致这种情况的原因吗？ 我试着查看Request.Path和Request.Url的文档，但我无法弄清楚为什么它们会有所不同。 直接命中请求URL会正确显示资源。

更新：我设法通过使用IIS 7.0的失败请求跟踪功能来查看其中一个故障请求：

推荐人：谷歌搜索

用户代理：Mozilla / 5.0（iPad; CPU OS 5_1_1，如Mac OS X）AppleWebKit / 534.46（KHTML，如Gecko）版本/ 5.1 Mobile / 9B206 Safari / 7534.48.3

RequestURL： http ： //www.somesite.com ：80 / Images / Image％20With％20Space.jpg

手动将URL键入我的iOS 5.1.1会正确显示图像。 在Google图像中搜索图像会正确显示图像。 仍然没有成功的复制。

在路径的中途，我看到：

MODULE_SET_RESPONSE_ERROR_STATUS警告。 ModuleName =“RequestFilteringModule”，Notification =“BEGIN_REQUEST”，HttpStatus =“404”，HttpReason =“Not Found”，HttpSubStatus =“11”，

根据IIS的文档，来自请求过滤模块的404.11是URL中的“双重编码”错误。 尝试一下，如果我有目的地创建一个双重编码的URL，如http://www.somesite.com/Images/Image%2520With%2520Space.jpg，我会在事件日志中得到确切的错误，并填写格式错误的请求路径。

事件日志错误中格式错误的请求路径似乎是ASP.NET 4.0中的错误。

但是，它没有解释为什么我首先得到错误。 我检查了大量失败的请求日志 - 唯一的常见因素是他们都在使用AppleWebKit。 它可能是Safari中的一个错误吗？

Answer 1

可以修改Web.Config的httpRuntime部分以调整URL验证。 ASP MVC项目通常在验证模式2.0下运行，下面列出了默认的无效字符（以逗号分隔）。

<httpRuntime requestValidationMode="2.0" requestPathInvalidCharacters="&lt;,&gt;,*,%,:,&amp;,\" />

如您所见，％符号被视为无效。 可以将空间编码为％20，从而导致验证错误。 您可以将requestPathInvalidCharacters属性添加到Web.Config文件中的httpRuntime部分，并复制下面列出的值，除了“％”部分。

Scott Hanselman有一篇关于这个问题的博文：

http://www.hanselman.com/blog/ExperimentsInWackinessAllowingPercentsAnglebracketsAndOtherNaughtyThingsInTheASPNETIISRequestURL.aspx

Answer 2

我不禁想到 - 鉴于受限制的用户代理 - 这可能表示IOS 5.1.1上该浏览器对URL的错误处理。 我本人并不拥有这样的设备，所以我无法对此进行测试 - 但调查它的行为方式与其实际上有空格的网站的行为会很有趣。

我有一种感觉，它从页面源中看到了网址中的%20并对其进行了双重编码，认为它有用。 问题是，IIS会将其解码回来（在ASP.net启动之前）并将其从它的婴儿车中抛出来，因为现在它看到的是字面值%20而不是空格。

我个人不建议修改服务器的安全设置; 然而，这将是最简单的解决方案，所以我敢说这就是你要做的。

相反，我想如果你能证实这个'错误'（我已经在路上，找到一个安全的隐藏地点，从Apple的律师），找到一个适用于这个设备的格式; 或者从资源网址中取出所有空格。 A -是最好的选择。