File Upload и его подводные камни
Всем привет. Сегодня хочу затронуть тему File Upload и то, почему этот функционал почти всегда является одним из самых чувствительных в приложении с точки зрения ИБ.
━━━━━━━━━━ Что такое File Upload ━━━━━━━━━━
File Upload — это механизм, при котором клиент отправляет файл на сервер, чаще всего через multipart/form-data. Сам по себе этот формат нормальный и стандартный, но важно понимать: поля вроде filename и Content-Type приходят от клиента, а значит доверять им “как есть” нельзя.
Где это встречается: • загрузка аватарки • загрузка изображения к посту • загрузка PDF или DOCX в поддержку • импорт CSV/Excel
━━━━━━━━━━ Почему это опасно ━━━━━━━━━━
File Upload опасен тем, что приложение начинает работать с чужим объектом, формат, содержимое и даже имя которого контролирует атакующий.
А дальше всё упирается в реализацию: • как проверяется расширение • как определяется MIME type • анализируется ли реальное содержимое файла • где файл хранится • можно ли его потом открыть напрямую • обрабатывается ли он сторонними библиотеками • есть ли лимиты по размеру и количеству
Если хотя бы одна из этих частей сделана слабо, дальше уже начинаются уязвимости.
━━━━━━━━━━ Основные риски File Upload ━━━━━━━━━━
➤ RCE / загрузка исполняемого файла Самый известный и самый опасный сценарий. Если сервер позволяет загрузить файл, который потом может быть интерпретирован как скрипт или выполнен через backend-компонент, это уже прямой путь к компрометации.
➤ Обход валидации типа файла Проверка только по расширению или только по Content-Type — слабая защита. Эти значения легко подменяются. На практике надо смотреть и на сигнатуры, и на реальное содержимое, и на то, как файл потом используется.
➤ XSS / XXE / parser-based атаки Опасность не только в “web shell”. Даже изображение, SVG, XML или офисный файл могут стать носителем другой атаки, если backend или frontend потом небезопасно его обрабатывает, парсит или отображает.
➤ DoS Слишком большие файлы, огромное количество загрузок, архивные бомбы, тяжёлая обработка изображений и файловых форматов — всё это легко превращается в отказ в обслуживании, если нет лимитов и контроля ресурсов.
➤ Path Traversal / overwrite Если имя файла используется небезопасно, можно получить перезапись существующих файлов или запись в неожиданные директории. Особенно опасно, когда приложение работает с путями “как пришло от клиента”.
➤ IDOR / утечки доступа Даже если сама загрузка реализована нормально, проблема часто всплывает дальше — на этапе хранения и выдачи. Файл может быть приватным, но отдаваться по предсказуемому ID, URL или имени без нормальной авторизации. Это уже ведёт к утечкам.
━━━━━━━━━━ Как обезопасить File Upload ━━━━━━━━━━
• строгий allowlist допустимых расширений и типов • серверная проверка MIME и сигнатуры файла, а не доверие к заголовкам клиента • переименование файла на стороне сервера • хранение вне web root • запрет прямого исполнения загруженных файлов • лимиты по размеру, количеству и частоте загрузок • отдельная проверка архивов, SVG, XML, PDF и офисных форматов • антивирусное или sandbox-сканирование там, где это уместно • выдача файлов только через контролируемый слой доступа • обязательная авторизация на скачивание приватных файлов • логирование и алерты на аномальные загрузки
━━━━━━━━━━ Итог ━━━━━━━━━━
File Upload — это не “мелкий технический endpoint”.
Это одна из самых чувствительных точек приложения, потому что через неё атакующий приносит на сервер свой объект, а дальше уже пытается заставить систему неправильно его принять, обработать, сохранить или отдать.
Именно поэтому безопасный File Upload — это всегда не одна проверка, а цепочка защит: • валидация • изоляция • безопасное хранение • контроль доступа • безопасная обработка
