了解 IIS 中的路径规范化答案

【问题标题】：Understanding path normalization in IIS了解 IIS 中的路径规范化
【发布时间】：2019-05-13 16:04:57
【问题描述】：

我想在我的 IIS 网站中禁用像 example.com/page/../other-page（甚至是真实页面）这样的目录遍历。我已经尝试使用自定义响应进行请求过滤和 URL 重写。

关于请求过滤的denyUrlSequences 部分的Microsoft 文档实际上使用.. 作为an example：

以下示例Web.config 文件将拒绝访问三个 URL 序列。第一个序列防止目录遍历，[…]
<configuration>
   <system.webServer>
      <security>
         <requestFiltering>
            <denyUrlSequences>
               <add sequence=".." />
               [...]

……但它不起作用；在拒绝规则运行之前，example.com/page/../other-page 已经变为 example.com/other-page。您可以通过为page/sub 设置拒绝规则并访问example.com/page/./sub-page 来证明这一点。规范化路径被规则阻止，但在原始状态下不会匹配。

我已经在 IIS v7.5 和 v10 上对此进行了测试，我想它也存在于每个中间版本中。

什么是标准化？（可能是this library？）
在请求生命周期中什么时候发生？
如何在不打开一些安全漏洞的情况下成功阻止以下序列？ ..、./ 和 //

互联网搜索只想告诉我旧版本 IIS 中的一个大约 2000 年的漏洞，或者如何启用带有点的 MVC 路由。

_{调试说明：如果您使用curl 来测试此行为，请确保添加--path-as-is 选项，这样它就不会在客户端进行规范化。一些浏览器似乎也在进行客户端规范化。}
_{使用说明：我名义上是在尝试关闭example.com/clubs-baby-seals/../about-us，以免有人获取链接的成功加载作为对印章虐待的认可。}

【问题讨论】：

标签： iis iis-10 directory-traversal

【解决方案1】：

可能是任何人在改变它，从浏览器到最终的 HTTP.sys 或 IIS。重要的一点是用户是否有权访问他们最终获得的资源。如果用户已经可以访问，那么就没有安全漏洞，因为他们也可以在浏览器中输入标准化的最终地址。使用 '..' 点并不会显示任何其他信息。

另一方面，如果您真的想知道谁更改了路径，我会亲自进行一些网络跟踪以及 FREB 日志记录，以查看每个阶段会发生什么。我不知道答案。

【讨论】：

【解决方案2】：

虽然我不知道 (1) 和 (2) 的具体答案，但事实证明 (3) 的原始预规范化 URI 路径在 UNENCODED_URL 服务器变量中可用。这使得针对它运行 URL 重写规则成为可能：

<rule name="Block directory traversal attempts" stopProcessing="true">
    <match url="(.*)" />
    <conditions logicalGrouping="MatchAny" trackAllCaptures="false">
        <add input="{UNENCODED_URL}" pattern="\.\." />
        <add input="{UNENCODED_URL}" pattern="\./" />
        <add input="{UNENCODED_URL}" pattern="//" />
    </conditions>
    <action type="CustomResponse" statusCode="404"
            statusReason="Not Found" statusDescription="Page not found" />
</rule>

【讨论】：