Безопасный файловый сервер

Question

Введение

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

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

Задача

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

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

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

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

Вопрос

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

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

Это уменьшит успех?

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

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

Answer 1

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

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

Answer 2

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

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