2011-01-20 3 views
1

ВведениеЗащищенный сервер файл

Я хочу создать веб-приложение Java, для хранения и резервного копирования файлов пользователей, похожие на Dropbox. Одна из интересных возможностей Dropbox заключается в том, что он может определить, существует ли определенный файл на сервере. Например, если один пользователь загружает файл на сервер, другому пользователю, который пытается загрузить тот же файл, не нужно будет загружать один и тот же файл. Серверу потребуется только отметить, что он имеет тот же файл. Это помогает сэкономить полосу пропускания/пространства и значительно увеличить скорость.

Наиболее простым решением этой проблемы является использование хеш-строки файла, например. sha1, md5 и т. д., чтобы идентифицировать файл. Клиентское программное обеспечение проверяет наличие определенного хеша на сервере или нет. Если он существует, он может пропустить процесс загрузки и отметить, что пользователь имеет тот же файл.

Проблема

Веб-приложение реализовано на основе REST архитектуры, так что пользователь может легко написать свое собственное программное обеспечение клиента, чтобы загрузить свои файлы. По соображениям безопасности SSL включен для всех транзакций. Но моя самая озабоченность по поводу безопасности связана с тем, что пользователи притворяются, что у них есть файл без фактического владения им, если я использую sha1 или любые другие стандартные алгоритмы хеша. Это не может быть предотвращено с помощью SSL или шифрования. Если пользователю удастся получить хэш-строку, например. md5 и sha1 из многих файлов можно найти в googling, он может отметить, что у него есть файл с использованием службы REST в веб-приложении.

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

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

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

Вопрос

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

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

Будет ли это уменьшать сумятицу?

У кого-нибудь есть идея решить эту проблему по-другому?

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

+0

Я не понимаю, почему это проблема безопасности, если клиент утверждает, что имеет определенный файл, но не знает? –

+0

@Christoffer Hammarström: Если я правильно понимаю, хеш-функция позволяет пользователю просить сервер «помещать файл с таким-то-хешем в мою собственную область хранения, как если бы я его загрузил», и сервер будет соответствовать как поскольку этот файл ранее был загружен кем-то другим. Затем злоумышленник может * загрузить * файл, который он просто «загрузил», чтобы получить доступ к его содержимому. – Wyzard

+0

Я использую термин «безопасность» неправильно? Но это проблема, когда кто-то утверждает, что у них есть файл без его владения. Скажем, кто-то опубликовал фотографию в Интернете с хэш-строкой. Позже фото удаляется, но хэш-строка остается в Интернете. Эта фотография также загружается в учетную запись владельца на сервере webapp. Очевидно, что другой пользователь хочет получить эту приватную фотографию, они могут утверждать, что у них есть это, используя хэш-строку. Это означает, что вы владеете хэш-строкой файла, и вы тоже являетесь владельцем файла, который я хочу предотвратить. – gigadot

ответ

2

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

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

+0

Спасибо @Wyzard. Я обожаю оба ваших ответа. +1 оба для них – gigadot

1

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

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

+0

Понял. Это сводится к компромиссу между сохранением пропускной способности и безопасностью. – gigadot

Смежные вопросы