Какие проблемы безопасности возникают, когда пользователи могут загружать свои собственные файлы?

Ответ 1

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

Валидация расширения файлов, вероятно, является хорошей второй строкой защиты. Проверка типов может быть выполнена позже... если вы не полагаетесь на (mim-type) пользователя для указанной проверки.

Почему проверка расширений файлов? Потому что большинство веб-серверов используют для идентификации исполняемых файлов. Если ваши исполняемые файлы не заблокированы до определенного каталога (и, скорее всего, это не так), файлы с определенными расширениями будут выполняться в любом месте под корнем документа сайта.

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

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

Я уверен, что есть другие проблемы, которые я пропустил, но, надеюсь, это помогает.

Ответ 2

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

Пользователи не смогут загружать zip файлы или действительно какой-либо файл без изображения, потому что библиотека изображений будет работать, если попытается изменить размер данных без изображения, и вы можете просто поймать исключение. Вероятно, вы захотите сделать предварительную проверку расширения файла. Нет смысла отправлять файл через библиотеку изображений, если имя файла "foo.zip".

Что касается разрешений, ну... не устанавливайте бит выполнения. Но реалистично, разрешения не будут сильно защищать вас от вредоносного ввода пользователя.

Если ваша среда программирования позволяет это сделать, вы захотите выполнить некоторые из этих проверок во время загрузки. Злонамеренный HTTP-клиент может отправить файл с бесконечным размером. IE, он просто никогда не прекращает передавать случайные байты, что приводит к атаке отказа в обслуживании. Или, может быть, они просто загружают концерт видео в качестве изображения своего профиля. Большинство форматов файлов изображений имеют заголовок и в начале. Если клиент начинает отправлять файл, который не соответствует известному заголовку изображения, вы можете прервать передачу. Но это начинает переходить в царство излишества. Если вы не Facebook, такого рода вещи, вероятно, не нужны.

Edit

Если вы разрешаете пользователям загружать скрипты и исполняемые файлы, вы должны убедиться, что ничего, загруженное с помощью этой формы, никогда не возвращается ничем, кроме application/octet-stream. Не пытайтесь смешивать Content-Type, когда вы имеете дело с потенциально опасными загрузками. Если вы собираетесь сообщать пользователям, что им приходится беспокоиться о своей собственной безопасности (что эффективно, что вы делаете, когда принимаете скрипты или исполняемые файлы), тогда все должно быть представлено как application/octet-stream, чтобы браузер не пытался его отобразить, Вероятно, вы также должны установить заголовок Content-Disposition. Вероятно, также целесообразно задействовать антивирусный сканер в конвейере, если вы хотите иметь дело с исполняемыми файлами. ClamAV является скриптовым и открытым исходным кодом, например.

Ответ 3

было бы полезно также проверить размер, не хотелось бы, чтобы кто-то намеренно загружал поддельное изображение размером 100 гб только из-за злобы, если бы вы:)

Кроме того, вы можете подумать над тем, чтобы люди не могли использовать вашу пропускную способность просто для простого способа размещения изображений (в основном я бы занимался размещением незаконных материалов). В любом случае, большинство людей будут использовать imageshack для хостинга temp image.

Ответ 4

Для дальнейшего чтения есть замечательная статья Acunetix на Почему файлы для загрузки файлов являются серьезной угрозой безопасности

Ответ 5

С большим контекстом было бы легче узнать, где могут быть небезопасности.

Если данные могут быть сохранены в базе данных (звучит так, как будто этого не будет), вам следует защититься от SQL Injection.

Если данные могут отображаться в браузере (как это было бы), вам может потребоваться защита от HTML/CSS Injection атак.

Если вы используете языки сценариев (например, PHP) на сервере, вам может потребоваться защита от инъекционных атак против этих конкретных языков. С компилированным кодом сервера (или неудачной реализацией сценариев) существует вероятность переполнения буфера.

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

EDIT. Если вы действительно хотите охватить все базы, рассмотрите риски JPEG и WMF дыры в безопасности. Они могут быть использованы, если злоумышленник может загружать файлы из одной системы, а затем просматривать файлы - или убеждает другого пользователя просматривать файлы - из другой системы.

Ответ 6

Размер содержимого Ограничение определенных типов файлов (.jpeg,.png и т.д., Типы файлов с белым списком допускаются только) (например, для сайта, поддерживающего иностранные языки, допускается некоторая кодировка, хакер может воспользоваться этим и добавляет любой script/вредоносный код, закодированный и добавленный к исходному файлу, и пытается загрузить)