Support custom resolvers as XXE solution
- Linguagem predominante
- CodeQL
- Estrelas
- 10.1k
- Forks
- 2.1k
- Merge médio
- 2d 15h
- PRs com merge (30d)
- 141
Descrição
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.
Guia de contribuição
Avaliação
Esta issue ainda não foi avaliada.