Java: `java/xxe` doesn't cover public XML helper methods that parse caller-provided input
还没有人认领这个 Issue。
评估
调研方向
从 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 天 10 小时
- 30 天内合并 PR
- 134
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
github/codeql 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 84/100
-
难度 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
-
难度 2/5 1-3 小时 新手友好度 78/100
-
难度 2/5 1-3 小时 新手友好度 88/100
sipyourdrink-ltd/bernstein#6191 ·
-
security severity:low track:open-source
难度 2/5 1-3 小时 新手友好度 78/100
-
难度 2/5 1-3 小时 新手友好度 72/100
gwen001/offsectools_www#2055 ·
-
难度 2/5 1-3 小时 新手友好度 78/100
WalletConnect/actions#112 ·