CVE-2021-34429 Jetty WEB-INF 信息泄露

描述

        可以使用一些编码字符来制作 URI，以访问WEB-INF目录的内容和/或绕过一些安全限制。

影响

        默认合规模式允许带有包含 %u002e 段的 URI 的请求访问 WEB-INF 目录中的受保护资源。例如，/%u002e/WEB-INF/web.xml可以检索 web.xml 文件的请求。这可能会泄露有关 Web 应用程序实现的敏感信息。同样，编码的空字符可能会阻止正确的规范化，因此 /.%00/WEB-INF/web.xml cal 也会检索 web.xml 文件。

分析

在 9.4.37 之前，Jetty 由两条防线保护免受这种攻击方式：

• URI 首先被解码，然后对.和..序列进行归一化。虽然这不符合 RFC，但它确实删除了已编码或参数化的相关段，并使生成的 URI 路径免受任何重复规范化（通常通过 URI 操作和文件系统映射完成）的影响。

• 该FileResource级处理的绝对路径和资源的规范路径之间的差额作为别名，因此资源不会被默认服务。

在 9.4.37 之前，FileResource该类被替换为PathResource不将规范化差异视为别名的类。然后版本 9.4.37 更新了 URI 解析以符合 RFC，因为在解码之前完成规范化。这允许对不会被纯 RFC URI 规范化但被文件系统规范化的相对路径段进行各种编码或修饰，从而允许通过别名访问受保护的资源。特别是通过在规范化后解码 URI，它使它们容易受到任何后续规范化（可能在检查安全约束之后）改变 URI 的单一性。这种额外的规范化通常会被 URI 操作代码和文件系统所破坏。

随着 Jetty 版本 9.4.43、10.0.6、11.0.6，我们恢复了几道防线：

• URI 首先被解码，然后被规范化，这不是严格按照当前的 RFC。由于规范化是在解码后完成的，因此生成的 URI 路径不会被进一步规范化，并且引用的资源在通过安全约束后也不容易更改。

• 在 URI 解析过程中，会检查一些特定的段/字符，这些段/字符可能会被应用程序模糊地看到（例如，编码点段、编码分隔符、空段、参数化点段和/或空字符）。因此，即使 Jetty 代码正确处理这些 URI，也存在应用程序可能不会这样做的风险，因此除非设置了特定的合规模式，否则此类请求会被 400 Bad Request 拒绝。

• 一旦通过初始 URI 处理解码和规范化，Jetty 将不会在其自己的资源处理中再次解码或规范化接收到的 URI。这避免了双重解码攻击的可能性。

• 该ContextHandler.getResource(String path)方法始终检查传递的路径是否已规范化，仅在 AliasChecker 批准的情况下才接受非正常路径。这是Jetty资源服务直接使用的方法。

• API 方法像ServletContext.getResource(String path)将在调用之前规范化ContextHandler.getResource(String path)。这允许应用程序使用非正常路径。

• 该PathResource班现在认为在请求资源的名称和发现的资源名称之间的正常/规范名称的任何差异是一个别名，如经明确，这将只投放AliasChecker

总之，防御是检测特定已知 URI 别名攻击的前线，最后一道防御是不允许任何资源别名。

解决方法

        可以部署一些 Jetty重写规则来将原始请求 URI 中包含编码点段或空字符的任何请求重写为已知未找到的资源：

<Call name="addRule">  <Arg>    <New class="org.eclipse.jetty.rewrite.handler.RewriteRegexRule">      <Set name="regex">.*/(?:.+/)+.*</Set>      <Set name="replacement">/WEB-INF/Not-Found</Set>    </New>  </Arg></Call><Call name="addRule">  <Arg>    <New class="org.eclipse.jetty.rewrite.handler.ValidUrlRule"/>  </Arg></Call>

本文始发于微信公众号（Khan安全攻防实验室）：CVE-2021-34429 Jetty WEB-INF 信息泄露