Support custom resolvers as XXE solution
- 主要語言
- CodeQL
- 星號
- 10.1k
- 分支
- 2.1k
- 平均合併
- 2 天 15 小時
- 30 天內合併 PR
- 141
描述
I attempted to set up CodeQL in the EchoSVG project (css4j/echosvg#37) but found a [false positive claiming a critical Java XXE vulnerability](https://github.com/css4j/echosvg/security/code-scanning/30?query=ref%3Arefs%2Fpull%2F37%2Fmerge+ref%3Arefs%2Fpull%2F37%2Fhead+ref%3Arefs%2Fheads%2Ffe-codeql) in:
https://github.com/css4j/echosvg/blob/f79f0b9e201ba927745d1645ead1879c8f89e981/echosvg-dom/src/main/java/io/sf/carte/echosvg/dom/util/SAXDocumentFactory.java#L463-L470
The code uses `FEATURE_SECURE_PROCESSING` (as well as other configurations) together with a [custom resolver](https://github.com/css4j/xml-dtd) that, by default, is configured to not retrieve remote DTDs. The approach is described here:
https://css4j.github.io/resolver.html
And that's similar to the [resolver approach that OWASP describes](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#no-op-entityresolver), but instead of a no-op it is using a preloaded subset of safe DTDs. That's consistent with [SonarQube S2755](https://rules.sonarsource.com/java/RSPEC-2755):
> And use an entity resolver (and optionally an XML Catalog) to resolve only trusted entities.
Given that CodeQL uses OWASP as a guide for the identification of security vulnerabilities, it would seem reasonable to have a way to avoid false positives when a custom EntityResolver is being used.
貢獻指南
評估
這個 Issue 還沒有評估資料。