Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Java: `java/xxe` doesn't cover public XML helper methods that parse caller-provided input

未關閉
#21,774 2 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
48/100
Issue 類型
功能
描述清晰度
基本清楚
活躍度
冷清
技術堆疊
java
領域
security

研究方向

從 java/xxe 查詢及其現有的解析器建構 sink 和安全設定建模開始。檢查對將 InputStream、String、Reader 或 URL 值傳遞給 DocumentBuilderFactory.parse 的公開 helper 的涵蓋情況,然後與類似的 SAXParserFactory 和 XMLInputFactory 入口進行比較。完成標準是:測試能夠展示對所述 helper 形態和簡單 wrapper 的 findings,同時不遺失現有結果。

由索引模型根據 Issue 內容生成。

描述

This looks like a gap in java/xxe around library-style XML helpers. If a public helper takes caller-provided XML as an InputStream, String, Reader, or URL, builds a DocumentBuilderFactory without XXE hardening, and then calls newDocumentBuilder().parse(...), I wouldn't expect that to fall out of coverage.

CodeQL already seems to model the parser sink and the usual safe configs here, and it still finds other java/xxe results in the same codebase, so this doesn't look like a missing sink or a failed analysis. It looks more like these public parsing entry points are not treated as strong enough sources for this query. That's a pretty normal pattern in SDK helpers, XML utility classes, metadata loaders, and config parsers, where the trust boundary is the method parameter rather than a controller or request object.

The aws-sdk-android fix for CVE-2022-4725 is a good example: both RegionMetadataParser.parse(InputStream) and XpathUtils.documentFrom(...) were fixed by adding the standard DocumentBuilderFactory hardening.

Semgrep's documentbuilderfactory-disallow-doctype-decl-missing rule catches the same shape by reusing the existing parser-construction sink and checking for missing hardening, which makes this seem like a fairly local modeling issue.

My guess is that java/xxe could cover this by recognizing public parse helpers that feed caller-controlled XML directly, or through trivial wrappers, into the existing XXE sinks. I would expect the same hole to show up for similar helper methods built around SAXParserFactory and XMLInputFactory too.

import java.io.InputStream;
import javax.xml.parsers.DocumentBuilderFactory;

class XmlHelper {
    public static void parse(InputStream in) throws Exception {
        DocumentBuilderFactory f = DocumentBuilderFactory.newInstance();
        var b = f.newDocumentBuilder();
        b.parse(in);
    }
}
主要語言
CodeQL
星號
10.1k
分支
2.1k
平均合併
2 天 16 小時
30 天內合併 PR
143

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

github/codeql 的其他 Issue

查看 github/codeql 的全部 Issue

相似的 Issue

更多 Security Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。