Маленький ZIP занял весь диск: какие лимиты нужны импорту

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

Почему размер вложения ничего не говорит о запасе диска

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

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

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

Бюджет операции: что считать отдельно

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

Учебный расчёт, который можно перенести в ТЗ

Допустим, вы проектируете небольшой импорт. Условные ограничения: вход до 40 MiB, один извлечённый элемент до 100 MiB, весь результат до 300 MiB и до 1000 элементов. Одновременно допускаются два задания. Эти числа выбраны для примера, а не предложены как отраслевой стандарт.

Два результата могут занимать до 2 × 300 = 600 MiB. Две исходные загрузки добавляют до 2 × 40 = 80 MiB. Значит, только эти две категории хранения требуют до 680 MiB в рамках допущений. Здесь MiB означает 1 048 576 байт.

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

Для своего бюджета возьмите реальные штатные выгрузки и замерьте расходы в безопасной среде. Затем согласуйте, какой объём поддерживает продукт и как клиент делит более крупный пакет. Бесконечное увеличение предела скрывает ограничение, но не устраняет его.

Объявленный размер и фактическая гарантия библиотеки

Нельзя одинаково трактовать метаданные всех архивных API. В приведённом примере Microsoft для .NET указана гарантия ограничения выдаваемых байтов значением длины элемента; это используется при проверке размера. Для другого обработчика такую гарантию нужно подтвердить по его документации.

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

В памятке OWASP по загрузкам отдельно сказано учитывать размер после распаковки, если сервис извлекает файлы. Внешнее расширение и входной размер не заменяют эту часть проверки.

Нужна ли автоматическая распаковка внутри распаковки

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

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

Извлечено ещё не значит принято

Распаковывайте в отдельное временное место под контролем приложения. Microsoft также обращает внимание на границы каталога назначения. Проверка путей и содержимого остаётся самостоятельной задачей: соблюдение лимита объёма не делает любой извлечённый файл допустимым.

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

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

Что проверить до запуска импорта

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

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