Forum Moderators: phranque

Message Too Old, No Replies

Idea on preventing hotlinking images

Idea on preventing hotlinking images

         

bytb

2:24 am on Oct 21, 2007 (gmt 0)



Hi, I had this idea on preventing hotlinking images. My idea was if you knew who the image was requested from in a way that could not be faked (ie referer) this could be prevented and useragents could be reverse dnsed.

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?

jdMorgan

3:18 am on Oct 21, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I don't see how that solves the problem, because anybody could call the script.

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

bytb

3:50 am on Oct 21, 2007 (gmt 0)



Yes I see your point, but I wanted to get a away from cookies and make a more secure answer but its hard, it would be much easier if apache only allowed some files to be only called by server ip. Perhaps by using an allowed refer to contain a sesssion php cookie this may be the way.

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?

bytb

4:06 am on Oct 21, 2007 (gmt 0)



Another idea is you could mod_rewrite the cgi call for the image, all protection would work as normall and hijackers would never know ip detection was beeing inforced.

bytb

4:22 am on Oct 21, 2007 (gmt 0)



Proposed answer, stick the cgi script behind and a 8 digit folder, mod_rewrite it and then stick a session cookie as an allowed referer along with useragents and server ip.

jdMorgan

2:06 pm on Oct 21, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



You're using some terms here in an incompletely-described way that I think we should highlight.

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

bytb

2:51 pm on Oct 21, 2007 (gmt 0)



Thanks JdMorgan, clearly I need to rethink this, thanks for your help and advice much appreciated :)

Achernar

1:31 pm on Oct 23, 2007 (gmt 0)

10+ Year Member Top Contributors Of The Month



What is your problem with anti-hotlinking settings in apache?

<Directory /home/you_site_full_path/images>
SetEnvIf REFERER "^((wysiwyg://[^:]*)?http://www\.example\.com/.*)?$" link_ok

Order 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]