Hotlink protecting Flash player movies?

.htaccess problem

[blurry]

Hi all :)

I was hoping someone here could help with a hotlink protection problem... This was what we had in our .htaccess file:

RewriteEngine on RewriteCond %{HTTP_REFERER}!^$
RewriteCond %{HTTP_REFERER}!^http://(www\.)?mydomain.com/.*$ [NC]
RewriteRule \.(gif¦jpg¦bmp)$ [mydomain.com...] [R,NC]

It worked fine for our images, and hotlinkers were successfully redirected to our "hotlinker.htm" page.

Recently we decided to protect our Flash player movies from hotlinking as well, and so added "swf" to our rule:

RewriteEngine on RewriteCond %{HTTP_REFERER}!^$
RewriteCond %{HTTP_REFERER}!^http://(www\.)?mydomain.com/.*$ [NC]
RewriteRule \.(gif¦jpg¦bmp¦swf)$ [mydomain.com...] [R,NC]

But since adding that file extension, our Flash movies won't load/play on our site.

Any suggestions or advice?

Thanks in advance,

Blurry

[jdMorgan]

blurry,

Check your raw server logs and examine the Referrer field for these failed requests. If your only access control is referrer-based, then the information you see there should tell you something.

Jim

[blurry]

Hi Jim, thanks for your reply.

I checked our raw logs and immediately noticed that Referrers for ALL our Flash files are blank, even when they are called from a page on our domain. (This is same for both failed and successful requests).

I don't understand why though...

But I guess this at least explains why the Flash movies won't load once we add "swf" to our .htaccess rule.

[jdMorgan]

Your first RewriteCond should have allowed blank referrers, if formatted as shown below. It is generally true that media players don't provide referrers (not sure why they don't support this), and so access control by referrer is even more unreliable for media files than for html-type pages.

RewriteEngine on
RewriteCond %{HTTP_REFERER} .
RewriteCond %{HTTP_REFERER} !^http://(www\.)?mydomain\.com [NC]
RewriteRule \.(gif¦jpg¦bmp¦swf)$ /hotlinker.htm [NC,L]

Note that I have changed the RewriteRule code from a redirect to an internal rewrite, to "hide" the function. I also escaped the period in mydomain.com in the RewriteCond, and trimmed the superfluous ".*$" from the end, since it doesn't do anything but waste CPU time there.

Also note that posting on this board modifies the "¦" pipe character to a broken pipe. You must replace these characters before trying to use code posted here.

You can replace "!^$" with "." in the first RewriteCond as shown; it's shorter and does the same thing.

Remember to flush your browser cache before testing any change to your access control code.

Jim

[blurry]

Thanks Jim, that works brilliantly! The Flash files all seem to be safely protected from hotlinking now, and they still load/play properly on our site :)

Unfortunately, we couldn't get the internal rewrite to work for us though (substituting to the 'hotlinker.htm' file). But when hotlinked, images now show up as red X's, and Flash movies are blank - so I think that's fine, too.

Thanks again for your help :)

[jdMorgan]

The problem is that browsers don't handle changes in major file type (i.e. image format to html format). The following might be more useful; Rewrite image requests to a "special" image, and forbid .swf hotlinking:

RewriteEngine on
RewriteCond %{HTTP_REFERER} ^http://(www\.)?mydomain\.com [NC]
RewriteRule .* - [S=2]
RewriteRule \.(gif¦jpg¦bmp)$ /no_hotlink.gif [L]
RewriteRule \.swf$ - [F]

By way of explanation, if the referrer is your site, "- [S=2]" causes the two subsequent anti-hotlink rules to be skipped with the URL unchanged.

Again, if the browser or swf player provides no referrer, then hotlinking is still possible. That's just an inherent limitation of referrer-based access control.

Jim

[PirvyChinfeld]

Hot linking in flash can easily be achieved by loading variables in at the first frame of the main timeline movie. Such as a 'key' which is stored as a text file or php file or whatever on your server.

