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 别名攻击的前线,最后一道防御是不允许任何资源别名。

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

解决方法

        可以部署一些 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安全攻防实验室,经授权后由张发布,观点不代表华盟网的立场,转载请联系原作者。

发表评论