我该如何防止Amazon Cloudfront的图片盗链？

Question

我使用Amazon CloudFront来托管我的网站的所有图片和视频，以便为遍布全球的用户更快地提供服务。我还对托管在CloudFront上的元素应用了非常积极的前向缓存，将Cache-Control设置为public, max-age=7776000。

最近我发现，第三方网站未经授权就链接到我的CloudFront服务器上，在自己的页面上显示图片，这让我很恼火。

我已经配置了.htaccess防止在自己的服务器上进行链接，但是在Cloudfront上没有找到这样的方法，因为它似乎没有本身支持此功能。令人烦恼的是，Amazon的Bucket策略只有在S3上生效，对CloudFront分发无效 [链接]。如果您想利用这些策略，必须直接从S3提供内容。

搜索我的服务器日志以查找链接者并手动更改文件名并不是一个现实的选项，虽然我一直在做这件事来结束最明显的违规行为。

- Donald Jenkins

Answer 1

您可以将 Referer 标头转发到您的源

1. 进入CloudFront设置
2. 编辑分发设置
3. 进入“行为”选项卡并编辑或创建一种行为
4. 将“转发标头”设置为“白名单”
5. 添加Referer作为白名单标头
6. 在右下角保存设置

请确保在您的源上处理Referer标头。

- Blaise

---

我只能将 Origin、Access-Control-Request-Headers 和 Access-Control-Request-Methods 添加到白名单中... 此外，链接的文档并没有明确说明 referer。 - Bernhard Vallant

@BernhardVallant 你应该能够在这里看到选项。如果没有，那可能是因为你所使用的价格计划不支持此功能。 - GFoley83

@user2528676 这取决于您在源上运行的服务器。如果您搜索“防止nginx热链接”或“防止apache热链接”，谷歌会为您提供相关代码示例。 - Blaise

不要这样做。如果请求的图像已经被“合法”用户获取并缓存在缓存中，那么盗链客户端将能够正常请求它（而您仍然需要支付CloudFront的费用）。如果盗链客户端确实发生了缓存未命中，并且请求发送到您的源并被拒绝，那么CloudFront将缓存403响应一段时间，导致合法客户端在请求该项时也会收到此响应。很抱歉重新激活这个多年前的答案，但它仍然是顶级搜索结果。 - Brett

@Brett 我认为你错了，“您可以配置CloudFront将标头转发到源，这会导致CloudFront基于一个或多个请求标头中的值缓存多个对象版本。”请参见https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html。 - Blaise

Answer 2

我们遇到了许多热链接问题。最终，我们为许多图像创建了CSS精灵。可以在底部/侧面添加白色空间或将图像合并在一起。

我们使用CSS在页面上正确显示它们，但如果有任何热链接，除非他们也复制CSS/HTML，否则将错误地显示这些图像。

我们发现他们不会费心（或不知道如何做）。

- Harry

Answer 3

官方方法是使用签名URL来分发您的媒体。对于每个要分发的媒体文件，您可以生成一个特殊制作的URL，该URL在给定的时间和源IP的限制下工作。

对于静态页面的一种方法是为该页面中包含的媒体生成临时URL，这些URL的有效期为页面缓存时间的2倍。假设您的页面缓存时间为1天，则链接将在2天后失效，这迫使热链接者更新其URL。虽然不是绝对可靠的，因为他们可以构建工具自动获取新的URL，但它应该能够阻止大多数人。

如果您的页面是动态的，您不需要担心破坏页面的缓存，因此您可以简单地生成仅适用于请求者IP的URL。

- zimbatm

---

谢谢 Jonas：那是一个相当复杂的过程，不是吗？ - Donald Jenkins

在生成签名 URL 时，我该如何访问请求方的 IP？ - crazyCoder

Answer 4

截至2015年10月，您可以使用AWS WAF限制对Cloudfront文件的访问。这里是来自AWS的一篇文章，它宣布了WAF并解释了您可以使用它做什么。这是一篇文章，帮助我设置了我的第一个ACL以基于引用者限制访问。

基本上，我创建了一个默认操作为DENY的新ACL。我添加了一个规则，检查引用者头字符串的结尾是否为我的域名（小写）。如果它通过了该规则，则允许访问。

在将我的ACL分配给我的Cloudfront分发后，我尝试在Chrome中直接加载我的其中一个数据文件，但我收到了以下错误：

- Redtopia

Answer 5

据我所知，目前还没有解决方案，但我有一些可能相关、可能无关的建议...

首先：许多人在Cloudfront支持论坛上提出了这个问题。例如，可以看看这里和这里。

显然，AWS受益于热链接：点击量越多，他们就会向我们收取更多费用！我认为我们（Cloudfront用户）需要开始一种高度协调的运动，要求他们将referer检查作为一项功能提供。

我想到的另一个临时解决办法是更改我用于将流量发送到cloudfront/s3的CNAME。因此，假设您目前将所有图像发送到：

cdn.blahblahblah.com（重定向到某个cloudfront/s3存储桶）

您可以将其更改为cdn2.blahblahblah.com，并删除cdn.blahblahblah.com的DNS条目。

作为DNS更改，这将使所有当前热链接的人在其流量到达您的服务器之前就被拦截：DNS条目将无法查找。您必须不断更改cdn CNAME才能使其生效（比如每个月更改一次？），但它会起作用。

实际上，这是一个比看起来更严重的问题，因为它意味着人们可以更轻松地爬取您网站页面的整个副本（包括图像）--所以您失去的不仅仅是图像，并且您要付费来提供这些图像。搜索引擎有时会得出您的页面是副本而副本是原件的结论...然后您的流量就消失了。

我正在考虑放弃Cloudfront，转而使用布局合理、超级快速的专用服务器（从一个位置向全世界提供所有内容），从而让我对这些事情有更多的控制。

总之，希望其他人有更好的答案！

- Chris W

---

非常感谢这些评论。听起来现在没有适当的解决方案。手动更改URL是可行的，但相当费力！我希望亚马逊能想出更好的方法。 - Donald Jenkins

如果您更改CNAME，则无需更改URL。在更改为新的CNAME之前，您可以使用301重定向来捕获旧CNAME的引荐（以告诉搜索引擎您去了哪里）。如果有人正在阅读此内容并想知道我所说的CDN CNAME是什么意思，那么在Paul Stamatiou的指南“How to: Getting Started with Amazon Cloudfront”[http://paulstamatiou.com/how-to-getting-started-with-amazon-cloudfront]中对此进行了很好的解释，这是我发现的实施Cloudfront CDN的最简单、最清晰的指南。 - Chris W

我喜欢DNS建议，定期清除所有热链接 :) - William Denniss

Answer 6

这个问题涉及到图像和视频文件。
引用检查无法用于保护多媒体资源免受热链接，因为一些移动浏览器在请求使用HTML5播放的音频或视频文件时不发送引用头。
我确定iPhone上的Safari和Chrome以及Android上的Safari都是如此。
太糟糕了！谢谢你，苹果和谷歌。

- figolu

Answer 7

使用签名Cookie如何？使用自定义策略创建签名Cookie，该策略还支持您想要设置的各种限制，并且它是通配符。

- Sandip Jangra