Импорт XML: какие обращения нельзя разрешать парсеру

Безопасный импорт XML должен обрабатывать согласованный формат, не получая лишних прав читать внешние ресурсы. Если обмен не требует DTD, отключите их обработку средствами выбранного парсера. Отдельно проверьте загрузку схем, преобразования и лимиты: успешный разбор синтаксиса ещё не разрешает документу обращаться к файлам или сети.

Начните с документа обмена, а не с настройки сервера

Попросите владельца интеграции описать, что приходит в файле: какие сущности бизнеса, обязательные поля и правила совместимости. Фраза «поставщик присылает XML» не объясняет, нужны ли внешние определения. Разрешение возможностей по привычке делает границы обмена неопределёнными.

Полезно разделить два решения: какие данные клиент вправе передать и какие действия библиотека может совершить при их чтении. Даже договорённый поставщик способен отправить ошибочный файл. Его название в списке партнёров не заменяет настроек обработчика.

В описании XXE для Android риск связан с обработкой недоверенного XML и внешних сущностей при слабой конфигурации. Возможные последствия включают доступ к файловым данным и расход ресурсов. Это основание проверить настройки, а не утверждать, что каждый XML-файл опасен.

Составьте паспорт разрешённых возможностей

Предлагаемая таблица — рабочий документ для условной интеграции каталога товаров. Она не описывает настройки какого-либо действующего сервиса. В столбце с решением должны появиться ответы именно вашей команды, подтверждённые контрактом обмена.

Отключение DTD: проверьте конкретную библиотеку

В руководстве OWASP по XXE рекомендуется по возможности отключать DTD. Если они действительно необходимы, отдельно ограничивают разрешение внешних сущностей, загрузку внешних определений и развёртывание сущностей. Способы управления и исходное поведение различаются между парсерами.

Поэтому задание «поставить защитный флаг» недостаточно. Запишите язык, название библиотеки, её версию и фактический способ создания обработчика. Затем сверьте настройки с документацией этого интерфейса. Не переносите пример для одного движка на другой без проверки.

OWASP также рассматривает внешние ресурсы при валидации схем и преобразованиях, отдельно упоминает XInclude. Неподдерживаемая защитная настройка должна считаться ошибкой конфигурации, а не поводом продолжить обработку с неполной защитой. Это стоит включить в критерии запуска импорта.

Проследите весь путь файла

Нарисуйте последовательность: приём файла, разбор, проверка структуры, преобразование, подготовка записей и сохранение. Напротив каждого этапа укажите библиотеку и ответственного. Так легче увидеть второй обработчик, который не получает настройки первого.

Предположим, в учебной интеграции схема хранится в поставке приложения. Команда утверждает её вместе с релизом. Тогда в паспорте обмена логично закрепить именно этот источник и процедуру обновления, а не позволять каждому загруженному документу самостоятельно выбирать новые правила.

Если поставщик требует другой порядок, сначала согласуйте, чем он вызван. Возможно, нужен отдельный канал поставки схем или поддержка нескольких заранее известных версий. Решение о совместимости должно быть явным: его нельзя незаметно заменить разрешением любого внешнего обращения.

Защита от XXE не задаёт бюджет импорта

OWASP предупреждает, что предотвращение XXE не устраняет все варианты истощения ресурсов XML. Поэтому ограничения объёма и сложности нужно согласовать отдельно. Не объявляйте обработчик защищённым от перегрузки только потому, что внешние сущности отключены.

Мы советуем задавать бюджет по штатной задаче: допустимый размер документа, количество бизнес-записей, время обработки и доступную память исполнителя. Конкретные значения выбирают по измерениям своего обмена. Универсальное число из чужого примера не становится требованием к вашему каталогу.

Также договоритесь о результате превышения. Если импорт предназначен для целого документа, ошибка не должна выглядеть как полное успешное обновление. Сохраните прежнее рабочее состояние или предусмотрите явно описанное продолжение с учётом уже принятых записей.

Что дать пользователю при отказе

Оператору нужна причина, по которой он может действовать: неверная версия формата, недопустимая возможность или превышение согласованного бюджета. Подробности внутреннего устройства обработчика оставьте в защищённой диагностике. Не просите клиента присылать рабочие секреты для воспроизведения.

Удобный отчёт связывает номер импорта, время, версию обработчика и этап отказа. Исходный файл храните только по установленным правилам доступа и срока. Ошибку совместимости можно обсуждать с поставщиком на обезличенном фрагменте структуры и описании ожиданий.

План приёмки без опасных демонстраций

1. Утвердите формат, необходимые возможности XML и владельца схемы.
2. Зафиксируйте конкретный парсер, версию и документацию защитных настроек.
3. Проверьте конфигурацию каждого этапа, включая валидацию и преобразование.
4. В изолированной среде примите небольшой штатный документ с вымышленными данными.
5. Проверьте понятный отказ для несогласованного формата и ошибки конфигурации.
6. На безопасных ограниченных наборах проверьте бюджет и отсутствие частично принятого результата.
7. Сохраните критерии повторной проверки после замены библиотеки или изменения обмена.

Не нужно воспроизводить чтение системных файлов или обращения к внутренним сервисам, чтобы сформулировать эти требования. Для приёмки нужны согласованные свойства и наблюдаемые результаты в собственной среде. Обнаруженный непонятный параметр лучше разобрать с разработчиком до включения обмена.

В аудит API передайте паспорт обработчика и границы доверия. При разработке интеграции включите их в требования к обмену. А для доработки существующего импорта отдельно опишите, как сохраняется рабочее состояние при отказе.