Предотвращение горячей ссылки на Amazon Cloudfront - PullRequest
20 голосов
/ 13 апреля 2011

Я использую Amazon Cloudfront для размещения всех изображений и видео на моем сайте, чтобы быстрее обслуживать их для своих пользователей, которые довольно разбросаны по всему миру. Я также применяю довольно агрессивное прямое кэширование к элементам, размещенным в Cloudfront, устанавливая Cache-Control в public, max-age=7776000.

Недавно я с досадой обнаружил, что сторонние сайты ссылаются на мой сервер Cloudfront для отображения изображений на своих страницах без авторизации.

Я настроил .htaccess для предотвращения хотлинкинга на моем собственном сервере, но не нашел способа сделать это в Cloudfront, который, похоже, не поддерживает эту функцию изначально. И, к сожалению, политики Amazon Bucket, которые можно использовать для предотвращения хотлинкинга, влияют только на S3, они не влияют на дистрибутивы CloudFront [ link ]. Если вы хотите воспользоваться преимуществами политик, вы должны обслуживать контент непосредственно с S3.

Очистка журналов моего сервера для горячих линкеров и ручное изменение имен файлов на самом деле нереальный вариант, хотя я делал это, чтобы положить конец самым вопиющим преступлениям.

Любые предложения приветствуются.

Ответы [ 7 ]

10 голосов
/ 05 июля 2014

Вы можете переслать заголовок Referer к вашему источнику

  1. Перейти к настройкам CloudFront
  2. Изменить настройки распределений дляраспределение
  3. Перейдите на вкладку «Поведение» и отредактируйте или создайте поведение
  4. Установите для заголовков пересылки белый список
  5. Добавьте Referer в качестве заголовка белого списка
  6. Сохраните настройкив правом нижнем углу

Не забудьте также обработать заголовок Referer на своем источнике.

10 голосов
/ 16 августа 2011

Официальный подход заключается в использовании подписанных URL-адресов для ваших носителей.Для каждого фрагмента мультимедиа, который вы хотите распространить, вы можете сгенерировать специально созданный URL-адрес, который работает с заданным ограничением времени и IP-адресов источника.

Один из подходов для статических страниц - создание временных URL-адресов для включенных носителейна этой странице, которые действительны в 2 раза дольше, чем время кэширования страницы.Допустим, время кэширования вашей страницы составляет 1 день.Каждые 2 дня ссылки становятся недействительными, что обязывает хотлинкеры обновлять свои URL-адреса.Это не просто, поскольку они могут создавать инструменты для автоматического получения новых URL-адресов, но это должно предотвратить большинство людей.

Если ваша страница динамическая, вам не нужно беспокоиться о том, чтобы очистить кэш вашей страницы, чтобы вы могли простогенерировать URL, которые работают только для IP-адреса запрашивающей стороны.

8 голосов
/ 12 мая 2011

У нас было множество проблем с горячими ссылками. В конце мы создали CSS спрайты для многих наших изображений. Либо добавляя пробел внизу / сторонам, либо комбинируя изображения вместе.

Мы правильно отображали их на наших страницах с использованием CSS, но любые горячие ссылки отображали изображения неправильно, если они также не копировали CSS / HTML.

Мы обнаружили, что они не беспокоятся (или не знают как).

5 голосов
/ 10 февраля 2016

По состоянию на октябрь 2015 г. вы можете использовать AWS WAF для ограничения доступа к файлам Cloudfront. Вот статья из AWS , которая объявляет WAF и объясняет, что вы можете с ней сделать. Вот статья , которая помогла мне настроить мой первый ACL для ограничения доступа на основе реферера.

По сути, я создал новый ACL с действием по умолчанию DENY. Я добавил правило, которое проверяет конец строки заголовка реферера для моего доменного имени (в нижнем регистре). Если он проходит это правило, он разрешает доступ.

После назначения моего ACL для моего дистрибутива Cloudfront я попытался загрузить один из моих файлов данных непосредственно в Chrome, и у меня появилась эта ошибка:

Chrome error message when trying to access a Cloudfront file directly after applying a WAF ACL

2 голосов
/ 20 апреля 2011

Насколько я знаю, в настоящее время нет решения, но у меня есть несколько, возможно, актуальных, возможно, не относящихся к делу предложений ...

Во-первых: множество людей спрашивали об этом на форумах поддержки Cloudfront.См., Например, здесь и здесь .

Очевидно, что AWS извлекает выгоду из хотлинкинга: чем больше просмотров, тем больше они взимают за нас!Я думаю, что мы (пользователи Cloudfront) должны начать какую-то сильно организованную кампанию, чтобы заставить их предлагать проверку реферера в качестве функции.

Другое временное решение, о котором я подумал, - это изменение CNAME, которое я использую для отправки трафика в cloudfront / s3.Допустим, вы в настоящее время отправляете все свои изображения на:

cdn.blahblahblah.com (который перенаправляет на некоторое хранилище cloudfront / s3)

Вы можете изменить его на cdn2.blahblahblah.com и удалитьзапись DNS для cdn.blahblahblah.com

В качестве изменения DNS это приведет к выбиванию всех пользователей, которые в настоящее время осуществляют хотлинкинг до того, как их трафик попадет где-то рядом с вашим сервером: запись DNS просто не сможет найти.Вам нужно было бы постоянно менять cdn CNAME, чтобы сделать это эффективным (скажем, раз в месяц?), Но это сработало бы.

На самом деле это большая проблема, чем кажется, потому что это означает, что люди могут очищать целые копиистраницы вашего веб-сайта (включая изображения) гораздо проще - так что вы не только теряете изображения, но и платите за их обслуживание.Поисковые системы иногда приходят к выводу, что ваши страницы - это копии, а копии - оригиналы ... и трафик уходит.

Я думаю отказаться от Cloudfront в пользу стратегически расположенного, сверхбыстрого выделенного сервера (обслуживающего весь контент для всего мира из одного места), чтобы дать мне гораздо больший контроль над такими вещами.

В любом случае, я надеюсь, что у кого-то есть лучший ответ!

0 голосов
/ 09 сентября 2017

Как насчет использования подписанных файлов cookie?Создайте подписанный файл cookie, используя настраиваемую политику, которая также поддерживает различные виды ограничений, которые вы хотите установить, а также подстановочный знак.

0 голосов
/ 18 сентября 2016

В этом вопросе упоминаются графические и видеофайлы.
Проверка реферрера не может использоваться для защиты мультимедийных ресурсов от хотлинкинга, поскольку некоторые мобильные браузеры не отправляют заголовок реферера при запросе аудио или видео файла, воспроизводимого с использованием HTML5.
IЯ уверен в этом насчет Safari и Chrome на iPhone и Safari на Android.
Очень плохо!Спасибо, Apple и Google.

...