Безопасные загрузки файлов: права доступа, лимиты, подписанные URL и сканирование

Почему загрузки файлов рискованны (простыми словами)

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

Риск — это не только «кто‑то загрузил вирус». Неправильная загрузка может слить приватные файлы, раздуть счёт за хранение или заставить пользователей отдать доступ. Файл с именем “invoice.pdf” может вовсе не быть PDF. Даже настоящие PDF и изображения могут создать проблемы, если приложение доверяет метаданным, автоматически генерирует превью или отдает их с неправильными правилами.

Типичные провалы выглядят так:

• Кто‑то угадывает URL файла и скачивает документ другого пользователя.
• Загруженный HTML-файл подаётся как веб‑страница и показывает форму для кражи логина.
• Атакующий многократно загружает огромные файлы, пока приложение не замедлится или не упадёт.
• «Безопасный» тип файла подделывают, после чего сотрудник открывает его во внутренней сети.

Одна деталь объясняет многие инциденты: хранение файлов — это не то же самое, что их выдача. Хранение — где вы держите байты. Выдача — как вы доставляете эти байты в браузеры и приложения. Проблемы возникают, когда приложение отдает пользовательские загрузки с тем же уровнем доверия и правилами, что и основной сайт, и браузер считает загрузку «доверенной».

«Достаточно безопасно» для малого или растущего приложения обычно означает, что вы можете честно ответить на четыре вопроса без уклончивости: кто может загружать, что вы принимаете, какой размер и как часто, и кто сможет читать файл позже. Даже если вы быстро собираете продукт (сгенерированный код или платформа на основе чата), эти ограждения важны.

Простая модель угроз для загрузок

Относитесь к каждой загрузке как к недоверенному входу. Практический способ защитить загрузки — представить, кто может злоупотребить ими и что для него будет «успехом».

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

Чего они хотят? Обычно одно из следующих:

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

Затем сопоставьте слабые точки. Эндпоинт загрузки — это входная дверь (слишком большие файлы, странные форматы, высокая частота запросов). Хранилище — это задняя комната (публичные бакеты, неверные права, общие папки). URL для загрузки — это выход (предсказуемые, долгоживущие или не привязанные к пользователю).

Пример: функция «загрузить резюме». Бот загружает тысячи больших PDF, чтобы накрутить расходы, а злоумышленник заливает HTML-файл и выдаёт его за «документ», чтобы обмануть других.

Прежде чем вводить контролы, решите, что важно для вашего приложения: приватность (кто может читать), доступность (можете ли вы продолжать отдавать), стоимость (хранение и трафик) и соответствие требованиям (где хранится данные и как долго). Этот список приоритетов поможет принимать согласованные решения.

Права доступа и контроль, которые реально работают

Большинство инцидентов с загрузками — это не сложные взломы. Это простые баги «я вижу чужой файл». Рассматривайте права как часть механики загрузок, а не как дополнительную фичу.

Начните с одного правила: по умолчанию отказ. Считайте каждый загруженный объект приватным, пока вы явно не разрешили доступ. «Приватно по умолчанию» — хорошая база для счетов, медицинских документов, документов аккаунта и всего, что привязано к пользователю. Делайте файлы публичными только когда пользователь этого явно ожидает (например, публичный аватар), и даже тогда подумайте о временном доступе.

Роли, соответствующие реальным задачам

Держите роли простыми и разделёнными. Частое разделение:

• Uploader: может создавать загрузки для своей учётной записи
• Viewer: может скачивать файлы, которые ему разрешены
• Support: имеет доступ к файлам только по временной и аудитируемой выдаче прав
• Admin: управляет политиками, но не должен автоматически читать всё

Не полагайтесь на правила уровня папки вроде «всё в /user-uploads/ ок». Проверяйте владение или доступ тенанта при чтении каждого файла. Это защитит, когда кто‑то меняет команду, уходит из организации или файл переназначают.

Хорошая модель для поддержки — узкая и временная: дать доступ к одному конкретному файлу, залогировать и автоматически истечь.

Валидировать тип файла, не доверяя клиенту

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

