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.
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.
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?
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:
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:
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.
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
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.
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
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.
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});
};
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.