Forum Moderators: phranque
My idea was to link to the image via "src=/cgi-bin/image.cgi?requested.jpg".
The image.cgi script could then take the variable and request the image using "LWP::UserAgent;" this would generate a request to the server using the ip address of the server.
Then in .htaccess you could allow your ip only to get image and allowed usergaents (reverse dnsed) and this could potentially prevent all hotlinking. What do you think?
If you need hotlinking protection that is better than the (unreliable but simple) HTTP-Referrer-based method, the usual answer is to use a script to serve your images (by directly reading them from a non-HTTP-accessible space in the server filesystem) only if a "image access allowed" cookie has been set as the result of the user-agent having visited a page on your site which sets that cookie. The cookie can be given a very limited lifetime to prevent abusers from capturing a valid cookie and then re-using it again and again.
Jim
I have a good answer via curl that can take a something and rewrite without any tell signs to hijackers. Including Live Headers.
I appreciate your comments and the highlght of weakness.Perhaps allowed referer with a session cookie and curl the whole thing removing all cookie and referers may present a secure answer?
First "referrer" -- Be aware that the HTTP Referer header is unreliable. It can easily be spoofed, and in many situations it may be suppressed, either directly or indirectly. For example, a URL that's typed-in to the browser address bar has no referrer; By definition, there is no referring 'page'. Certain well-known "internet security" software packages block the referrer sent by the browser. Some browsers can be easily configured to not send a referrer. Corporate and ISP caching proxies will fetch resources from your site on behalf of their (multiple) users and won't send a referrer while doing so because their single resource fetch is intended to 'feed' multiple users, so the referrer would be inaccurate for all but the first user-invoked fetch. In these cases, you will have problems if you require a non-blank referrer.
Client IP addresses are not necessarily fixed. For example, you will see AOL users fetching resources from your site using multiple IP addresses -- a different IP address for each fetch. And as mentioned above, these fetches are actually coming through AOL's caching proxy servers.
Using CURL, LWP, etc.: One thing you want to avoid is using HTTP requests for 'internal' server operation. There is no reason to have the server request stuff from itself using HTTP -- This adds a horrible overhead to fetches. Instead, use internal filesystem reads, as in PHP or SSI "includes."
I did not specifically discuss/mention "session" cookies, instead keeping the discussion generic. You can define, set, and check your own cookie and call it whatever you like using Apache mod_headers and mod_rewrite. Or you can use PHP's session cookies -- It doesn't really matter to this discussion, only to the implementation.
Because any referrer can easily be spoofed and because it would be very inefficient for the server to use HTTP when 'fetching from itself,' I cannot recommend the method you're proposing -- assuming that I understood it correctly.
Jim
<Directory /home/you_site_full_path/images>
SetEnvIf REFERER "^((wysiwyg://[^:]*)?http://www\.example\.com/.*)?$" link_okOrder Deny,Allow
Allow from env=link_ok
Deny from all
</Directory>
or in .htaccess without the <Directory ...>
(wysiwyg://[^:]*)? is used when the content of a popup has been generated from the opener webpage.
The outer ^(...)?$ ensures that an empty referrer is accepted.
[edited by: Achernar at 1:31 pm (utc) on Oct. 23, 2007]