Какие проблемы безопасности возникают, когда пользователи могут загружать свои собственные файлы? - PullRequest
14 голосов
/ 06 мая 2009

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

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

Это более общий вопрос, чем вопрос о конкретной ситуации, так каковы лучшие практики в этой ситуации? Что ты обычно делаешь?

Я полагаю: проверка типа при загрузке, различные разрешения для загружаемых файлов ... что еще?

РЕДАКТИРОВАТЬ : Чтобы прояснить контекст, я думаю о веб-приложении, где пользователь может загрузить любой тип файла и затем отобразить его в браузере. Файл будет храниться на сервере. Пользователи - это те, кто использует веб-сайт, поэтому доверие не требуется.

Я ищу общие ответы, которые могут применяться для разных языков / сред и производственных сред.

Ответы [ 6 ]

8 голосов
/ 06 мая 2009

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

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

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

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

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

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

5 голосов
/ 06 мая 2009

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

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

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

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

Редактировать

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

1 голос
/ 22 октября 2014

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

1 голос
/ 06 мая 2009
Проверка размера

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

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

0 голосов
/ 09 апреля 2014

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

0 голосов
/ 06 мая 2009

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

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

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

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

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

РЕДАКТИРОВАТЬ : Если вы действительно хотите охватить все базы, учтите риски, связанные с JPEG и WMF дырами в безопасности. Они могут быть использованы, если злонамеренный пользователь может загрузить файлы из одной системы, а затем просмотреть файлы - или убедить другого пользователя просмотреть файлы - из другой системы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...