3

我正在尝试阻止从特定域对我的 Cloudfront 文件进行热链接。通过结合在线示例和亚马逊自己的策略生成器，我想出了这个：

{
  "Version": "2008-10-17",
  "Id": "http referer policy",
  "Statement": [{
    "Sid": "Block image requests",
    "Action": "s3:GetObject",
    "Effect": "Deny",
    "Resource": "arn:aws:s3:::mybucket/subdir/*",
    "Condition": {
      "StringLike": {
        "aws:Referer": [
          "http://example.com/*"
        ]
      }
    },
    "Principal": {
      "AWS": "*"
    }
  }]
}

我在 的子目录中发送了一个文件的失效请求mybucket，然后几分钟后尝试重新加载仍然发送引用标头的图像（使用 Chrome 的开发工具验证）。使用 Ctrl+F5 进行了硬重新加载，响应标头包含“X-Cache:Miss from cloudfront”，因此它肯定获得了最新版本的图像。

但是图像仍然显示正常并且没有被阻止。策略生成器没有“aws:Referer”键的选项，但它位于此处的 Amazon 文档中。我在这里做错了吗？

4

1 回答 1

1

更新 2

重新审视您的政策 我想知道您最初是如何允许 CloudFront 访问您的对象的？您是否偶然遵循了例如开始将 CloudFront 与 Amazon S3 一起使用中的常见建议，即您必须确保将您的对象权限设置为针对您的 Amazon S3 存储桶中的每个对象将所有内容设置为公开。

在这种情况下，由于同时可用的三种不同的 S3 访问控制机制之间的交互，您可能会偶然发现一个相关的陷阱，这确实会让人感到困惑。这在Using ACLs and Bucket Policies Together中得到了解决：

当您将 ACL 和存储桶策略分配给存储桶时，Amazon S3 在确定账户对 Amazon S3 资源的访问权限时会评估现有的 Amazon S3 ACL 以及存储桶策略。如果帐户有权访问 ACL 或策略指定的资源，则他们能够访问请求的资源。

因此，您需要将 ACL 迁移到存储桶策略（即在通过aws:referer拒绝之前允许 CloudFront 访问），然后删除过于宽泛的 ACL。

祝你好运！

更新 1

好的，现在有了客户端缓存，恐怕这将不是一件容易的事（当您在 AWS 论坛中搜索aws:referer时很明显），因此可能需要进行几次迭代（尤其是考虑到您已经研究过主题自己已经）：

  • 遇到的最常见的问题是AWS 文档中的前导空白错误（这特别烦人，因为一个简单的文档修复会代表用户和 AWS 支持人员弥补大量浪费的时间）
    • 但是，您的策略没有显示此问题，因为您清理了真实域，实际上您可能已经替换了生产代码中的错误？
  • 同样重要的是要意识到HTTP referer标头不一定可用，请参见例如引用者隐藏（因此您的策略无论如何都不会阻止恶意访问，尽管这显然不是问题）
    • 您已经说过，您已经验证它是通过 Chrome 开发人员工具发送的，所以这也不适用（我提到它是为了强调降低的安全级别）。

乍一看，该策略看起来不错——不过，在进一步深入这个方向之前，我建议确保您确实成功绕过了 Chrome 的缓存，众所周知，这比人们习惯使用其他浏览器的方式更不直接；特别是，Ctrl + F5 只是重新加载页面，但不 绕过缓存（至少不可靠）！

正如那里所记录的那样，您可以使用其他组合键之一来重新加载页面并绕过缓存（包括在Ctrl + F5第一次重新加载后令人困惑的第二次），但是，我建议您使用以下两种替代方法之一：

  • Chrome 的开发者工具为没有缓存的浏览提供了专门的支持 - 在工具箱面板的右下角是一个用于设置的 cog 图标，单击它会触发带有选项面板的覆盖，其中您会在部分下找到禁用缓存选项网络。
  • Chrome的隐身模式（_，虽然现在不太明确的选项。Ctrl + Shift + N
于 2012-01-27T01:10:24.197 回答