Java: `java/xxe` doesn't cover public XML helper methods that parse caller-provided input
まだ誰も着手していません。
評価
調査の方向性
java/xxe クエリと、既存のパーサー構築シンクおよび安全な設定のモデリングから始めます。InputStream、String、Reader、または URL の値を DocumentBuilderFactory.parse に渡す公開ヘルパーについてカバレッジを確認し、その後、類似する SAXParserFactory および XMLInputFactory のエントリーポイントと比較します。完了条件は、既存の結果を失うことなく、説明したヘルパーの形状と単純なラッパーに対する 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日 10時間
- マージ済み PR(30日)
- 134
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
github/codeql のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
-
C#: cs/simplifiable-boolean-expression false positive on Nullable<bool> compared with a literal オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
false-positive
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
-
false-positive
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
似ている issue
-
documentation help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
clerk/javascript#9852 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
AiursoftWeb/AnduinOS-2#19 ·
-
area/config comp/agent P3 sweeper:risk-security-boundary type/feature
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
NousResearch/hermes-agent#118734 · コメント 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
AXERA-TECH/ax-llm#75 ·