如何防止 Amazon Cloudfront 盗链？
我使用 Amazon Cloudfront 托管我网站的所有图像和视频，以便更快地为分散在全球各地的用户提供服务。我还对 Cloudfront 上托管的元素应用了相当积极的前向缓存，将 Cache-Control 设置为 public, max-age=7776000。
最近，我很恼火地发现，第三方网站正在盗链到我的 Cloudfront 服务器，以便在未经授权的情况下在自己的页面上显示图像。
我已配置 .htaccess 以防止在我自己的服务器上进行热链接，但尚未找到在 Cloudfront 上执行此操作的方法，Cloudfront 似乎本身不支持该功能。而且，令人烦恼的是，亚马逊的存储桶策略可用于防止热链接，但仅对 S3 有效，对 CloudFront 发行版没有影响 [链接]。如果您想利用这些策略，您必须直接从 S3 提供内容。
在我的服务器日志中搜索热链接并手动更改文件名并不是一个现实的选择，尽管我一直这样做是为了结束最明目张胆的犯罪行为。
I use Amazon Cloudfront to host all my site's images and videos, to serve them faster to my users which are pretty scattered across the globe. I also apply pretty aggressive forward caching to the elements hosted on Cloudfront, setting Cache-Controlto public, max-age=7776000.
I've recently discovered to my annoyance that third party sites are hotlinking to my Cloudfront server to display images on their own pages, without authorization.
I've configured .htaccessto prevent hotlinking on my own server, but haven't found a way of doing this on Cloudfront, which doesn't seem to support the feature natively. And, annoyingly, Amazon's Bucket Policies, which could be used to prevent hotlinking, have effect only on S3, they have no effect on CloudFront distributions [link]. If you want to take advantage of the policies you have to serve your content from S3 directly.
Scouring my server logs for hotlinkers and manually changing the file names isn't really a realistic option, although I've been doing this to end the most blatant offenses.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
您可以将
Referer标头转发到您的源确保也处理源上的引用标头。
You can forward the
Refererheader to your originMake sure to handle the Referer header on your origin as well.
我们遇到了许多盗链问题。最后，我们为许多图像创建了 CSS 精灵。在底部/侧面添加空白或将图像组合在一起。
我们使用 CSS 在页面上正确显示它们，但任何热链接都会错误地显示图像，除非它们也复制了 CSS/HTML。
我们发现他们不打扰（或不知道如何打扰）。
We had numerous hotlinking issues. In the end we created css sprites for many of our images. Either adding white space to the bottom/sides or combining images together.
We displayed them correctly on our pages using CSS, but any hotlinks would show the images incorrectly unless they copied the CSS/HTML as well.
We've found that they don't bother (or don't know how).
官方方法是为您的媒体使用签名网址 。对于您想要分发的每个媒体片段，您可以生成一个特制的 URL，该 URL 在给定的时间和源 IP 限制下工作。
静态页面的一种方法是为该页面中包含的媒体生成临时 URL，其有效期是页面缓存时间的 2 倍。假设您的页面的缓存时间是 1 天。每 2 天，链接就会失效，这迫使热链接者更新其 URL。这并不是万无一失的，因为他们可以构建工具来自动获取新的网址，但这应该会阻止大多数人。
如果您的页面是动态的，则无需担心会破坏页面的缓存，因此您可以简单地生成仅适用于请求者 IP 的 URL。
The official approach is to use signed urls for your media. For each media piece that you want to distribute, you can generate a specially crafted url that works in a given constraint of time and source IPs.
One approach for static pages, is to generate temporary urls for the medias included in that page, that are valid for 2x the duration as the page's caching time. Let's say your page's caching time is 1 day. Every 2 days, the links would be invalidated, which obligates the hotlinkers to update their urls. It's not foolproof, as they can build tools to get the new urls automatically but it should prevent most people.
If your page is dynamic, you don't need to worry to trash your page's cache so you can simply generate urls that are only working for the requester's IP.
自 2015 年 10 月起，您可以使用 AWS WAF 限制对 Cloudfront 文件的访问。 这是一篇来自 AWS 的文章，其中介绍了 WAF 并解释了您可以执行的操作与它。 这里有一篇文章帮助我设置了我的第一个 ACL 根据引用者限制访问。
基本上，我创建了一个默认操作为 DENY 的新 ACL。我添加了一条规则来检查我的域名（小写）的引用标头字符串的末尾。如果它通过了该规则，则允许访问。
将我的 ACL 分配给我的 Cloudfront 发行版后，我尝试直接在 Chrome 中加载我的数据文件之一，但收到此错误：
As of Oct. 2015, you can use AWS WAF to restrict access to Cloudfront files. Here's an article from AWS that announces WAF and explains what you can do with it. Here's an article that helped me setup my first ACL to restrict access based on the referrer.
Basically, I created a new ACL with a default action of DENY. I added a rule that checks the end of the referer header string for my domain name (lowercase). If it passes that rule, it ALLOWS access.
After assigning my ACL to my Cloudfront distribution, I tried to load one of my data files directly in Chrome and I got this error:
据我所知，目前还没有解决方案，但我有一些可能相关、可能不相关的建议...
第一：很多人在 Cloudfront 支持论坛上问过这个问题。请参阅此处和此处。
显然，AWS 从热链接中受益：点击次数越多，他们向我们收取的费用就越高！我认为我们（Cloudfront 用户）需要启动某种精心策划的活动，让他们提供引用检查作为一项功能。
我想到的另一个临时解决方案是更改用于将流量发送到 cloudfront/s3 的 CNAME。假设您当前将所有图像发送到：
cdn.blahblahblah.com （重定向到某个 cloudfront/s3 存储桶）
的 DNS 条目
您可以将其更改为 cdn2.blahblahblah.com 并删除 cdn.blahblahblah.com作为 DNS 更改，这会在流量到达您的服务器之前淘汰当前正在热链接的所有人员：DNS 条目将根本无法查找。您必须不断更改 cdn CNAME 才能使其生效（例如每月一次？），但它会起作用。
这实际上是一个比看起来更大的问题，因为这意味着人们可以更轻松地抓取您网站页面的整个副本（包括图像） - 因此，您丢失的不仅仅是图像，也不仅仅是您为提供这些图像而付费。搜索引擎有时会得出结论，您的页面是副本，副本是原件......然后您的流量就会爆炸。
我正在考虑放弃 Cloudfront，转而采用战略定位的超快专用服务器（从一个地方向全世界提供所有内容），以便让我对这些事情有更多的控制权。
无论如何，我希望其他人有更好的答案！
As far as I know, there is currently no solution, but I have a few possibly relevant, possibly irrelevant suggestions...
First: Numerous people have asked this on the Cloudfront support forums. See here and here, for example.
Clearly AWS benefits from hotlinking: the more hits, the more they charge us for! I think we (Cloudfront users) need to start some sort of heavily orchestrated campaign to get them to offer referer checking as a feature.
Another temporary solution I've thought of is changing the CNAME I use to send traffic to cloudfront/s3. So let's say you currently send all your images to:
cdn.blahblahblah.com (which redirects to some cloudfront/s3 bucket)
You could change it to cdn2.blahblahblah.com and delete the DNS entry for cdn.blahblahblah.com
As a DNS change, that would knock out all the people currently hotlinking before their traffic got anywhere near your server: the DNS entry would simply fail to look up. You'd have to keep changing the cdn CNAME to make this effective (say once a month?), but it would work.
It's actually a bigger problem than it seems because it means people can scrape entire copies of your website's pages (including the images) much more easily - so it's not just the images you lose and not just that you're paying to serve those images. Search engines sometimes conclude your pages are the copies and the copies are the originals... and bang goes your traffic.
I am thinking of abandoning Cloudfront in favor of a strategically positioned, super-fast dedicated server (serving all content to the entire world from one place) to give me much more control over such things.
Anyway, I hope someone else has a better answer!
这个问题提到了图像和视频文件。
Referer 检查不能用于保护多媒体资源免遭盗链，因为某些移动浏览器在请求使用 HTML5 播放的音频或视频文件时不会发送 Referer 标头。
我对 iPhone 上的 Safari 和 Chrome 以及 Android 上的 Safari 确信这一点。
太糟糕了！谢谢苹果和谷歌。
This question mentioned image and video files.
Referer checking cannot be used to protect multimedia resources from hotlinking because some mobile browsers do not send referer header when requesting for an audio or video file played using HTML5.
I am sure of that about Safari and Chrome on iPhone and Safari on Android.
Too bad! Thank you, Apple and Google.
使用签名cookie怎么样？使用自定义策略创建签名 cookie，该策略还支持您想要设置的各种限制，并且它是通配符。
How about using Signed cookies ? Create signed cookie using custom policy which also supports various kind of restrictions you want to set and also it is wildcard.