Java: `java/xxe` doesn't cover public XML helper methods that parse caller-provided input
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
Hướng nghiên cứu
Bắt đầu với truy vấn java/xxe cùng sink xây dựng parser hiện có và mô hình hóa cấu hình an toàn. Kiểm tra độ bao phủ đối với các helper public truyền giá trị InputStream, String, Reader hoặc URL vào DocumentBuilderFactory.parse, sau đó so sánh với các entry point tương tự của SAXParserFactory và XMLInputFactory. Hoàn tất khi các test thể hiện được findings cho dạng helper được mô tả và các wrapper tầm thường mà không làm mất các kết quả hiện có.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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);
}
}
- Ngôn ngữ chính
- CodeQL
- Star
- 10.1k
- Fork
- 2.1k
- Merge trung bình
- 2 ngày 11 giờ
- Pull request đã merge (30 ngày)
- 129
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của github/codeql
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
-
C#: cs/simplifiable-boolean-expression false positive on Nullable<bool> compared with a literal Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
-
false-positive
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
false-positive
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
Tất cả issue của github/codeql
Issue tương tự
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
TheManticoreProject/Manticore#1383 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
dotnet/arcade-skills#51 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
ethereum-optimism/factory#64 ·
-
Cookie sessions never expire Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
zitadel/zitadel-go#628 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
phoenixframework/phoenix#6847 ·