XML External Entity (XXE) — уязвимости внешних объектов параметров и внешних общих объектов

Чтобы предотвратить атаки XXE, я отключил перечисленные ниже функции в соответствии с рекомендациями для Java DocumentBuilderFactory — https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet.

        dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
        dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
        dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
        dbf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);
        dbf.setXIncludeAware(false);
        dbf.setExpandEntityReferences(false);

Существует ли какая-либо уязвимость, если я не устанавливаю для external-general-entites и external-parameter-entities значение false? Поскольку это не позволит расширить эти внешние объекты, если мы установим для параметра disallow-doctype-decl значение true, а для XIncludeAware — значение false.

Безопасно ли удалить эти 2 строки из приведенного выше кода - dbf.setFeature("http://xml.org/sax/features/external-general-entities", false); dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false); или их обязательно нужно сохранить. Если это обязательно, какие уязвимости, если мы не установим для них значение false?

Приведите пример уязвимости, относящейся к внешним общим/параметрическим объектам, даже если для disallow-doctype установлено значение true, для XIncludeAware — значение false, а для ExpandEntityReferences — значение false.


person Venkata Rami Reddy    schedule 21.01.2019    source источник


Ответы (1)


Их сохранение не является обязательным. Установка disallow-doctype-decl предотвратит атаки XXE, поскольку любые встроенные объявления DOCTYPE в ненадежном XML заставят синтаксический анализатор выдать исключение.

Однако я рекомендую оставить код как есть, так как external-general-entities и external-parameter-entities по умолчанию true< /а>. Если этих двух строк нет, а более поздний сопровождающий (наивно или по ошибке) удалит первую строку, код снова станет уязвимым. Наличие других строк в явном виде повышает вероятность того, что при дальнейшей модификации сопровождающий будет искать эти функции и, как мы надеемся, узнает, почему они здесь.

person K Eno    schedule 01.03.2019