Начните с allowlist: решите, какие точные форматы вы принимаете (например, .jpg, .png, .pdf) и отвергайте всё остальное. Избегайте «любое изображение» или «любой документ», если вам действительно не нужно такое широкое принятие.

Не доверяйте расширению имени файла или заголовку Content-Type от клиента. Их легко подделать. Файл с именем invoice.pdf может быть исполняемым, а Content-Type: image/png — ложью.

Надёжнее инспектировать первые байты файла, часто называемые «magic bytes» или сигнатурой файла. Многие форматы имеют стабильные заголовки (PNG, JPEG). Если заголовок не соответствует разрешённому формату — отклоняйте.

Практичная схема валидации:

• Allowlist расширений на сервере
• Определяйте MIME‑тип на сервере (не доверяйтесь клиентскому заголовку)
• Проводите sniffing по magic bytes для поддерживаемых форматов
• Генерируйте случайное имя для хранения и сохраняйте оригинальное имя как метаданные
• Блокируйте рискованные форматы, особенно HTML, SVG и скриптоподобное содержимое

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

Для фото профиля принимайте только JPEG и PNG, проверяйте заголовки и очищайте метаданные если возможно. Для документов ограничьте PDF и отвергайте всё с активным содержимым. Если позже решите поддержать SVG или HTML — относитесь к ним как к потенциально выполняемым и изолируйте.

Ограничения по размеру, лимиты частоты и основы DoS

Большинство простоев при загрузках — это не «умные» хакерские приёмы. Это гигантские файлы, слишком много запросов или медленные соединения, которые загружают серверы до отказа. Считайте каждый байт затратой.

Устанавливайте лимиты по фиче

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

Применяйте ограничения в нескольких местах, потому что клиент может врать: в логике приложения, на веб‑сервере/реверс‑прокси, с таймаутами загрузки и с ранним отклонением, когда заявленный размер слишком велик (до чтения всего тела).

Конкретный пример: аватары — до 2 MB, PDF — до 20 MB, всё большее — через другой поток (например, прямой upload в объектное хранилище с подписанным URL).

Лимиты частоты и контроль злоупотреблений

Даже маленькие файлы могут привести к DoS, если их загружают бесконечно. Добавьте rate limit для эндпоинтов загрузки по пользователю и по IP. Для анонимных запросов сделайте ограничения строже.

Возобновляемые (resumable) загрузки помогают реальным пользователям с плохой связью, но session‑токен должен быть жёстким: короткий срок жизни, привязан к пользователю и к конкретному размеру/назначению файла. Иначе endpoint «resume» станет бесплатной трубой в ваше хранилище.

Когда вы блокируете загрузку, возвращайте понятные пользователю ошибки (файл слишком большой, слишком много запросов), но не раскрывайте внутренности (стектрейсы, имена бакетов, детали поставщика).

Безопасные решения для хранения и выдачи файлов

Безопасные загрузки — это не только то, что вы принимаете. Это также где файл хранится и как вы его отдаёте.

Не храните байты файлов в основной базе данных. Большинству приложений нужна только метаинформация в БД (ID владельца, оригинальное имя, определённый тип, размер, контрольная сумма, ключ хранилища, время создания). Байты держите в объектном хранилище или сервисе, предназначенном для больших BLOB.

Разделяйте публичные и приватные файлы на уровне хранения. Используйте разные бакеты/контейнеры с разными правилами. Публичные файлы (публичные аватары) могут читаться без логина. Приватные файлы (контракты, счета, медицинские документы) никогда не должны быть общедоступными, даже если кто‑то угадает URL.

По возможности не отдавайте пользовательские файлы с того же домена, что и основное приложение. Если рискованный файл просочится (HTML, SVG со скриптами или странности MIME sniffing), хостинг на основном домене может привести к захвату аккаунтов. Отдельный домен загрузок или домен хранилища ограничит радиус поражения.

При скачивании заставляйте безопасные заголовки. Ставьте предсказуемый Content-Type на основе разрешённых типов, а не того, что утверждает пользователь. Для всего, что браузер может интерпретировать, предпочитайте отдавать как скачивание.

Несколько дефолтов, предотвращающих сюрпризы:

