允许双URL连接codeD请求路径是有效的 [英] Allow Double URL Encoded Request Paths To Be Valid

问题描述

我有IIS 7.0集成运行一个标准的ASP.Net WebForms的应用程序托管管道。许多我们的网站图片都在他们的文件名称空间（例如'./棒球drawing.gif）。当我们把这些图片到我们的HTML页面，我们url可连接code中的路径，以便我们的HTML的img标签看起来像该＆lt; IMG SRC = /＆GT'/棒球％20drawing.gif。';

I have a standard ASP.Net WebForms application running on IIS 7.0 with an Integrated Managed Pipeline. Many of the images on our site have spaces in their files names (e.g. './baseball drawing.gif'). When we place these images into our html pages we url encode the paths so that our html img tags look like this <img src='./baseball%20drawing.gif' />

现在，问题就来了的时候某些搜索引擎和网络爬虫尝试索引我们的网站。当他们凑我们的网页他们将HTML带code我们已经HTML-CN codeD路径得到这样的图像链接'./棒球％2520drawing.gif 其中， 25％是'％'URL编码。这将导致两个问题：

Now, the problem comes in when certain search engines and webcrawlers try to index our site. When they scrape our pages they will html encode our already html-encoded paths getting image links like this './baseball%2520drawing.gif' where %25 is the url encoding for '%'. This causes two problems:

1. 当用户从这些搜索引擎结果他们收到断开的链接。


2. 当用户试图浏览到它抛出在我们的系统错误，这些错误链接。

正如你可以看到这是一个输输的局面。用户可以得到断开的链接，而我们在错误日志中获得的噪音。

As you can see this is a lose lose situation. Users get broken links, and we get noise in our error logs.

我一直在试图找出如何，没有运气更正此问题。以下是我已经试过：

I've been trying to figure out how to correct this problem with no luck. Here is what I've tried:

1. 设置＆LT;的requestFiltering allowDoubleEscaping ='真'＆GT; 在web.config中，以prevent了404.11 URL双转义的错误。这种固定的第一个错误，但导致一个新的，有潜在危险的Request的发现。


2. 从＆LT删除了'％';的httpRuntime requestPathInvalidChars＆GT; 来prevent的潜在危险Request的错误。这种固定的第二个错误，但现在我们有了第三个，资源无法找到。


3. 我把休息在我的code观看 Request的。它看起来是与'球Image.gif的'而不是'球％2520Image.gif'的值。有了这个既然如此，我不知道为什么它不工作。

1. Set <requestFiltering allowDoubleEscaping='true'> in web.config to prevent the "404.11 URL Double Escaped error". This fixed the first error but caused a new one, "a potentially dangerous Request.Path was found".
2. Removed the '%' from the <httpRuntime requestPathInvalidChars> to prevent the "potentially dangerous Request.Path" error. This fixed the second error but now we have a third one, "Resource can't be found".
3. I placed a break in my code to watch Request.Path. It looks like it is right with a value of 'Ball Image.gif' instead of 'Ball%2520Image.gif'. With this being the case I'm not sure why it isn't working.

我觉得我有在那里我有没有真正理解，为什么没有什么工作禁止一切黑客超强。所以我想我的问题是三折

I feel like I have a super hack where I am having to disable everything without really understanding why nothing is working. So I guess my question is three fold

1. 为什么解决方案的尝试1照顾不到的问题？


2. 为什么溶液2不采取照顾的问题？


3. 为什么我看Request的第3步中的权利，但它仍然不起作用？

任何帮助，任何人都可以提供将大大AP preciated。

Any help anyone can provide would be greatly appreciated.

推荐答案

OK，经过互联网和大量的实验，我想我终于明白是怎么回事的一番搜索。我的主要问题是极端确认偏误的情况。一切，我看书上说什么，我想听到的，而不是它实际上说。我要大大地总结，我需要以了解回答我的问题的关键点。

OK, after much searching of the internets and plenty of experimentation I think I finally understand what is going on. My main problem was a case of extreme confirmation bias. Everything I read said what I wanted to hear rather than what it actually said. I am going to summarize greatly the key points I needed to understand in order to answer my question.

1. 首先，我需要了解IIS和AS​​P.Net是两个不同的应用程序。什么IIS确实简而言之就是接收请求，路由请求处理它，会从处理应用程序的输出，然后发送从应用程序返回给请求者的输出的应用程序。什么ASP.Net确实是从IIS接收请求，处理它，然后通过响应返回给IIS。这是一个巨大的过度概括的全过程，但对于我而言这是不够好。的 1

传入ASP.Net请求必须经过两个守门。该IIS7的requestFiltering模块（在system.webserver /的requestFiltering 2 配置），然后是ASP。净的httpRuntime请求过滤器（在配置的System.Web / ）。

