IIS Rewrite Module过滤规则失效问题排查求助

问题根源是IIS默认会先处理并清理路径中的特殊扩展段（比如你遇到的ASP.NET会话路径(A(vulnerability))），导致Rewrite Module默认拿到的是清理后的{REQUEST_URI}，而非浏览器发送的原始请求URL，因此你的正则规则无法匹配到目标路径。

以下是具体解决方案：

• 改用{UNENCODED_URL}变量匹配原始URL
  IIS Rewrite模块提供了{UNENCODED_URL}服务器变量，它保存了浏览器发送的完整原始请求URL（未经过IIS路径清理）。修改你的规则，用这个变量作为匹配输入，而非默认的路径变量。

  示例配置：

  <rule name="Block Vulnerable Session Paths" stopProcessing="true">
    <match url=".*" />
    <conditions>
      <!-- 匹配包含括号包裹路径段的请求 -->
      <add input="{UNENCODED_URL}" pattern=".+/\([^/]+\)/.+" />
    </conditions>
    <action type="CustomResponse" statusCode="404" statusReason="Not Found" statusDescription="Resource not available" />
  </rule>
  

• 优化正则表达式精准匹配
  如果只需要拦截ASP.NET的会话路径（格式为(A(...))），可以把正则调整得更精准，避免误拦截其他合法带括号的路径：

  .+/\(A\([^)]+\)\)/.+
  

  这个正则只会匹配路径中包含(A(...)结构的段，完全对应你遇到的漏洞链接格式。

• 验证规则有效性
  利用IIS Rewrite的测试功能：在规则配置界面点击"Test Pattern"，输入原始漏洞URL（https://localhost/Account/(A(vulnerability))/Login），检查是否能成功匹配。如果需要更精准的拦截（比如只针对Account下的Login路径），可以把条件中的正则改成：

  /Account/\(A\([^)]+\)\)/Login
  

• 关于后端代码收到清理URL的说明
  调试时后端拿到清理后的URL是正常的——ASP.NET默认使用IIS清理后的路径，但只要Rewrite规则用{UNENCODED_URL}匹配并返回404，请求根本不会到达后端代码，也就不存在漏洞触发的可能。

内容的提问来源于stack exchange，提问作者Deutsche Regierung