Then in the subsequent frames, if that 'variable' key is not met, you can use an 'unloadMovie' event to the _root of the flash movie.

This therefore effectively eliminates the possibility of an external site using your movie. It also saves bandwidth if you set ALL of your assets in the movie in frames 'after' the checkpoint for the loadVariables call to get the 'key' to continue the movie (meaning this is a valid call since the server had the file in question with the right key loaded etc.)

One other fail-safe is to rename the flash player movies extension to something other than .swf. Perhaps an unknown file type extension is best. This way, it becomes much more problematic to decompile the flash movie, until the idiot hackers realize what extension is was to change back to .swf. Still, they will only decompile the location on YOUR server where you call the loadVariables to get the 'key'. Hence, asp, or php etc. is preferred instead of a text file. With server side scripting you can include code that prevents the 'echoing' of the key variable if accessed directly. You could also use .htaccess to protect the 'key' file too.

Last, but NOT least, you can further encrypt the html source of the flash movie coding, you know the < object > tag etc. Then, it takes some nifty decoding to even find the location and 'interesting' file extension that the plugin is using.

One resource for encrypting html for this very purpose is a free utility found at: [dfwstudios.com...]

I use the hex encode technique (javascript1.2+) and ensure the code for the flash object tag is ALL on one line with no line breaks...then encrypt/paste into your page and wooollla. This in conjunction with the aforementioned is 99% effective in locking out flash movies being used without permission.

I'm sure there's lots of questions and gripes and criticism, but hey, my flash movies are finally safe, how about yours? heh heh

PirvyChinfeld is an alias of the web designer with a hole in his head, AKA "Third Eyer".

[blurry]

Thank you both for the replies :)

Jim: Thanks for the explanation - unfortunately we tried but couldn't get your suggestion to work for us (500 internal server error), and it also stopped the Flash movies from playing on our site. Perhaps something else on our server is causing problems *sigh* Incidently, we tested the internal rewrite rule (substituting images and .swf to "hotlinker.htm") on Mozilla Firefox, and that worked perfectly!

PirvyChinfeld: Thanks for the suggestions - I guess if we can't hotlink protect the Flash files with .htaccess we may have to look at some other methods. We did try renaming .swf files with a PHP script, but had a problem with the "decoded" URLs showing up on address bars etc, and it kind of defeated the purpose. I like your idea of using a variable key and unloadMovie though, perhaps that's something we could try in future.

Someone on a Flash discussion board suggested this for our .htaccess:

SetEnvIfNoCase Referer "^http://www.mydomain.com/" locally_linked=1
SetEnvIfNoCase Referer "^http://www.mydomain.com$" locally_linked=1
SetEnvIfNoCase Referer "^http://mydomain.com/" locally_linked=1
SetEnvIfNoCase Referer "^$" locally_linked=1
<FilesMatch "\.(swf)$">
Order Allow,Deny
Allow from env=locally_linked
</FilesMatch>

It was supposed to get around the blank referrer problem but didn't work for us either. I thought I'd post it up anyhow, in case someone else finds it useful.

[jdMorgan]

Same idea, different code.

I should have mentioned that posting on this board modifes the "¦" pipe characters. You must edit them before trying to use code posted here. Also, when you get a server error, check the error log! It will usually tell you just what is wrong.

Jim

[blurry]

Hi, Jim - we did edit the ¦ characters, and remembered to flushed our browser caches each time as you mentioned before...but still no luck here. Our error logs didn't record anything for those failed attempts at all, which is rather odd. And the only thing noticeable in the access logs were the '500' status codes. I think it's a lost cause :( Thanks again for your help though.

[jdMorgan]

> Our error logs didn't record anything for those failed attempts at all, which is rather odd.

If you have access to httpd.conf, make sure your LogLevel is set to "Warn" or "Error" at the highest. Otherwise, you won't see some errors that can cause server failures, and that can make life very difficult.

You may need to ask your host to fix this if you don't have httpd.conf access.

Jim