安全文件服务器

Question

简介

我想创建一个用于存储和备份用户文件的Java Web应用程序，类似于Dropbox。其中一个有趣的Dropbox功能是它可以检测服务器上是否已存在某个文件。例如，如果一个用户将文件上载到服务器上，则尝试上载同一文件的另一个用户将不需要上载相同的文件内容。服务器只需要标记他有相同的文件。这有助于节省带宽/空间并以多种方式提高速度。

此问题的最基本解决方案是使用文件哈希字符串，例如sha1，md5等，用于标识文件。客户端软件检查服务器上是否存在某个哈希值。如果它存在，则它可以跳过上载过程并标记该用户具有相同的文件。

问题

Web应用程序基于REST架构实现，因此用户可以轻松编写自己的客户端软件来上传文件。出于安全原因，为所有事务启用了SSL。但我最担心的是关于用户伪造他们有一个文件而没有实际拥有它，如果我使用sha1或任何其他标准哈希算法。 SSL或加密无法阻止这种情况。如果用户设法获得散列字符串，例如通过谷歌搜索可以找到许多文件的md5和sha1，他可以在Web应用程序上使用REST服务标记他有文件。

因此，可能的解决方案之一是服务器从文件中请求一组特定的随机字节以及整个文件的散列。以下是示例步骤：

1. 客户端检查服务器上是否存在某个哈希值。然后，如果文件已经存在，服务器将返回所需的随机字节位置。
2. 如果服务器有文件，客户端会根据请求发送随机字节。如果没有实际文件，客户端软件将无法对其做出响应。

通过这种方式，它可以节省带宽并确保用户拥有他们想要上传的文件。

问题

我不是网络安全方面的专家，所以我不知道这是不是一个好主意。我读过一些关于实现自己的花哨过程的文章可能会导致安全性降低，因为安全性无法测试，额外的信息可能会提供破解方法。

有人对此过程有任何评论吗？

它会降低安全感吗？

有没有人有想法以不同的方式解决这个问题？

我知道这个问题可能没有确切的答案，但我想知道是否有人遇到过同样的问题并且有任何好的解决方案。

Answer 1

不要让客户端上传文件内容的一些随机字节，而是要求客户端上传文件随机区域的哈希。这样，您可以使用更广泛的尺寸，并要求客户验证。

但更好的是，可能会向客户端发送一个随机数，并要求客户端使用该数字作为密钥计算整个文件内容的HMAC。这在计算上更加昂贵，因为服务器也必须计算HMAC，但它验证客户端是否拥有整个文件，而不仅仅是其中的一小部分。

Answer 2

即使使用验证方案，此哈希特征的一个不可避免的副作用是，它显示该文件的副本已存在于服务器上的某处。这本身可能是敏感信息。

对于最严格的隐私保护，您应该放弃此功能，并让每个用户上传自己的文件副本。您可以在服务器上使用哈希比较，以避免存储文件的多个副本，对客户端透明。