【问题标题】:URL Parameter (&cfs=1) Causing .NET ExceptionsURL 参数 (&cfs=1) 导致 .NET 异常
【发布时间】:2014-06-12 14:46:59
【问题描述】:

我最近向我的网站添加了一堆开放图形标签,现在我收到了与对这些图像的请求相关的 .NET 异常。具体来说,看起来某个社交网站(可能是 Facebook based on this post)正在请求图片,但在图片 URL 的末尾附加了“&cfs=1”:

http://www.cheatsheetwarroom.com/images/socialsharing/rankings/running-back-rankings.jpg&cfs=1

.NET 不接受“?” URL 中的字符并提供以下异常:

从客户端 (&) 检测到具有潜在危险的 Request.Path 值。

我假设当有人共享我的内容时这可能会导致问题,那么有没有办法在不牺牲安全性的情况下避免异常?

【问题讨论】:

  • 什么? .NET 非常适合使用常规查询字符串。您确定可能没有一些看起来有点可疑的 POST/表单数据吗?
  • 抱歉,我更正了示例 URL。图像扩展后的字符是和号,而不是问号。我认为这就是问题所在。
  • 您可以捕获异常,清理 URL,然后继续...?
  • 你怎么能这样?这个异常是在管道的早期生成的。
  • @bperniciaro:你找到解决这个问题的永久方法了吗?这里有同样的...

标签: c# .net facebook


【解决方案1】:

我也怀疑这个错误被扔得太远了,我无法对此做任何事情,但我还是试了一下,想出了这个 UrlRewrite 规则:

<rule name="Remove ampersand in JPG file extention" stopProcessing="true">
    <match url="([\w/]+.jpg)(&amp;[a-z=0-9]+)" />
    <conditions logicalGrouping="MatchAny" trackAllCaptures="false" />
    <action type="Rewrite" url="{R:1}" appendQueryString="false" logRewrittenUrl="true" />
</rule>

...我更愿意进行永久重定向,但 UrlRewrite 不会将 {R:1} 用于 301,因此我们可以使用这种格式的规则进行最好的重写。

【讨论】:

  • 我尝试了这种方法,虽然我不再收到“潜在危险请求”,但确实收到了 404 错误页面
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-09-20
  • 1970-01-01
  • 1970-01-01
  • 2016-06-30
  • 2021-10-02
相关资源
最近更新 更多