启用双重逃逸是危险的吗？

小开

最佳答案

编辑: 增加了相关章节的强调。

基本上: IIS 过于偏执。如果没有对 URI 解码的数据进行特别不明智的操作(比如通过字符串连接生成本地文件系统 URI) ，那么可以安全地禁用这个检查。

要禁用该检查，请执行以下操作(来自给你) : (请参阅我在下面的评论，了解双重转义的必要性)。

<system.webServer>
<security>
<requestFiltering allowDoubleEscaping="true"/>
</security>
</system.webServer>

如果加号是搜索输入中的有效字符，则需要将启用“ allowDoubleEscaping”，以允许 IIS 处理来自 URI 路径的此类输入。

最后，一个非常简单(如果有限)的解决方案就是避免使用“ +”，而是使用“% 20”。在任何情况下，使用’+’符号对空格进行编码都是 < em > not 有效的 url 编码，但是特定于一组有限的协议，并且由于向后兼容的原因可能得到广泛支持。如果只是为了规范化的目的，那么最好将空格编码为’% 20’; 这很好地避开了 IIS7问题(它仍然可能出现在其他序列中，比如% 25ab)

小开

您是否考虑过使用“/search/a/b/c”这样的搜索 URL？

你需要设置一条路线，比如

search/{*path}

然后从操作中的路径字符串中提取搜索值。

小开

我在 IIS 7.5下做应用程序中的 Server.TransferRequest ()时遇到了这个问题。

对文件名进行编码会导致双转义问题，但是如果我没有对其进行编码，那么就会遇到 “潜在危险请求路径”错误。

在我传递给 Server.TranferRequest ()的 URL 上放置任何协议，即使是空协议也可以解决这个问题。

不起作用:

context.Server.TransferRequest("/application_name/folder/bar%20bar.jpg");

作品:

context.Server.TransferRequest("://folder/bar%20bar.jpg");

小开

我只是想加上的一些信息，以 Eamon Nerbonne 的回答相关的“ 该怎么办”部分的问题(不解释为什么)。
也可以轻松地更改特定应用程序的设置

打开控制台 有管理权(Start-cmd-右键单击，以管理员身份运行)
输入以下内容(取自此处: http://blogs.iis.net/thomad/archive/2007/12/17/iis7-rejecting-urls-containing.aspx) :
```
%windir%\system32\inetsrv\appcmd set config "YOURSITENAME" -section:system.webServer/security/requestfiltering -allowDoubleEscaping:true
```
(你可以用 Default Web Site代替 YOURSITENAME，将此规则应用于默认网站)
进来，准备。

举个例子:

首先，我遇到了同样的问题:
输入上述文字:
现在，它的工作方式与预期一致: