РУКОВОДСТВО · ОБНОВЛЕНО 2026-11-01
XML из ответа нейросети: как не разрешить внешние сущности при разборе
Проверка недоверенного документа до запуска XML-процессора и бизнес-логики.
XML, полученный от модели, остаётся недоверенным вводом. Он может повторить конструкцию из исходного документа или содержать неожиданные объявления. Если парсер разрешает внешние сущности, разбор способен обратиться к ресурсу вне переданного текста. Выберите безопасную конфигурацию конкретной библиотеки, запретите ненужные DTD и внешние обращения, ограничьте ресурсы. Проверка схемы и просьба модели не писать опасные элементы не заменяют эти меры. Безопасность должна действовать до интерпретации документа, а не после того, как текст уже полностью обработан.
1. Определите нужный поднабор XML
Опишите обязательные элементы, атрибуты и допустимый размер документа. Если приложению не нужны DTD, внешние сущности и подключения, не разрешайте их ради универсальности. Выберите библиотеку с документированными параметрами и проверьте текущие значения по умолчанию. Не переносите имя опции из другого языка. OWASP приводит рекомендации для разных XML-процессоров: общий принцип один, но конкретные безопасные настройки и версии отличаются. Привяжите конфигурацию к используемой зависимости и её обновлениям.
2. Ограничьте внешние обращения до разбора
Отключите разрешение внешних сущностей и ненужную загрузку DTD, а при необходимости схем используйте контролируемый локальный источник. Ограничьте сетевой доступ процесса отдельно, чтобы ошибка настройки не превращалась в произвольную загрузку. Не считайте предварительный поиск подстроки в XML полноценной защитой: синтаксис и обработка сущностей сложнее одной проверки текста. Модель не должна выбирать адрес схемы или локального файла, если бизнес-контракт этого явно не требует и не ограничивает.
3. Проверьте ресурсы и структуру
Ограничьте размер исходного текста, глубину вложенности, количество узлов и время работы согласно возможностям вашей среды. Ошибку разбора отделяйте от ошибки схемы и от неверного бизнес-значения. Только после безопасного получения структуры проверяйте типы, диапазоны и допустимые поля. Корректная структура не доказывает правильность извлечённых сведений. Не пытайтесь восстановить произвольный повреждённый XML бесконечным циклом запросов к модели; предусмотрите понятное завершение и сохранение безопасной причины отказа.
4. Протестируйте политику без внешнего эффекта
Используйте изолированный стенд и собственные синтетические документы, проверяющие запрещённые возможности без чтения реальных секретов и без запросов к чужим адресам. Убедитесь, что отказ происходит до внешнего обращения и не запускает менее защищённый резервный парсер. Проверьте обычный допустимый XML и пограничную вложенность, чтобы защита не ломала необходимый сценарий. В журнал записывайте категорию ошибки и идентификатор задания, а не всё содержимое пользовательского документа или путь к закрытому ресурсу.
Частые вопросы
Достаточно ли попросить модель вернуть только безопасный XML?
Нет. Вывод может содержать скопированный недоверенный текст. Политику должен обеспечивать парсер и его окружение до обработки структуры.
Защищает ли проверка XSD от XXE автоматически?
Не следует на это рассчитывать. Способ получения схемы и разбор XML тоже нуждаются в безопасных настройках конкретного процессора.
Можно ли запретить XML совсем?
Если процессу достаточно другого формата, это может упростить контракт. Но выбранный формат всё равно требует проверки структуры, ресурсов и бизнес-значений.
Нужно ли запускать опасный пример на рабочем сервере?
Нет. Проверяйте отказ на изолированных синтетических данных без реальных секретов, внутренней сети и нагрузки на production.