防止 Amazon Cloudfront 盗链

Posted 2023-04-14

【中文标题】防止 Amazon Cloudfront 盗链

【英文标题】：Preventing Amazon Cloudfront hotlinking

【发布时间】：2011-08-04 21:48:34

【问题描述】：

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

最近令我恼火的是，第三方网站在未经授权的情况下链接到我的 Cloudfront 服务器以在他们自己的页面上显示图像。

我已经配置了.htaccess，以防止在我自己的服务器上进行热链接，但在 Cloudfront 上没有找到这样做的方法，它似乎本身不支持该功能。而且，令人讨厌的是，可用于防止盗链的 Amazon 存储桶策略仅对 S3 有效，而对 CloudFront 分配没有影响 [link]。如果您想利用这些策略，您必须直接从 S3 提供您的内容。

搜索我的服务器日志以查找热链接器并手动更改文件名并不是一个现实的选择，尽管我一直在这样做以结束最公然的违法行为。

欢迎提出任何建议。

【参考方案1】：

You can forward the Referer header to your origin

转到 CloudFront 设置 编辑分配的分配设置 转到“行为”选项卡并编辑或创建行为 将转发标头设置为白名单 将Referer添加为列入白名单的标头 保存右下角的设置

确保也处理您的来源上的 Referer 标头。

【讨论】：

我只能将Origin、Access-Control-Request-Headers 和Access-Control-Request-Methods 添加到白名单中...而且链接的文档没有明确说明引用者...

@BernhardVallant 您应该能够看到选项here。如果不是，那可能是因为您使用的价格计划。

@Blaise 你能举一个例子来说明处理源头上的引用标头的最后一部分吗？

不要这样做。如果被请求的图像已经从“合法”用户获取它的缓存中，则盗链客户端将能够很好地请求它（并且您仍在为云端命中付费）。如果热链接客户端确实设法获得缓存未命中并且请求转到您的源并被拒绝，则云端将缓存 403 响应一段时间，导致合法客户端在请求该项目时也获得此响应。很抱歉恢复这个多年前的答案，但它仍然是热门搜索结果。

@Brett 我认为您弄错了，“您可以将 CloudFront 配置为将标头转发到源，这会导致 CloudFront 根据一个或多个请求标头中的值缓存对象的多个版本。 "见docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/…

【参考方案2】：

官方的做法是为您的媒体使用signed urls。对于您要分发的每个媒体片段，您可以生成一个特制的 URL，该 URL 在给定的时间和源 IP 约束下工作。

静态页面的一种方法是为该页面中包含的媒体生成临时 URL，其有效期为页面缓存时间的 2 倍。假设您的页面的缓存时间是 1 天。每隔 2 天，链接就会失效，这要求热链接者更新其 url。这不是万无一失的，因为他们可以构建工具来自动获取新网址，但它应该阻止大多数人。

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

【讨论】：

谢谢 Jonas：不过，这是一个相当复杂的过程？

生成签名网址时如何访问请求者的 ip？

【参考方案3】：

我们遇到了许多盗链问题。最后，我们为许多图像创建了 css sprites。要么在底部/侧面添加空白，要么将图像组合在一起。

我们使用 CSS 在我们的页面上正确显示了它们，但任何热链接都会错误地显示图像，除非它们也复制了 CSS/html。

我们发现他们不打扰（或不知道如何）。

【参考方案4】：

从 2015 年 10 月起，您可以使用 AWS WAF 来限制对 Cloudfront 文件的访问。 Here's an article from AWS 宣布 WAF 并解释你可以用它做什么。 Here's an article 帮助我设置了我的第一个 ACL，以根据引用者限制访问。

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

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

【参考方案5】：

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

首先：很多人在 Cloudfront 支持论坛上提出过这个问题。例如，请参阅 here 和 here。

很明显，AWS 从盗链中受益：点击次数越多，他们向我们收取的费用就越多！我认为我们（Cloudfront 用户）需要启动某种精心策划的活动，以让他们提供推荐人检查作为一项功能。

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

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

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

作为 DNS 更改，这会在他们的流量到达您的服务器附近之前击倒所有当前进行盗链的人：DNS 条目将无法查找。您必须不断更改 cdn CNAME 才能使其生效（比如每月一次？），但它会起作用。

这实际上是一个比看起来更大的问题，因为这意味着人们可以更轻松地抓取您网站页面的整个副本（包括图片） - 因此，您丢失的不仅仅是图片，也不仅仅是您为服务付费那些图像。搜索引擎有时会得出结论，您的页面是副本，而副本是原件……然后您的流量就会爆炸。

我正在考虑放弃 Cloudfront，转而使用具有战略定位的超快速专用服务器（从一个地方向全世界提供所有内容），让我对这些事情有更多的控制权。

无论如何，希望别人有更好的答案！

【讨论】：

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

如果更改 CNAME，则无需更改 URL。您可以使用 301 重定向在一段时间内从旧 CNAME 捕获引荐，然后再更改为新 CNAME（告诉搜索引擎您去了哪里）。如果有人在阅读本文并想知道我所说的 CDN CNAME 是什么意思，Paul Stamatiou 的指南“如何：Amazon Cloudfront 入门”[paulstamatiou.com/…，这是实现 Cloudfront CDN I 的最简单、最清晰的指南，对此进行了很好的解释。找到了。

我喜欢DNS建议，定期淘汰所有热链接:)

【参考方案6】：

这个问题提到了图像和视频文件。 由于某些移动浏览器在请求使用 HTML5 播放的音频或视频文件时不发送referer 标头，因此无法使用Referer 检查来保护多媒体资源免遭盗链。 我确信 iPhone 上的 Safari 和 Chrome 以及 android 上的 Safari。 太糟糕了！谢谢苹果和谷歌。

【参考方案7】：

使用签名 cookie 怎么样？使用自定义策略创建签名 cookie，该策略还支持您要设置的各种限制，也是通配符。