开发者

How can I prevent Amazon Cloudfront from hotlinking?

开发者 https://www.devze.com 2023-02-25 21:36 出处:网络
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 ele

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.


You can forward the Referer header to your origin

  1. Go to CloudFront settings
  2. Edit Distributions settings for a distribution
  3. Go to the Behaviors tab and edit or create a behavior
  4. Set Forward Headers to Whitelist
  5. Add Referer as a whitelisted header
  6. Save the settings in the bottom right corner

Make sure to handle the Referer header on your origin as well.


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).


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.


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:

How can I prevent Amazon Cloudfront from hotlinking?


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!


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.


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消