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-FoundSet>    New>  Arg>Call><Call name="addRule">  <Arg>    <New class="org.eclipse.jetty.rewrite.handler.ValidUrlRule"/>  Arg>Call>