XXE vulnerability in GenericPackager

[k-sever]

GenericPackager (as well as GenericValidatingPackager) are vulnerable to XML External Entity (XEE) attack.

Here is the test example that reproduces it

@Test
    public void testXXEAttach() {
        try {
            String xeeAttackXml = "<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n"
                + "<!DOCTYPE foo [\n"
                + "  <!ELEMENT foo ANY >\n"
                + "  <!ENTITY xxe SYSTEM \"https://jposxee.free.beeceptor.com/hacked\" >]>\n"
                + "<foo>&xxe;</foo>";
            new GenericPackager().readFile(new ByteArrayInputStream(xeeAttackXml.getBytes()));
            fail("Expected ISOException to be thrown");
        } catch (ISOException ex) {
            assertEquals("Entity extension is disabled", ex.getMessage(), "ex.getMessage()");
        }
    }

The xxe entity is getting resolved and request goes to https://jposxee.free.beeceptor.com/hacked (it's just a mock API):

It's not a finalized test that you can check in, but it gives you the idea.

[ar]

GenericPackager configuration is usually read from the classpath. Having the ability to define entities is a nice to have feature that improves code readability. Somebody with enough access to the classpath to use an XXE have easier ways to compromise the system.

Can you provide a use case where a GenericPackager configuration could be injected from a remote host?

[k-sever]

GenericPackager configuration is usually read from the classpath.

Well, you can't enforce it. IMO it should be secure by default, security > code readability. I'd rather disable external entities by default and make it possible to configure XML reader features for GenericPackager, so that anyone who actually needs it can redefine it.

[ar]

Fair enough. I'll reopen the issue and think about a way to configure it to reenable the feature.