Browser 基于亚马逊S3浏览器的上传-防止覆盖

我们在我们的网站上使用AmazonS3制作图像，用户通过我们的网站将图像/文件直接上传到S3。在我们的策略文件中，我们确保它以“upload/”开头。任何人都可以看到这些图像的完整URL，因为它们在上传后是公开可读的图像。黑客可以进来并使用javascript中的策略数据和图像的url用他们的数据覆盖这些图像吗？我认为没有办法防止上传一次后的覆盖。我见过的唯一解决方案是将文件复制/重命名到一个不可公开写入的文件夹中，但这需要下载图像，然后再次将其上载到S3（因为Amazon无法真正进行重命名）

如果我理解正确，图像将通过服务器应用程序上载到Amazon S3存储。 因此，AmazonS3的写入权限只有您的应用程序。客户端只能上传图像并抛出你的应用程序（将它们存储在S3上）。黑客只能强制你的应用程序上传同名图片并重写原始图片

当用户上传一个名称已经存在于S3存储中的图像时，您如何处理这种情况？ 考虑以下动作：

第一个用户上传图像some-name.jpg

您的应用程序将该图像存储在S3中的upload-some-name.jpg下

第二个用户上传图像some-name.jpg

您的应用程序会覆盖存储在S3中的原始应用程序吗

---

事实上，S3确实有一个拷贝功能，非常好用

但正如amra所述，通过复制声音将空间翻倍是低效的
mybe最好为对象提供某种唯一的id，如guid，并设置以“x-amz-meta-”开头的其他用户元数据，以获取有关对象的更多信息，如上载对象的用户、显示名称等。

---

另一方面，您可以随时检查密钥是否已经存在，并提示错误我认为这个问题意味着使用服务器提供的策略文件，内容直接从浏览器传输到S3。如果该策略文件设置了过期，例如，在未来的某一天，则该策略在此之后将变为无效。此外，您可以在可写路径上设置起始条件

因此，黑客可以使用您的策略文件恶意覆盖文件的唯一方法是获取一个新的策略文件，然后仅覆盖指定路径中的文件。但到那时，您将有机会拒绝提供策略文件，因为我假设这是在验证用户后发生的事情

因此，简而言之，如果您在分发正确构造的策略文件并在这样做之前对用户进行身份验证，我看不出有什么危险。不需要复制东西