Защита изображений от hotlinking

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

В связи с этим потерроризировал гугль и нашел статейку http://www[dot]alistapart[dot]com/articles/hotlinking/
Имеет ли смысл отслеживать рефереры, если их можно банально подделать?

В проекте картинки выводятся таким образом
<a href="http://site/images/12345[dot]jpg"><img src="http://site/images/thumb_12345.jpg" /></a>. Т.е. как в обычной галерее. Пропускать каждую картинку через некий скрипт проверки имеет ли смысл? Или забить на это и разрешить hotlinking и бешенный трафик на хост?!

-----
Список фильмов с описанием, блекджеком и... для Joomla? -> https://киноархив[dot]com
Демо нового движка для сайта php.su -> php[dot]su, проект на гитхабе

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

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

А если ставить на картинки водяные знаки с адресом вашего сайта? Пускай либо фотошопят картинки либо рекламируют ваш сайт.

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

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

Я ведь правильно понял, что проблема не в том, что тырят картинки, а в том, что у вас паразитный трафик?

(Отредактировано автором: 15 Декабря, 2010 - 09:58:32)

-----
PostgreSQL DBA

Мне кажется, проблема высосана из пальца. Какой смысл хотлинка? Экономия трафика! Чтобы подделать реферера, что нужно? Отправить правильный заголовок. Заголовок отправляет либо браузер пользователя, либо скрипт. В браузер пользователя мы вмешаться не сможем, поэтому заголовки придется отправлять скриптом на стороне сервера. Получается, что трафик один хрен пойдет через наш сервер и url изображения должен указывать на наш скрипт, а не на сторонний сайт. А это уже не фига не хотлинк.

Поправьте меня, если я что-то не так понимаю.

кстате а вот это вариант! Можно зделать так как отдаются файлы на депозит. Сылка всегда динамическая. Тоестьсам скачал дал другу а сылка уже не работает.

-----
Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.

Viper В качестве варината решения осуществляющего защиты от возможности запроса пользователем изображений из каталогов распооложения некоторого web-сайта при включении компонента его запроса к другом ресурсе возможно использования следующих вариатнов - в качестве возможного простого решения допустимо включение системы авторизации на оригинальном web-сайта и обеспечению передачи запрошенных объектов изображений посредством неявного вызываемого PHP-скрипта при соответствующей конфигурации alias-инга и действенного перенаправления обслуживающего его web-сервера - в качестве более качественного варианта защиты допустимо применение такого управляющего генерацией пользовательских документов HTTP-ответа PHP-скрипта включающего синхронизацию по уникальному ключу с элементам HTML-страницы осуществляющими запрос соответствущего изображения на ресурсе

-----
Сделать можно все что угодно - нужно только старание, терпение и хороший поисковик
Безлимитный web-хостинг от 15 рублей за 40 МБ дискового пространства - http://ihost[dot]oks71[dot]ru/

Именно что траффик. На саму то картинку ватермарк вешается.

Uchkuma т.е. с вашей точки зрения все это: "С базуки по мухе"?

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

-----
Список фильмов с описанием, блекджеком и... для Joomla? -> https://киноархив[dot]com
Демо нового движка для сайта php.su -> php[dot]su, проект на гитхабе

Сделайте обычную защиту от хотлинка. С помощью htaccess или еще как. Если "левый" трафик был, то он сразу "отвалится". Если конечно левый трафик не связан с грабингом вашего сайта.

Предполагаемые в преыдущем сообщении вариант осуществления защиты от возможности прямого доступа к элементам изображений на вашем web-узле при включении их с состав сторонних HTML-страниц - включает проведения реального HTTP-запроса на целевой сервер при проведнии обработки компонента включения изображения браузером - однако обеспечивает предотвращения передачи содержимого собственного файловго объекта изображения

-----
Сделать можно все что угодно - нужно только старание, терпение и хороший поисковик
Безлимитный web-хостинг от 15 рублей за 40 МБ дискового пространства - http://ihost[dot]oks71[dot]ru/

Использовал 2 способа, могу немного объяснить.

1: Через .htaaccess - просто и сердито. Если чужой реферер - отдаем другое изображение, на котором написано: "Все изображения находятся на сайте www.bla-bla.ru". Не забудьте указать, что при пустом реферере нельзя блокировать изображение, некоторые пользователи открывают изображения отдельно. (Если на серваке установлен Nginx: прописывать нужно в его конфиге, возможностей там поболее.)

2: Через особый PHP скрипт. Тут немного сложнее, т.к. придется создать целый модуль, который будет проверять реферер.

Этот вариант имеет недостатки:
- время на разработку и отладку.
- нагрузка на хостинг\сервер, создаваемая скриптом (а также висящие процессы от пользователей с медленным соединением).
- еще касательно Nginx'а, но это не столь важно.

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


Такую ссылку не вставишь в тело страницы, и как правило у них "срок жизни".

Ну, это с какой стороны посмотреть. Если у вас хостинг за 2 у.е. в месяц и 15 хостов в сутки, то да, беспокоится не о чем. А если 10 тысяч и паразиты создают доп. нагрузку на сервер, то просто необходимо от них избавиться.
(Добавление)

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

http://site[dot]ru/catalog/directory/imagename[dot]jpg - Прямая ссылка? Нет, скрипт получает через URL три GET параметра: название каталога изображений, папка изображений и имя изображения. И возвращает даже не файл с .jpg расширением, а заранее созданный оптимизированный файл imagename.cache, с ватермаркой и требуемого размера.

(Отредактировано автором: 16 Декабря, 2010 - 05:45:21)

Вы невнимательно прочитали мой пост.
И пост Мелкого тоже. Там шла речь о добавлении к имени файла ключика.
По большому счету браузеру вообще все равно, скриптом файл отдается или напрямую из файловой системы. На кеширование это никак не влияет. А если не отдать правильные заголовки, изображение попросту браузером не будет отображено. Аналогично и для хотлинка не важно, какая будет ссылка на картинку, imagename.jpg или imagename.php.

Ну да, я разве что-то другое сказал? Все дело в заголовках.
Что нам мешает ложить ключик в сессию или в куки? Правильно, ничего.
А если добавить ключ к УРЛ и ссылка на изображение будет постоянно находится на странице контента, то сами подумайте, что получится. Нелепо в этом случае говорить о защите изображения. Этот способ можно использовать только тогда, когда все остальные недоступны.

Описанные в предыдущих комментариях потока дискуссии варанты решения защиты изображений от прямого доступа обеспечивают обязательное включение пользователем целевого HTTP-запроса на web-ресурс с последующим осуществлением анализа информационных полей окружащей среды и расчета параметров доступа - в таком случае возможно конфигурирование объекта данных выходного HTTP-документа конролируемой генерации однако достаточно большое число целевых запросов обеспеичвают значительное количество сетевого траффикам - единственным варинтом обеспечивающим гарантированную защиту целевого содержимого является использование актвных пользовательских компонентов авторизации - которым в частности может выступать специализированных ActiveX-компонент в браузере Internet explorer с помощью которого возможно организовать защиту уровня клиентского компилируемого приложения

-----
Сделать можно все что угодно - нужно только старание, терпение и хороший поисковик
Безлимитный web-хостинг от 15 рублей за 40 МБ дискового пространства - http://ihost[dot]oks71[dot]ru/