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

У меня есть веб-сайт, на котором показаны галереи. Пользователи могут загружать свой собственный контент из Интернета (вводя URL-адрес) или загружая изображение со своего компьютера.

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

Есть ли здесь какие-либо рекомендации или лучшие практики относительно того, где мне их хранить?

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


image security storage asp.net-mvc
person leora    schedule 26.12.2010    source источник

Ответы (5)


arrow_upward
67
arrow_downward

Вы НЕ должны хранить загруженные пользователем файлы в любом месте, где к ним можно получить прямой доступ по известному URL-адресу в структуре вашего сайта. Это угроза безопасности, поскольку пользователи могут загружать файлы .htm и .js. Даже файл с правильным расширением может содержать вредоносный код, который может быть выполнен в контексте вашего сайта аутентифицированным пользователем, что позволяет проводить атаки на стороне сервера или на стороне клиента.

См., Например, http://www.acunetix.com/websitesecurity/upload-forms-threat.htm и Какая безопасность проблемы возникают, когда пользователи могут загружать свои собственные файлы?, в которых упоминаются некоторые проблемы, о которых вам необходимо знать, прежде чем вы разрешите пользователям загружать файлы, а затем представите их для загрузки на своем сайте.

  1. Не помещайте файлы в обычную структуру каталогов вашего веб-сайта.

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

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

  4. Не доверяйте mime-типам или расширениям файлов, откройте файл и измените его, чтобы убедиться, что он является тем, за что он претендует.

  5. Ограничьте размер и время загрузки.

person Ian Mercer    schedule 26.12.2010
comment
Хотелось бы немного подробнее узнать о № 3 и № 4. Обеспечивает ли изменение размера изображения? И под open it вы имеете в виду проверить первые байты, которые должны сообщить вам тип файла? - person Omar; 27.12.2010
comment
3. по существу исключает возможность того, что в файл изображения были включены поврежденные метаданные для атаки на какой-то плохо написанный браузер или другое программное обеспечение для изображений. 4. Да, убедитесь, что это действительно файл изображения с соответствующими метаданными изображения, соответствующими заявленному типу. Можете ли вы загрузить это в растровое изображение и т. Д.? Пользователи часто загружают на ваш сайт испорченные изображения, поэтому заранее отклонить их - хорошая идея. - person Ian Mercer; 27.12.2010
comment
вы упомянули, что не помещайте файлы в обычную структуру каталогов вашего веб-сайта. Но если я этого не сделаю, как я могу ссылаться на этот контент? - person leora; 30.01.2011
comment
@ooo Создайте метод действия, который возвращает FileResult. Действие принимает [уникальный, не поддающийся определению] идентификатор, присвоенный вами при загрузке, например Guid и возвращает файл изображения. - person Ian Mercer; 01.02.2011
comment
@Hightechrider - спасибо за ответ. Можете назвать рекомендуемое место? папка appdata ?? или вы говорите где угодно, кроме видимого URL в структуре веб-сайта - person leora; 26.08.2011
comment
@Hightechrider - есть ли отзывы по вопросу в моем последнем посте? - person leora; 30.08.2011
comment
Да нигде этого не видно. Загрузки обычно становятся большими, поэтому в большинстве случаев я помещаю их на отдельный диск / SAN / ... помещаю их на S3 / ... - person Ian Mercer; 09.09.2011
comment
Если вы используете размещенное решение, вы можете поместить в папку в структуре сайта, но запретить любой доступ: ‹authorization› ‹deny users = * /› ‹/authorization› - person Paul Tyng; 11.10.2011

arrow_upward
9
arrow_downward

В зависимости от ресурсов, которые у вас есть для реализации чего-то подобного, чрезвычайно выгодно хранить все это в Amazon S3.

Получив загрузку, вы просто отправляете ее на Amazon и вставляете URL-адрес в свою базу данных, как вы делаете с другими изображениями. Как упоминалось выше, вероятно, было бы разумно открыть изображение и изменить его размер перед отправкой. Это одновременно проверяет, что это на самом деле изображение, и гарантирует, что вы случайно не предоставите конечному пользователю изображение с полным разрешением камеры.

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

person dmnc    schedule 17.10.2011
comment
Мне нравится этот ответ, но вам также следует подумать о безопасности. Использование S3 минимизирует объем трафика, проходящего через ваш сайт. Но если вы хотите убедиться, что файл такой, какой они есть, я бы применил фильтр к изображению перед загрузкой в ​​s3, чтобы вы знали, что это изображение, и фильтр успешно. - person Angelom; 18.10.2011
comment
Действительно. Это было своего рода тем, что я имел в виду на шаге изменения размера, но в любом случае было бы неплохо иметь какую-либо хорошую надежную проверку, что у вас действительно есть реальное изображение. - person dmnc; 19.10.2011

arrow_upward
4
arrow_downward

Один из способов - сохранить изображение в таблице базы данных с полем varbinary.

Другой способ - сохранить изображение в папке App_Data и создать подпапку для каждого пользователя (~ / App_Data / [userid] /myImage.png).

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

person Trax72    schedule 11.10.2011
comment
У нас есть метод базы данных для статического общего контента на веб-сайтах. Мы используем его для вызова версий. Это хорошо работает, и мы можем сжать двоичный объект. - person Omnia9; 13.10.2011

arrow_upward
3
arrow_downward

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

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

См. Сообщение stackoverflow. и просмотрите список магических чисел

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

Вариант хранения зависит от ваших требований. См. этот пост также

Установите предел загрузки, установив для свойства maxRequestLength значение Web.Config, как это, где размер файла указан в КБ

<httpRuntime maxRequestLength="51200" executionTimeout="3600" />
person Prasanth    schedule 16.10.2011

arrow_upward
-2
arrow_downward

Вы можете сохранить свои доверенные данные параллельно с папкой htdocs/www, чтобы ни один пользователь не мог получить доступ к этой папке. Также вы можете добавить аутентификацию .htaccess к своим доверенным данным (для .htaccess вы должны хранить файл .htpasswd параллельно с папкой htdocs / www), если вы используете apache.

person Sanjay dev    schedule 18.10.2011