• Используйте Content-Disposition: attachment для документов.
• Устанавливайте безопасный Content-Type (или application/octet-stream).
• Храните и отдавайте с непрозрачными ключами объектов (не пользовательские имена).
• Логируйте скачивания приватных файлов.

Хранение — это также безопасность. Удаляйте брошенные загрузки, удаляйте старые версии после замены и ставьте срок жизни для временных файлов. Менее данных — меньше риска утечки.

Подписанные URL: когда использовать и как ужесточить

Подписанные URL (pre-signed) — распространённый способ позволить пользователям загружать или скачивать файлы, не делая бакет публичным и не пропуская каждый байт через ваш API. В URL заложено временное разрешение, затем оно истекает.

Два распространённых потока:

• Прямая загрузка в хранилище: ваше приложение выдаёт короткоживущий подписанный URL, и браузер загружает прямо в объектное хранилище.
• Загрузка через сервер: файл попадает сначала на ваш API, затем сервер сохраняет его.

Прямая загрузка снижает нагрузку на API, но делает правила хранилища и ограничения в URL еще более критичными.

Как сделать подписанные URL жёсткими

Относитесь к подписанному URL как к одноразовому ключу. Делайте его специфичным и с коротким сроком жизни.

• Истекайте write‑URL быстро (обычно 1–5 минут). Читайте URL лучше держать минуты, а не дни.
• Привязывайте URL к точному ключу объекта (один объект, не папка).
• Добавляйте ограничения, где это поддерживается: ожидаемый content type, максимальный размер, контрольная сумма.
• Выдавайте URL только после проверки прав.
• Логируйте, кто запросил URL и зачем (user ID, ключ объекта, цель, IP/UA).

Практичный паттерн: сначала создайте запись загрузки (status: pending), затем выдайте подписанный URL. После загрузки проверьте, что объект существует и соответствует ожидаемому размеру и типу, прежде чем пометить его как готовый.

Пошагово: безопасный поток загрузки, который можно реализовать

Безопасный поток — это в основном ясные правила и понятные состояния. Относитесь к каждой загрузке как к недоверенной, пока проверки не пройдут.

Опишите, что каждая фича позволяет. Фото профиля и налоговый документ не должны использовать одинаковые типы файлов, лимиты размера или видимость.

Практичный поток (с реальными статусами)

1. Определите допустимые типы и лимит размера по фиче (например: фото до 5 MB; PDF до 20 MB). Применяйте те же правила на бэкенде.

2. Создайте «запись загрузки» до прихода байтов. Храните: владелец (пользователь или организация), назначение (avatar, invoice, attachment), оригинальное имя файла, ожидаемый макс. размер и статус вроде pending.

3. Загружайте в приватное местоположение. Не позволяйте клиенту выбирать конечный путь.

4. Снова проверьте на сервере: размер, magic bytes/тип, allowlist. Если прошло — переведите статус в uploaded.

5. Просканируйте на вредоносное ПО и обновите статус на clean или quarantined. Если сканирование асинхронное, держите доступ закрытым пока ждёте.

6. Разрешайте скачивание, превью или обработку только при статусе clean.

Небольшой пример: для фото профиля создайте запись, привязанную к пользователю с целью avatar, храните приватно, подтвердите, что это реально JPEG/PNG (а не просто переименованный файл), просканируйте, затем сгенерируйте превью URL.

Базовые шаблоны сканирования на вредоносное ПО (без обещаний)

Сканирование — это страховочная сетка, а не гарантия. Оно ловит известные плохие файлы и очевидные трюки, но не всё. Цель простая: снизить риск и по умолчанию сделать неизвестные файлы безвредными.

Надёжный паттерн — сначала карантин. Сохраняйте каждую новую загрузку в приватном месте и помечайте как pending. Только после прохождения проверок перемещайте в «clean» (или помечайте как доступный).

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

Что обычно включает «базовое сканирование»

Базовое сканирование обычно — это антивирусный движок (или сервис) плюс несколько правил: AV‑скан, проверки типа файла (magic bytes), лимиты для архивов (zip bomb, вложенные zip, огромный распакованный размер) и блокировка форматов, которые вам не нужны.

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

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