ASP.NET 4.0设置SSRS 2014报表服务器Uri时遇危险路径错误

这个问题我之前帮同事排查过，本质是ASP.NET 4.0对请求路径的安全验证规则比.NET 3.5严格很多——哪怕你的URL里看起来没有&字符，也会因为框架版本间的验证逻辑差异触发这个错误。

为什么会出现这个问题？ #

在.NET 3.5及更早版本中，ASP.NET的请求验证逻辑比较宽松，只会在页面级验证输入；而.NET 4.0默认启用了requestValidationMode="4.0"，会在请求到达任何页面/代码之前就对整个请求路径做严格检查，默认把&等字符标记为"危险"。你看到的错误里提到的&是&的HTML转义字符，可能是ReportViewer控件内部构造请求时的转义处理触发了验证，哪怕你传入的原始URL里并没有这个字符。

可行的解决方案 #

下面是几个经过验证的解决办法，按安全性从高到低排序：

1. 调整requestPathInvalidCharacters，移除&

在Web.config的<system.web>节点下添加或修改httpRuntime配置，把&从默认的危险字符列表中移除：

<system.web>
  <httpRuntime requestPathInvalidCharacters="<,>,*,%,:,\"/>
</system.web>

这样既保留了大部分安全验证，又允许&出现在请求路径中，适合大多数场景。

2. 回退到旧版请求验证模式

如果上面的方法无效，可以让ASP.NET 4.0使用.NET 3.5的验证逻辑，在Web.config里设置：

<system.web>
  <httpRuntime requestValidationMode="2.0" />
  <pages validateRequest="false" />
</system.web>

注意：validateRequest="false"会关闭页面级的请求验证，有一定安全风险，建议只在必要的页面（比如包含ReportViewer的页面）单独设置，而不是全局关闭。

3. 显式转义URL（不推荐，仅作备选）

如果不想修改Web.config，可以尝试对ReportServerUrl进行转义后再赋值：

string reportServerUrl = System.Web.HttpUtility.UrlEncode("http://MONROE:80/ReportServer_SQL2014");
mReportViewer.ServerReport.ReportServerUrl = new System.Uri(System.Web.HttpUtility.UrlDecode(reportServerUrl));

不过这个方法对ReportViewer控件的兼容性不一定好，优先推荐前两个方案。

安全提醒 #

修改请求验证规则会降低应用的安全性，务必确保你的报表服务器是可信的，并且没有暴露在公开网络中，避免恶意利用路径注入的风险。

内容的提问来源于stack exchange，提问作者Robert Hill