Preventing deep linking of Flash games

Several times, the Flash-based GasGames have been copied to other, completely unrelated sites or deep linked (the Flash application is embedded directly to another page so that the user has no clue about the origin of the app), of course without authorization. This article is not about copyright issues; suffice it to say that I don't mind people downloading the games and copying them to their friends, but deep linking and displaying advertisements next to the game is not acceptable.

Here are a few countermeasures I have implemented. None of them are completely secure, but they should provide enough of an obstacle so that the potential violators go somewhere else. These tricks are not platform-specific on the server side and they can be adapted to other formats apart from Flash, provided that some browser variables can be accessed programmatically. Some of the tricks rely on certain browser features, which are common, but not everyone has them enabled; they work in most cases nevertheless.

Intermediate page that serves the Flash file

The Flash application is not directly available, ie. it is not under the root directory of the site. Instead of that, there is a script or a page that serves the Flash file if several things check ok:

The format of the request parameters is correct. Such a basic thing: always validate parameters!
The game is already published. In this case, all the games have a specific time of publication; it's fairly easy to guess if the address of the newst game ends with getgame.gas?26 that there might be a new game at url getgame.gas?27.
The referrer is not an external site, or it is empty. Browsers send the referring url with every request. If a link to an external site is clicked from here, there will be a line in the http request that says HTTP_REFERER: http://arje.net. It's quite an easy way to tell if something deep linked. However, some ISPs filter out the referrer from the requests and requests without the referrer are always accepted.
The file assigned to the ID number exists. Just to fail gracefully even if someone forgets to copy the file to the server.

If any of the checks fail, the web server sends a response, which redirects the browser to the index page of the games.

Time-dependant hash code

A very effective way to prevent deep linking is to use cryptography. The page containing the Flash application creates a digital signature based on a secret word and the current time (year, month, day, hour and minutes). The signature is appended to the url. This effectively changes the url of the Flash file every minute (or precisely, every other minute; there must be some tolerance to allow requests that were sent at 59 seconds and 99 hundedths of a second of a certain minute and that would get to the server at 00.01 of the next minute).

Framekiller

The index page checks whether it is the outermost frame; this will cause pages linked using frames to load themselves directly to the window. In other words, it kills the other content on the page. This is very simple to accomplish using Javascript:

if(top.location!=location) top.location.replace(location);

English translation: "if the location of the outermost frame is not the location of this page, load this page to top". If the page is outermost, the location of top is the same as the location of the page and nothing is done.

This has quite an interesting effect when combined to the previous methods, since deep linked games open the index page of all the games without the external site. The deep linked game, used to lure people into external site opens the source site and the external site becomes the one providing visitors. (This may have some really bizarre legal issues, I pre-emptively pity the court that needs to judge such a case.)

Url checks in Flash apps

If an external site loads source code to be executed from your site, you get the chance to do quite a lot of different things. In Flash environment, the sandbox security model of Flash prevents anything truly nasty being done (such as delete files), but it provides ways to control the browser of the visitors of the external site.

Before doing anything, all the Flash applications check the source url. If this is in the list of acceptable urls, it proceeds. Otherwise it opens the source site. In ActionScript this is as follows:

var urls=new Array("http://www.homokaasu.org/", "http://homokaasu.org/");








var ok=false;








for(var i=0;i<urls.length && !ok;i++) {








  var u=urls[i];








  if(_url.substr(0, u.length).toLowerCase()==u) ok=true;








}








if(!ok) {









  getURL("http://homokaasu.org","_top");








  stop();









} else {








  play();








}

This will cause the Flash application to stop at the first frame if the url of the game does not begin with any of the urls listed in the first row. A bit more efficient way would be to somehow encrypt the urls. It wouldn't stand decompilation and a lot of scrutiny, but at least it would be effective against direct editing and replacement.

If the url of the game file is not in the list, it opens the front page of homokaasu.org to the outermost frame. Same effect as described previously.

Being nice

The outcome of the previous methods is rather nice. I decided to be kind and just grab the visitors - who quite likely don't even realize what happens.

Being nasty

Of course, it would be as easy to display goatse to visitors of the deep linking site or crash their browser. It would also be it easy to make it seem to visitors that the deep linking site is stretching the boundaries of obscenity or that it causes their browser to crash. It's just the final step that does all this.

Maybe I shouldn't tell this very nasty way to irritate people:

while(true) getURL(_url, "_blank");

The previous line of ActionScript causes the Flash application to open an infinite amount of windows, containing duplicates of the application, which start opening new windows...