Чтобы сделать это как можно короче: недавно внимание нашего системного администратора было доведено (как и должно быть), что одним из требований для нашего последнего веб-проекта будет разрешение клиентам выполнять загрузку файлов. В частности, это будут в первую очередь изображения и, возможно, видео [но, как я уверен, вы знаете, вы не можете гарантировать, каково точное содержимое загрузки, пока оно не будет на сервере].
Системный администратор был немного сбит с толку и едва успел сказать вопиющее «Нет!».
Я знаком со многими передовыми практиками, касающимися ввода от пользователей, обработки загрузок и т. Д., Поэтому я очень уверен в закулисных аспектах / коде этого проекта. У меня вопрос, есть ли какие-то конкретные ресурсы или темы для разговора, которые могут помочь моему системному администратору? На чем мне сосредоточиться, чтобы объяснить ему подобные вещи, как с этим справляться и т. Д.?
Некоторые опасения вызывают потенциальное пространство для хранения (которое, как я знаю, необходимо рассчитывать на основе предполагаемой «популярности», умноженной на расчетный размер файла), и проблемы безопасности при размещении загруженного контента.
В конце концов, и вы, и администратор должны поддерживать потребности бизнеса. Задача состоит в том, чтобы найти правильный баланс функционального (загрузка файлов) и нефункционального (безопасность, стоимость диска, производительность) подходов.
Все, кто рекомендует проверять расширения файлов, чтобы убедиться, что вы в безопасности, безумны. Достаточно просто переименовать exe или mp3 в гифку. То же самое для типа загрузки MIME.
В только способ убедиться в типе загрузки - это проанализировать ее; поищите подписи файлов внутри файла, загрузите его в процессор изображений и посмотрите, не задыхается ли он и т.д.
Что еще вам нужно делать, зависит от вашей ОС и веб-сервера, но, как правило, загрузка не должна идти на отдельный диск, поэтому вы не убиваете свою ОС, когда кто-то загружает много-много файлов и занимает все пространство. Где бы они ни были загружены, они не должны содержать разрешений на выполнение, чтобы никто не мог запустить файл оттуда через браузер (на всякий случай, если это сценарий на любом используемом вами веб-языке), даже лучше не допускать прямых ссылок на него вообще, обслуживать файлы через служебную страницу с чем-то вроде GUID в качестве параметра (например, displayImage? id = 0000-000000-0000-0000)
И, конечно же, сканирование на вирусы, ограничение максимального размера загрузки (хотя будьте осторожны, IIS6, например, не может проверить длину потока на полпути, и поэтому будет сохранять загрузку в памяти до ее завершения, а затем передает ее в ваше приложение asp.net. )
Прочтите этот сайт: http://www.owasp.org/index.php/OWASP_Top_Ten
Вы заметите, что «загрузка магически поврежденного Apache» не является широко известной уязвимостью безопасности.
Обработка загрузки Apache жестяная банка быть испорченным - и сильно испорченным - но вы действительно должны работать над этим, игнорируя список уязвимостей OWASP.
Кроме того, ваш фреймворк, о котором вы не упомянули, содержит конкретные рекомендации по безопасной обработке загрузок. Если у него нет возможности для загрузки, то бегите - не ходите - к лучшей платформе.
«[, но, как я уверен, вы знаете, вы не можете гарантировать, каково точное содержимое загрузки, пока оно не будет на сервере]».
Это далеко не так. И не имеет значения, даже если это верно для вашего конкретного фреймворка.
Файлы проходят через буферы. Фреймворки Python делают загрузку доступной в кэше (если он большой) или в памяти (если он небольшой). Это не «в действительности» в файловой системе, даже если оно находится в кэше с файловой поддержкой. У него нет окончательного имени или разрешений - это просто байты.
Байты не повреждают Apache волшебным образом. Исполняемые файлы с тупым владельцем (и / или битом setuid в их разрешениях) портят Apache.
Хитрость с загрузкой заключается в том, чтобы (а) использовать кеширование вашего фреймворка, (б) проверить данные перед их сохранением в любом месте, (в) сохранить их где-нибудь, кроме исполняемого - где-то Apache не может искать исполняемые файлы, и (г) никогда chmod или chown что угодно при любых обстоятельствах. Неисполняемая загрузка может вызвать проблемы, если она названа .htaccess и вы записали его в каталог, откуда Apache получает это - действие, которое легко предотвратить, установив разрешения для этого каталога и никогда не называя загруженный файл .htaccess.
Уязвимостей на удивление мало. Они хорошо задокументированы. И ваша структура уже справляется с этим.
Если это жизненно важная часть бизнес-требований, я не понимаю, как он мог отказаться, если соблюдаются протоколы безопасности (то есть расширение / тип файла фильтра, тип MIME, размер файла и т. Д.)
Предполагая, что он является частью корпоративной лестницы (а не единственным системным администратором в компании), попробуйте пойти к его руководителю и объяснить вашу ситуацию.
Имейте в виду, что вы можете проверить тип загруженных файлов (используя определение типа MIME; есть различные способы сделать это в PHP или с помощью внешней утилиты, такой как file), и вы можете проверить их на вирусы, опять же, с помощью внешней утилиты.
Предположительно, после того, как вы обработали и проверили загруженный файл, вы переместите его в его окончательное местоположение и отклоните файлы, которые не проходят эти этапы; если это так, вы можете убедить своего администратора, что вы будете сохранять только «безопасные» файлы.
Вы можете начать с того, что спросите его, каковы его основные болевые точки в этой проблеме; обеспокоен ли он безопасностью / безопасностью, несет ответственность за публикацию контента, предоставляемого другими пользователями (и любых связанных с безопасностью последствий для конечных пользователей, которые возникают), или его беспокоят проблемы инфраструктуры - хранилище, сеть и т. д.
Примечание. «Безопасный» выше относится к безопасности в рамках выполненных проверок. Очевидно, вы не можете гарантировать абсолютную безопасность всего, что предоставляет пользователь.
Загрузка файлов может быть сложной в управлении с точки зрения безопасности и в целом.
Чтобы иметь достаточно безопасное приложение, вам необходимо ...
Тогда это также зависит от доверия, которое вы оказываете своим конечным пользователям. Если это интрасеть, где все отслеживается, вам не нужна такая безопасность, как общедоступный веб-сайт! Если пользователи известны, вам не придется так тщательно все проверять.
Еще одна хорошая проверка работоспособности - не загружайте файлы на диск, а храните их в базе данных. Это убивает классический «загрузите злой файл, затем выполните злой файл в контексте сервера», потому что файлы не существуют на сервере.
Теперь вы всегда можете лукаво подавать файлы для загрузки, если у вас есть проблемы с производительностью с файлами, поддерживаемыми базой данных.
Будучи тем админом, который сказал: «А, нет». разработчикам, просящим загрузить файлы на сервер, я могу рассказать вам, что я ищу в приложении, которое пытается это сделать. Основное ограничение заключается в том, что если мы не говорим о выделенном веб-сервере, размер наших веб-серверов не рассчитан на массовое файловое хранилище.
Одним из стартапов, над которым я работал несколько лет назад, был сайт загрузки видео и изображений на Linux (так что все мои примеры взяты из этого). Есть ряд вещей, которые могут пойти не так, если разрешить загрузку.
Все системы загрузки должны перекодировать исходный формат в ваш стандартный формат. У этого есть двоякая польза. Во-первых, теперь у вас есть стандартный формат, который значительно упрощает отображение изображений и видео в вашем HTML. Следующий, если вы в некоторой степени уверены, что вы изменили файл достаточно, чтобы не размещать зараженные файлы. Если вы планируете обслуживать необработанные загруженные файлы от любого пользователя с адресом электронной почты, у вас могут возникнуть проблемы.
Как уже упоминали другие люди, вам нужно немного больше, чем просто проверить расширение. Эту проблему решить немного сложнее. Мы сделали несколько попыток, которые мне никогда не понравились, но это того стоит по нескольким причинам. Важным является то, что у вас, вероятно, будет несколько путей для перекодирования видео. Видео поставляется во многих различных контейнерах вместе с несколькими миллионами комбинаций аудио- и видеодорожек. Чем больше вы знаете о файле, тем лучше вы сделаете выбор, как его обработать или окончательно отклонить.
Предполагая, что вы перекодируете файлы, вы уязвимы для эксплойтов в ваших библиотеках обработки, таких как ffmpeg или libgd. Мы записывали исходный файл на диск в общей папке NFS, а затем запускали обработку в среде jail / chroot. Это позволило нам перекодировать в новый формат или выйти из строя в одном каталоге без заражения сервера или каких-либо других файлов. Кроме того, ваша система перекодирования должна быть очень актуальной, поэтому вам нужно проверять свой дистрибутив каждую ночь, чтобы убедиться, что базовые библиотеки, такие как libpng, libtiff, libmad, libdv и т. Д., Не имеют текущих ошибок безопасности.
Возвращаясь к исходному вопросу, убедитесь, что вы решаете проблемы, на которые указали все, и у вас не должно быть проблем с привлечением вашего системного администратора, и в конечном итоге у вас будет гораздо лучшее приложение. К сожалению, работа вашего системного администратора - сказать «нет» вещам, которые выглядят так, как будто они станут операционным кошмаром для поддержки.