XML External Entity Injection [XXE]
1. Введение:
Эта атака происходит, когда недоверенный XML-ввод, содержащий ссылку на внешнюю сущность, обрабатывается слабо настроенным XML-парсером.
Она может привести к раскрытию конфиденциальных данных, отказу в обслуживании, подделке запросов на стороне сервера (SSRF), сканированию портов с точки зрения машины, на которой расположен парсер, и другим последствиям для системы.
2. Типичный уязвимый код:
Атака XXE работает, используя возможности XML, а именно XML eXternal Entities (XXE), которые позволяют загружать внешние XML-ресурсы в XML-документ.
Передав XML-файл, определяющий внешнюю сущность, с URI file://, злоумышленник может эффективно обмануть парсер SAX (Simple API parser for XML) приложения и заставить его прочитать содержимое произвольного файла (файлов), находящегося в файловой системе сервера.
Наконец, мы используем XML-декларацию ENTITY для загрузки дополнительных данных с внешнего ресурса. Синтаксис объявления ENTITY таков: ENTITY name SYSTEM URI, где URI - это полный путь к удаленному URL или локальному файлу. В нашем примере мы определяем тег ENTITY для загрузки содержимого файла "file:///etc/passwd".
Это пример того, как может выглядеть XML-файл "полезной нагрузки".
Когда этот XML-документ обрабатывается уязвимым парсером, таким как представленный выше, все экземпляры &bar; будут заменены содержимым файла /etc/passwd.
Проще говоря, XML-парсер был обманут, чтобы получить доступ к ресурсу, который разработчики приложения не планировали делать доступным, в данном случае к файлу в локальной файловой системе удаленного сервера. Благодаря этой уязвимости можно было получить любой файл на удаленном сервере (точнее, любой файл, к которому веб-сервер имеет доступ на чтение).
К сожалению, парсер SAX не был настроен на запрет загрузки внешних сущностей (деклараций DOCTYPE), которые, будучи указанными в нашем модифицированном файле payload.xml, могут быть использованы злоумышленником для чтения произвольных системных файлов на удаленном сервере.
Поскольку пользовательский XML-ввод поступает из "недоверенного источника" (а именно, от клиента), очень трудно должным образом проверить XML-документ, чтобы предотвратить этот тип атаки.
3. Смягчение последствий:
2.1. Отключение встроенного DTD:
Поскольку мы знаем, что парсер технически не должен позволять загружать внешние сущности (любой вид объявления DOCTYPE), мы можем настроить XML-парсер на использование только локально определенного определения типа документа (DTD) и запретить любые встроенные DTD, указанные в пользовательском XML-документе (документах).
Из-за того, что существует множество движков для разбора XML, каждый из них имеет свой собственный механизм отключения встроенных DTD для предотвращения XXE. Возможно, вам придется поискать в документации к вашему XML-парсеру, как именно "отключить inline DTD".
Вот несколько примеров того, как можно отключить парсинг встроенного DTD.
2.2. Следуйте принципу наименьших привилегий:
Угроза XXE-атак полностью иллюстрирует важность соблюдения принципа наименьших привилегий, который гласит, что программным компонентам и процессам должен быть предоставлен минимальный набор разрешений, необходимых для выполнения их задач.
Поскольку у парсера XML редко бывают веские причины для выполнения исходящих сетевых запросов, рассмотрите возможность блокировки исходящих сетевых запросов для вашего веб-сервера в целом. Если вам все же необходим исходящий сетевой доступ: например, если код вашего сервера обращается к API сторонних разработчиков, - вам следует внести домены этих API в белый список правил брандмауэра.
3. Выводы:
Общеизвестно, что DTD - это устаревшая технология, поэтому разрешение на использование встроенных DTD - это ВСЕГДА НЕПРАВИЛЬНАЯ ИДЕЯ! Современные парсеры XML по умолчанию защищены от атак, и поэтому использование таких фреймворков или парсеров означает, что вы уже защищены от атак.
Last updated