从客户端检测到潜在危险的 Request.Path 值 (*)答案

【问题标题】：A potentially dangerous Request.Path value was detected from the client (*)从客户端检测到潜在危险的 Request.Path 值 (*)
【发布时间】：2011-08-23 10:50:33
【问题描述】：

我收到相当不言自明的错误：

检测到来自客户端 (*) 的潜在危险 Request.Path 值。

问题是由于请求 URL 中的*：

https://stackoverflow.com/Search/test*/0/1/10/1

此 url 用于填充搜索页面，其中 'test*' 是搜索词，并且 url 的其余部分与各种其他过滤器相关。

有没有一种简单的方法可以在 URL 中允许这些特殊字符？我已经尝试修改web.config，但无济于事。

我应该手动编码/解码特殊字符吗？或者是否有这样做的最佳实践，我想避免使用查询字符串。 - 但它可能是一种选择。

应用程序本身是一个c# asp.net webforms 应用程序，它使用路由来生成上面的漂亮 URL。

【问题讨论】：

你的页面顶部有ValidateRequest=false吗？
我不知道该网站出于什么原因在内部尝试重定向，该重定向正在创建像“localhost/://localhost/myWebsiteName”这样的 URL，这给了我同样的错误。我不知道为什么 ASP.net 管道认为它是一个危险的请求 URL。

标签： c# asp.net url routing webforms

【解决方案1】：

如果您使用的是 .NET 4.0，您应该能够通过 web.config 允许这些 url

<system.web>
    <httpRuntime 
            requestPathInvalidCharacters="&lt;,&gt;,%,&amp;,:,\,?" />
</system.web>

注意，我刚刚去掉了星号（*），原来的默认字符串是：

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

更多详情请见this question。

【讨论】：

有什么方法可以在动作上使用 mvc 属性，这样我就不必为整个应用程序关闭它？类似于这里的答案：stackoverflow.com/a/1540976/298758
@longda：也许可以尝试用元素为您需要的 url 包装它。从全局角度来看，使用反射会相当简单，但我不确定是否在每个控制器/动作的基础上设置它。也许开始一个问题？
它只是在 ASP.net MVC 项目上不起作用，接收运行过程以确定 viewStart 中的布局得到这个错误：路径中的非法字符。

【解决方案2】：

*字符不允许出现在URL的路径中，但是在查询字符串中使用没有问题：

http://localhost:3286/Search/?q=test*

这不是编码问题，* 字符在 URL 中没有特殊含义，因此 URL 是否对其进行编码无关紧要。您需要使用不同的方案对其进行编码，然后对其进行解码。

例如使用任意字符作为转义字符：

query = query.Replace("x", "xxx").Replace("y", "xxy").Replace("*", "xyy");

及解码：

query = query.Replace("xyy", "*").Replace("xxy", "y").Replace("xxx", "x");

【讨论】：

“xxx”“xxy”“xyy”游戏非常聪明。您可能需要详细说明其背后的逻辑，以免使读者感到困惑。
请求是在PATH 中使用它，而不是在查询字符串中。
我遇到了同样的情况，我的参数之一是 URL。即使正确编码 URL，我也会收到此错误。我最后只是对参数进行了 base64 编码（并在我的 api 中解码），这比试图弄清楚发生了什么要容易得多。实现自己的替换例程可能是一个更好的选择。
你不能使用aa a 和ab * 作为更简单的编码方案吗？
现在这救了我，谢谢，但在适当的时候我想检查一下这个建议：stackoverflow.com/a/603962/1830909，如果听到你的想法，我会很高兴。

【解决方案3】：

对我来说，我正在使用 web api 2.0 开发 .net 4.5.2，我有同样的错误，我只是通过添加 requestPathInvalidCharacters="" 来设置它在 requestPathInvalidCharacters 中，您必须设置不允许的字符，否则您必须删除导致此问题的字符。

<system.web>
     <httpRuntime targetFramework="4.5.2" requestPathInvalidCharacters="" />
     <pages  >
      <namespaces>
     ....
 </namespaces>
    </pages> 
  </system.web>

**请注意，这不是一个好习惯，可能是带有此参数的帖子作为对象的属性更好或尝试对特殊字符进行编码。 -- 在搜索了rest api设计的最佳实践后，我发现在搜索、排序和分页中，我们必须像这样处理查询参数

/companies?search=Digital%26Mckinsey

当我们对 & 进行编码并将其替换为 %26 时，这解决了问题无论如何，在服务器上我们会收到正确的参数 Digital&Mckinsey

此链接可能有助于设计 rest web api 的最佳实践 https://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9

【讨论】：

【解决方案4】：

您应该对路由值进行编码，然后（如果需要）在搜索之前解码该值。

【讨论】：

感谢您的回复。您的意思是有效地对 * 等项目进行替换，然后在您阅读时将其替换回来？
你能展示一个编码和解码值的代码示例吗？

【解决方案5】：

对我来说，在输入 url 时，用户不小心使用了 / 而不是 ?启动查询参数

例如：

url.com/endpoint/parameter=SomeValue&otherparameter=Another+value

应该是：

url.com/endpoint?parameter=SomeValue&otherparameter=Another+value

【讨论】：

是的，对我来说也是一样的 url.com/endpoint&parameter=SomeValue&otherparameter=AnotherValue

【解决方案6】：

这个异常发生在我的应用程序中，相当具有误导性。

当我使用 ajax 方法调用调用 .aspx 页面 Web 方法并传递 JSON 数组对象时，它被抛出。网页方法签名包含一个强类型的 .NET 对象数组 OrderDetails。 Actual_Qty 属性定义为 int，JSON 对象 Actual_Qty 属性包含“4”（额外的空格字符）。去掉多余的空间后，转换就可以了，ajax调用成功到达了网页方法。

【讨论】：

【解决方案7】：

如果是 IIS Express，请尝试将 Web 项目的服务器属性设置为本地 IIS。确定项目 url 是否正确并创建虚拟目录。

【讨论】：

【解决方案8】：

在处理 Uniform Resource Locator(URL) 时，有一定的syntax standards，在这种特殊情况下，我们正在处理保留字符。

在RFC 3986 之前，保留字符可以（或不可以）被通用语法、每个特定于方案的语法或特定于实现的URI 解引用算法的语法定义为分隔符；并且星号(*) 是保留字符。

最佳做法是在 URL 中使用Unreserved Characters，或者您可以尝试对其进行编码。

继续挖掘：

【讨论】：

【解决方案9】：

我在 Azure 数据工厂中遇到了类似的问题，带有 : 字符。

我解决了这个问题用 : 替换为 %3A

如图here。

例如，我替换了

date1=2020-01-25T00:00:00.000Z

与

date1=2020-01-25T00%3A00%3A00.000Z

【讨论】：