Hot Linking, Secure Token, Allow Domains, General Security

I have an EXTREME concern about a few posts I’ve been reading regarding hot linking, secure token, allow domains, etc.

Please bear with me as I set this up…

I have a website with two sections using Wowza.

One section is FREE while the other is a PAID area.

I have two applications, and two different content folders.

Each application has it’s own secure token

Allow domains is set to my website only

I’ve labeled my applications and content very descriptively (and easily extrapolated)

If someone views my ‘FREE’ section page source, deduces what the ‘PAID’ section would be, constructs a webpage on their own server using the deduced information and links to my player, would they be able to play my PAID content?

If they are able to view my paid content, seems like this entire exercise was frutile.

Regards,

Jake

It all depends on how you protect your paid content. If you protect it with some type of username/password or session based security where the user needs to enter his/her information to view the content and this security information is also validated through Wowza Pro then you should be OK. The issue here is more around embedding the swf in another web page. This is difficult to protect against. This requires that you protect the .swf itself and how it is served. If the content that is viewed using that swf requires some type of authentication then you should be OK.

Charlie

You could just link them to your domain. In onConnect handler do something like this:

String pageUrl = client.getProperties().getPropertyStr("connectpageUrl");
boolean reject = !pageUrl.startsWith("http://my.domain.com");

Then accept/reject the connection based on this info. That way only the domain part needs to match.

Charlie

I am not sure I am right person on the htaccess front. I am not much of an Apache jockey. I have dabbled but hard for me to make exacting recommendations. Richard, or anyone else?

Charlie

I don’t want to throw this off into the weeds so please excuse me if this does but here is a post that describes a method to prevent hot linking using Apache .htaccess files:

Preventing image hotlinking: An improved tutorial

It seems like a good approach if you are using Apache.

Charlie

I have not done anything on the module front. Shouldn’t be too hard to do with the Wowza IDE.

Charlie

I am sure you can sort out how to extend it to support multiple domains. I have created a clean, sticky thread here:

https://www.wowza.com/forums/showthread.php?t=5239

Charlie

What you are not checking is the html container. AllowDomains checks the domain of the SWF was served from. If someone constructs a web page that hotlinks the swf from your web site, AllowDomains or SecureToken will not help.

You can check the html container from Flash like this:

if (ExternalInterface.available)
{
var href:String = ExternalInterface.call("function(){return window.location.href;}");
// handle href
}

Or you can do the same on Wowza in onConnect like this:

public void onConnect(IClient client, RequestFunction function,
			AMFDataList params) {		
String pageUrl = client.getProperties().getPropertyStr("connectpageUrl");
// handle pageUrl
}

Or you can use a 3rd party Flash obfuscator that can limit use by domain.

Richarrd

Wow…thanks for the quick responses!

I’m not sure if I’m being naive because of my noobe’ness but I think this information (i.e. security hole) is VERY important and should clearly be stated somewhere. I’m sure there are many, many other Wowza users sleeping soundly at night thinking their content is safe…just as I was until yesterday. I even had frank discussions in a webmasters forum stating with no uncertainty that my content was safe while another member was adamant he had seen Wowza hacked on 3 occasions.

In my business, I wear absolutely every hat possible and thus I’m master of nothing. Richard, I appreciate your suggestions but they may as well be written in Hieroglyphics. I’m actually quite proud of the distance I’ve come with Wowza all things considered.

Charlie, yes I’m using user/pass to protect the paid area. It’s being done using a 3rd party processor who re-writes my .htaccess. I’m almost certain I’m not the only one using Wowza in its current setup on my server. The protected area simply protects my html pages, which links to my paid content application/content folder in the Wowza director on my server. I really liked the idea of keeping my content outside of the public_html area.

Is it possible to make a module where I could add properties like .htaccess location or what ever else might be needed? This seems like an extremely important issue and one worthy of high priority.

As stated above, I’m wearing every single hat possible. I do want to learn the IDE stuff but right now I need a solution I can implement now with very little time and effort.

Kindest Regards,

Jake

you can also use something as simple as this, add to to the top of your fla action script, it wont prevent people from downloading your swf but is a usefull extra to the things suggested here. I always password protect my swf and have this included in my code. so instead of opening and playing the swf it opens my page explaining i own the content and the user is attempting to view a swf from an unauthorised location

var urls=new Array(“http://your-allowed-website.com/”, “http://your-second-allowed-website.com/” );

var ok=false;

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

var u=urls*;*

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

}

if(!ok) {

getURL(“http://www.your-website-piracy-warning/deeplinking/index.php","_top”);

stop();

} else {

play();

}

Richard’s suggestion is a good one. It will tie the .swf file to your html page. If you change the html page name or path you will need to modify the code that is verifying this.

BTW, I will try to integrate this type of check into the MediaSecurity package. We have been more focused on securing the connection between the Flash player and Wowza Pro. Certainly faciliting the security between the hosting web page and the swf is also of interest. If other have suggestions on approaches to making this more secure please jump in and let me know.

Charlie

I don’t know about .htaccess either, but I think it could work. Test and see.

If you can modify the source code of the Player you can use the Actionscript solution above, the one with External Interface.

Richard

Sorry about the oversight. Posts do get lost in the shuffle sometimes.

The examples are AS3. It’s an easy client-side way to do this. Here is the solution more complete:

private var href:String = "";
if (ExternalInterface.available)
{
href = ExternalInterface.call("function(){return window.location.href;}");
}
if (href != "YourWebsite.com")
{
// handle bad domain.
}

Notice that this method does not depend on javascript in the html container, it injects a little javascript so users can’t see it what you are checking. And it doesn’t depend on an html container either, if the swf is playing by itself the check will fail

Richard

Just take out “private” if the var is declared inside a function. If you want the var available to different functions declare it outside a function with private keyword.

I think this will work to prevent the primary concern. Be specific what href should match. I don’t know if it will prevent other tricks.

Richard

var href:String = "";

Put it in com.jeroenwijering.models.RTMPModel.as in the load() function.

Add import to the top:

import flash.external.ExternalInterface;

And modify load() function:

/** Load content. **/
override public function load(itm:Object):void {
// Add from here:
var href:String = "";
if (ExternalInterface.available)
{
href = ExternalInterface.call("function(){return window.location.href;}");
}
if (href != "YourWebsite.com")
{
// handle bad domain.
return; // just refuse to load RTMPModel and your done. You don't owe anyone an explanation.
}
// end Add
	item = itm;
	position = 0;
	model.mediaHandler(video);
	connection.connect(item['streamer']);
	model.sendEvent(ModelEvent.BUFFER,{percentage:0});
	model.sendEvent(ModelEvent.STATE,{newstate:ModelStates.BUFFERING});
};

Richad

Right, I modified my post above for the 4.4 version.

Richard

Yes, but trace it out and see exactly what it is and don’t forget about localhost. This is what I get from what I am working on now:

href=

http://localhost/ChatApp/ChatApp.html?debug=true#

Richard

Like this:

trace(href);

Using trace statements in Flash editor is basic. I would spend a few days learning Flash at this point. That will save you a lot of time. lynda.com has tons of videos. Or get a Flash book that teaches Flash editor basics. I did both when I was ramping-up on Flash.

Richard

Create a new Wowza Module Class with the Wowza IDE and modify the onConnect like this:

public void onConnect(IClient client, RequestFunction function,
			AMFDataList params) {		
String ip = client.getIp();
// handle ip
}

I have a Wowza module with allow and deny ip lists. Checks the allow list first then the deny list. contact richard.lanham@gmail.com

Richard