Можно ли настроить JAXB для предотвращения атак на расширение сущностей?

Question

Обычно при синтаксическом анализе XML в java можно избежать стать жертвой атак расширения сущностей с помощью

dbf.setFeature(javax.xml.XMLConstants.FEATURE_SECURE_PROCESSING, true);

Где dbf - это DocumentBuilderFactory, используемый длясоздать DocumentBuilders для разбора XML.

Однако предположим, что я удаляю некоторые XML с использованием JAXB, например, вот так:

  final JAXBContext context = JAXBContext.newInstance(MyClass.class);
  final Unmarshaller unmarshaller = context.createUnmarshaller();
  final MyClass result = (MyClass) unmarshaller.unmarshal(input);

Как я могу настроить JAXB для использования FEATURE_SECURE_PROCESSING в базовом синтаксическом анализаторе XML?

Поиск в ответах на лучший результат приводит к следующему: http://forums.java.net/node/699983

Однако я не хочу вводить реализации XMLStreamFactory и тому подобное просто для расширения сущностей.настраивается.Есть ли способ решить эту проблему, используя только JAXB API?

Answer 1

Java SE 5 ограничивает количество расширений сущностей до 64 000:

• http://download.oracle.com/javase/1.5.0/docs/guide/xml/jaxp/JAXP-Compatibility_150.html#JAXP_security

Я ожидаю, что все реализации JAXB оставят эту защиту по умолчанию на месте,Однако, если вы хотите быть на 100% уверены, что вы можете создать SAXSource следующим образом, и JAXB может распаковать его:

SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
SAXParser sp = spf.newSAXParser();
XMLReader xmlReader = sp.getXMLReader();
SAXSource saxSource = new SAXSource(xmlReader, inputSource);

Для получения дополнительной информации см .:

• http://bdoughan.blogspot.com/2011/03/preventing-entity-expansion-attacks-in.html

Answer 2

Я использовал код, очень похожий на тот, что был в ответе Блейза, и недавно обнаружил, что у него есть тонкая проблема. XMLReader, который я получил от SAXParser, не был настроен для понимания пространств имен, что означало, что он неправильно обрабатывал нильские элементы, такие как

<myType>
    <myIntegerElement xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
</myType>

Вместо того, чтобы JAXB демонтировал myIntegerElement в null целое число в Java, оно декодировалось в Integer.valueOf(0); важное отличие для моего кода. Решением было установить фабрику синтаксического анализатора так, чтобы она учитывала пространство имен:

SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setNamespaceAware(true);
spf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
SAXParser sp = spf.newSAXParser();
// and so on

Я нахожу это довольно удивительным, потому что, если я получу свой XMLReader, выполнив XMLReaderFactory.createXMLReader(), то у читателя не возникнет проблем с обнуляемыми элементами, но он также не поймет XMLConstants.FEATURE_SECURE_PROCESSING.

Answer 3

javax.xml.parsers.SAXParserFactory

SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); 
SAXParser sp = spf.newSAXParser();
XMLReader xmlReader = sp.getXMLReader();
SAXSource saxSource = new SAXSource(xmlReader, inputSource);  

Answer 4

Ну, во-первых, материал xmlstreamfactory является частью jdk, поэтому вам не нужно «вводить реализации» в них. во-вторых, вы всегда можете (безопасно) проанализировать DOM и затем выполнить JAXB для DOM вместо необработанного потока. наконец, вы также можете создать свой собственный SAXParser (сконфигурированный для безопасной обработки) и передать его JAXB (о котором Блейз упомянул, только что видел) (встроенный в jdk файл jaxb использует XMLReader из SAXParser в качестве внутреннего анализатора для InputStream).