Incoming ASP.Net requests have to pass through two gatekeepers. The IIS7 RequestFiltering module(configured in system.webserver/requestFiltering2), and then the ASP.Net HttpRuntime request filters(configured in system.web/httpRuntime3).

在IIS的requestFiltering模块是规范化传入请求唯一的一个，它仅适用正常化一次。我再次重申它仅适用于它一次。即使＆LT;的requestFiltering allowDoubleEscaping =真/＆GT; 它仍然只适用于归一次。因此，这意味着'％2520'将被标准化为％20。此时如果allowDoubleEscaping是假的这一点IIS不会让通过，因为％20仍然可以标准化的要求。但是，如果allowDoubleEscaping设置为true，那么IIS7就过去了请求％20到下一个看门人，ASP.Net。这是第一个错误的原因。

The IIS RequestFiltering module is the only one that normalizes incoming requests and it only applies normalization ONE time. Again I repeat it only applies it ONE time. Even if <requestFiltering allowDoubleEscaping="true" /> it will still only apply normalization once. So that means '%2520' will be normalized to '%20'. At this point if allowDoubleEscaping is false IIS will not let the request through since '%20' could still be normalized. If, however, allowDoubleEscaping is set to true then IIS7 will pass off the request '%20' to the next gatekeeper, ASP.Net. This was the cause of the first error.

在Asp.net过滤器是其中requestPathInvalidCharacters进行检查。所以，现在我们的％20是无效的，因为默认情况下，'％'是requestPathInvalidCharacters的一部分。如果我们从列表中删除％，我们将使它通过第二个看门者和ASP.Net会尽力处理我们的请求。这是第二个错误的原因。

The Asp.net filter is where the requestPathInvalidCharacters are checked. So now our '%20' is invalid because by default '%' is a part of requestPathInvalidCharacters. If we remove the '%' from that list we will make it through the second gatekeeper and ASP.Net will try to handle our request. This was the cause of the second error.

现在ASP.net会尽量给我们的虚拟路径转换为服务器上的物理之一。不幸的是，我们仍然在我们的道路，而不是'我们想的那么ASP.Net是不是能找到我们想要的资源，并抛出一个资源找不到错误有一个％20。路径看着我的权利，当我在我的code分手的原因是因为我置于Request.Url财产的手表。这家酒店试图通过运用其自己的正常化，其toString（）方法，从而使得对大家有所帮助我们的20％，看起来像我们希望，尽管事实并非如此。这是最后一个错误的原因。

Now ASP.net will try to convert our virtual path into a physical one on the server. Unfortunately, we still have a '%20' in our path instead of the ' ' we want so ASP.Net isn't able to find the resource we want and throws a "resource can't be found error". The reason the path looked right to me when I broke in my code is because I placed a watch on the Request.Url property. This property tries to be helpful by applying its own normalization in its ToString() method thus making our %20 look like the ' ' we want even though it isn't. This was the cause of the final error.

要完成这项工作，我们可以写我们接收的前两个守门后请求并完全交给其关闭，以ASP.Net之前规范化它自己的自定义模块。这样做虽然会允许任何字符才能通过，只要它是URL连接codeD。例如，我们通常不想让'＆LT;'或'>'我们，因为这些路径可以用来标记插入到我们的code。由于事情做好现在的工作在＆lt;和>将无法让过去的ASP.Net过滤器，因为它们是requestPathInvalidCharacters的一部分。但是，恩codeD作为％253C和％253E他们可以，如果我们打开第2个门，然后交给其关闭，以ASP.Net之前正常化自己的自定义模块中的要求。

To make this work we could write our own custom module that receives the request after the first two gatekeepers and fully normalizes it before handing it off to ASP.Net. Doing this though would allow any character to come through as long as it was URL encoded. For example, we normally don't want to allow a '<' or a '>' in our paths since these can be used to insert tags into our code. As things work right now the < and > will not get past the ASP.Net filter since they are part of the requestPathInvalidCharacters. However, encoded as a %253C and a %253E they can if we open the first two gates and then normalize the request in our own custom module before handing it off to ASP.Net.

总之，允许％2520是完全规范化离不开创造了大量的安全漏洞来完成。如果能够告诉的requestFiltering模块完全正常化每次测试针对前两个守门的请求之前收到请求，那么这将是更安全的，但现在这些功能不可用。

In conclusion, allowing %2520 to be fully normalized can't be done without creating a large security hole. If it were possible to tell the RequestFiltering module to fully normalize every request it receives before testing that request against the first two gatekeepers then it would be much safer but right now that functionality isn't available.

如果我有什么毛病让我知道，我希望这可以帮助别人。

If I got anything wrong let me know and I hope this helps somebody.

这篇关于允许双URL连接codeD请求路径是有效的的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！