Размер файла кажется естественной мерой опасности: десять мегабайт выглядят опаснее десяти килобайт, а несколько сотен байт кажутся безобидными. Но программа обрабатывает не «вес» файла, а команды и значения внутри него. Крошечный вход способен запустить огромный объём вычислений или потребовать гигабайты памяти.
Свежий пример с Telegram наглядно показал, что размер не имеет значения. Специально сформированный TGS/Lottie-стикер весом 269 байт содержал значение порядка 1038 точек для векторной фигуры. Клиент пытался отрисовать объект, резко расходовал ресурсы и завершался. Дорого стоил не сам файл, а его интерпретация.
Почему маленький файл может оказаться очень «тяжёлым»
У любого формата есть два масштаба. Первый показывает объём входных данных на диске или в сети. Второй описывает работу после чтения файла. Между ними нет линейной связи. Несколько байт могут задавать размер холста, число повторений, глубину структуры или количество объектов, которые программа попытается создать.
Классический пример представляет ZIP-бомба. Хорошо повторяющиеся данные сильно сжимаются, поэтому компактный архив после распаковки способен превратиться в гигабайты. Более сложные варианты используют вложенные архивы. Лимит «не больше 10 МБ на загрузку» такой файл пропустит, хотя итоговая нагрузка окажется несравнимо выше.
Похожая асимметрия встречается и без архивов. XML может многократно раскрывать сущности, JSON способен содержать чрезмерно глубокие структуры, а неудачное регулярное выражение заставляет движок перебирать огромное число вариантов. Вход остаётся небольшим, но стоимость обработки растёт намного быстрее его размера.
| Сценарий | Что скрывает маленький вход | Главный расход |
|---|---|---|
| ZIP bomb | Большой объём после распаковки | Память, диск |
| XML/JSON bomb | Рекурсия и вложенность | Память, стек |
| ReDoS | Перебор совпадений | CPU |
| Изображение | Аномальное число пикселей | Память |
| Lottie/SVG | Сложная геометрия | CPU, память |
Архивы, картинки, Lottie и ReDoS
Графические форматы хорошо показывают проблему. Файл может хранить не готовую сетку пикселей, а параметры будущего изображения. Если декодер доверяет аномальной ширине и высоте, он попытается выделить огромный буфер. Поэтому библиотека Pillow ограничивает число пикселей и отдельно предупреждает о «decompression bomb».
Векторная графика добавляет другой риск. SVG и Lottie описывают фигуры, кривые и анимацию командами. Несколько чисел способны задать сцену, построение которой потребует огромного числа операций. Случай с Telegram наглядно показывает разницу между размером описания и сложностью результата.
ReDoS расходует уже не память, а процессорное время. Уязвимое регулярное выражение может снова и снова возвращаться назад и проверять почти одинаковые варианты разбиения строки. Для специально подобранного ввода число попыток иногда растёт экспоненциально, поэтому короткая строка надолго занимает ядро процессора.
XML-атака «Billion Laughs» строится на многократном раскрытии сущностей. Небольшой документ заставляет парсер размножать один фрагмент до огромного объёма. Для JSON чаще опасна чрезмерная глубина вложенности, способная довести рекурсивный обработчик до переполнения стека или долгого разбора.
Почему лимит размера не спасает и что действительно помогает
Проверка размера загрузки полезна, но контролирует только вход. Сервер может отклонить файл на 200 МБ и принять архив на 50 КБ, который после распаковки займёт гигабайты. Безопасный парсер ограничивает ещё и последствия обработки: итоговый размер, глубину, число объектов, размеры изображения, время работы и объём памяти.
- ограничивать итоговый размер и коэффициент распаковки;
- задавать максимальную глубину XML, JSON и других структур;
- проверять числовые параметры до выделения памяти и рендера;
- ограничивать число точек, пикселей, кадров и объектов;
- ставить таймауты и лимиты CPU и памяти для недоверенных данных.
Хорошая защита сначала оценивает предполагаемую стоимость операции и только потом выделяет ресурсы. Если файл просит «нарисовать 1038 точек», рендерер должен отвергнуть значение до запуска цикла. Для особенно рискованных форматов полезна изоляция в отдельном процессе или контейнере с жёсткими лимитами.
Поэтому маленький файл вполне может стать инструментом DoS. Опасность рождается из разницы между дешёвым запросом и дорогой реакцией программы. ZIP-бомбы лишь самый известный пример. Та же логика работает в анимациях, изображениях, XML, JSON, регулярных выражениях и других форматах, где вход управляет объёмом последующих вычислений.
FAQ: часто задаваемые вопросы
Что такое ZIP bomb?
ZIP bomb представляет собой сильно сжатый архив, который после распаковки создаёт несоизмеримо больший объём данных и может исчерпать память или место на диске.
Может ли файл на несколько сотен байт зависнуть приложение?
Да. Маленький файл способен задать огромные размеры, глубокую рекурсию, множество объектов или крайне дорогой алгоритм.
Чем decompression bomb отличается от вируса?
Decompression bomb не обязана содержать вредоносный код. Атака использует распаковку или разбор данных, чтобы исчерпать ресурсы системы.
Почему ограничение размера файла не защищает от DoS?
Лимит контролирует только исходный объём, тогда как после распаковки, декодирования или рендера нагрузка может вырасти на порядки.
Как защитить парсер от архивных бомб и сложных файлов?
Нужно ограничивать итоговый размер, глубину, число объектов, допустимые параметры, время обработки, память и CPU.
