Combining the use of rewrite and redirect

[gcn]

Hi,

Recently I've had some "warez" sites hotlink to a download product on my site which has forced me to update my .htaccess file to block exe files from being hotlinked.

My .htaccess file looks like this:

RewriteEngine on
RewriteCond %{HTTP_REFERER}!^$
RewriteCond %{HTTP_REFERER}!^http://(www\.)?domainname.com(/)?.*$ [NC]
.
.
.

RewriteRule .*\.(gif¦jpg¦jpeg¦bmp¦exe)$ - [F,NC]

Now, in addition to dropping this .htaccess file in my root directory, I am also using an .htaccess file in my downloads directory to redirect the download to a different server due to bandwidth limitations. I'm also using this approach because a couple of sites I do not manage are also linking to my download (with my permission) and they aren't always quick to change the link to the new one.

Everything works well, the allowed domains can download the file and all others are banned. As you can see above, I'm forcing a "You are not authorized to view this page message".

However, if you are smart enough to refresh the page after getting the view not authorized page, the download is available for download. I'm a little baffled why that would be occuring? And this totally defeats the purpose of blocking these leeches.

Anyone else experience this and is there a better way of using rewrite/redirect to make this bulletproof?

Thanks.

[jdMorgan]

> make this bulletproof?

There's no way to make referrer-based access control reliable, because referrers are often not sent by browsers and by 'media players', and those that are sent are often blocked by firewalls and caching proxies between the client and the server.

I'll venture a guess at why this is happening: Note that the URL in the address bar while viewing the 403 page remains that of the originally-requested resource. When you do a refresh, that URL is re-fetched, but with a blank referrer (just like a type-in URL would be). Therefore, it passes based on the allowance in RewriteCond #1 for a blank referrer. But this allowance is necessary in order for your site to be accessible to users behind caching proxies. So it's a catch-22.

Access control by referrer is most useful to stop 'casual' hotlinking. It is easily bypassed by determined and knowledgeable persons. In order to more reliably protect your content, a cookies- or password- based method is needed.

Jim

[gcn]

Jim,

> When you do a refresh, that URL is re-fetched, but > with a blank referrer (just like a type-in URL
> would be). Therefore, it passes based on the
> allowance in RewriteCond #1 for a blank referrer.

Thanks for your reply. Never thought of that but makes perfect sense to me.

> Access control by referrer is most useful to
> stop 'casual' hotlinking. It is easily bypassed by > determined and knowledgeable persons. In order to
> more reliably protect your content, a cookies- or
> password- based method is needed.

Yes, I know, even the most casual of users can figure a way around.

What exactly do you mean a "cookies" based method? Can you refer me to more information on how I could implement something like this?

Thanks again!
Gabriel

[jdMorgan]

Simple example: On the "authorized" page that you use to access or to include the download file, set a cookie. When the download file is requested from your server, the server checks the cookie. If present, it provides the file. If missing or outdated, it provides something else. You can use Apache mod_headers (server-side) or JavaScript (client-side) to set the cookie, and mod_rewrite or a server-side script to check the cookie.

In .htaccess, set a cookie for visitors to the page example.com/yourdownload-page.html:

<FilesMatch "^yourdownload-page\.html$">
Header set Set-cookie: "Visited; path=/"
</FilesMatch>

In .htaccess test cookie. If no cookie, redirect request for resource.pdf to goaway.pdf:

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_COOKIE} !^Visited
RewriteRule ^resource\.pdf$ /goaway.pdf [L]

That's a cobbled-together simple example; It's untested, and comes with no warranty or support agreement. But it demonstrates a simple cookie set and check. That's also 99% of what I know about cookies, but you should be able to find more info with some specific searches.

Jim

[gcn]

Jim,

> That's a cobbled-together simple example; It's
> untested, and comes with no warranty or support
> agreement. But it demonstrates a simple cookie set
> and check. That's also 99% of what I know about
> cookies, but you should be able to find more info
> with some specific searches.

Thanks for your help! That's a great start... enough to get me going on my way. I'll definitely need to spend a few minutes doing some research to get my head around the use of cookies on my site.

Gabriel