了解IIS中的路径归一化

我想在我的IIS网站上禁用诸如example.com/page/../other-page(甚至是真实页面(的目录遍历。我尝试了使用自定义响应的请求过滤和URL重写。

denyUrlSequences上的Microsoft文档实际上使用..作为示例：

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

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

我已经在IIS V7.5和V10上进行了测试，我认为它也存在于每个中间版本中。

正常化在做什么？(可能是这个图书馆？(
何时在请求生命周期中发生？
如何成功阻止以下序列而不打开安全孔？..，./和//

Internet搜索只想告诉我有关旧版本的IIS中大约200000漏洞的信息，或者如何启用其中带有点的MVC路由。

_{调试注意：如果使用curl测试此行为，请确保添加--path-as-is选项，因此它不会在客户端中进行归一化。一些浏览器似乎也在进行客户端标准化。}
_{用法注：我名义上试图关闭example.com/clubs-baby-seals/../about-us，以免某人以链接的成功负载作为密封虐待的认可。}

可能是任何正在更改它的人，从浏览器到http.sys或IIS。重要的一点是用户是否可以访问最终获得的资源。如果用户已经访问，则没有安全孔，因为它们可以同样可以在浏览器中标准化的最终地址输入。使用" .."点没有显示任何其他信息。

另一方面，您真的想知道谁改变了路径，我个人会进行一些网络跟踪以及弗里布记录以查看每个阶段的情况。我不太知道答案。

虽然我不知道(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>

相关内容

最新更新

热门标签：