Эффективный метод предотвращения хотлинкинга через .htaccess

Question

Мне нужно кое-что подтвердить, прежде чем я пойду обвинять кого-то в ... ну, я бы лучше не сказал.

Проблема:

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

Текущее «решение»:

Метод, который программист использовал для решения нашей проблемы «слишком много соединений», состоял в том, чтобы переименовать файл, который получает и обрабатывает запросы изображений (image_request.php), в image_request2.php, и заменить содержимое оригинала на

<?php
header("HTTP/1.1 500 Internal Server Error") ;
?>

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

Предлагаемое решение:

Мне кажется, более элегантным решением было бы:

In .htaccess

1. Если запрос для image_request.php
2. Проверить реферер
3. Если реферер не наш сайт, отправьте соответствующий заголовок
4. Если реферер является нашим сайтом, перейдите к image_request.php и обработайте запрос изображения

Я хотел бы знать:

По сравнению с простым возвратом 500 для каждого запроса к image_request.php:

Сколько больше нагрузки будет понесено, если мы будем использовать предложенное мной альтернативное решение, описанное выше?

Есть ли лучший способ сделать это?

Нашей главной заботой является то, что сайт работает. Я не согласен с тем, что разорвать все внутренне связанные изображения - это лучший / единственный способ решить эту проблему. Я отказываюсь сообщать нашим пользователям, что из-за того, что МЫ изменили, они теперь должны вручную изменить код встраивания во все ранее загруженное содержимое.

Answer 1

Хорошо, тогда вы можете использовать mod_rewrite в Apache для предотвращения хот-линков:

Answer 2

Я предполагаю, что вы храните пути к изображениям в базе данных с идентификаторами изображений, верно?И затем вы запрашиваете базу данных для пути к изображению, давая ему идентификатор изображения.

Я предлагаю вам установить MemCached на сервер и выполнить кэширование пользовательских запросов.Это легко сделать в PHP.После этого вы увидите загрузку сервера и решите, стоит ли вообще останавливать эту горячую ссылку.

Answer 3

Ваша увеличенная нагрузка равна загрузке строк в PHP (zilch).

Решение для запутывания даже не решает проблему с самого начала, так как оно не останавливает будущие горячие ссылки. Если вы проверяете заголовок реферера, убедитесь, что все основные браузеры установят заголовок так, как вы ожидаете. Это необязательный заголовок, и поведение может различаться в зависимости от браузера для изображений, встроенных в документ HTML.

Скорее всего, у вас включены сеансы для всех запросов (независимо от того, аутентифицированы они или нет) - в качестве плана резервного копирования вы также можете переименовать имя файла cookie вашего сеанса во что-то непонятное (edit: затемнение здесь на самом деле не имеет значения, если поскольку cookie-файл установлен только для вашего хоста (и он есть)), проверьте, что cookie-файл с таким именем установлен в image_request.php (ни один cookie-файл не будет указывать, что это первый запрос к вашему сайту). Используйте это только как запасной вариант или проверку избыточности. Это хуже, чем проверка реферера.

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

Также нет «подходящего заголовка» для лжи клиенту о доступности ресурса;) Просто отправьте 404.

Answer 4

Использование ModRwrite, вероятно, даст вам меньшую нагрузку, чем запуск сценария PHP. Я думаю, что ваше решение будет легче.

Убедитесь, что вы блокируете доступ только на шаге 3, если заголовок реферера не пуст. Некоторые браузеры и брандмауэры полностью блокируют заголовок реферера, и вы не захотите их блокировать.