Web Player Security?

Unity Engine
1

Currently, I am closing in on a playable Closed Alpha Build of my upcoming Browser-based game. I want to secure the Web Player as best as possible to prevent theft of the .unity3d file and leakage.

I imagine that hosting my Closed Alpha Web Player Build behind a secure page with say assigned user names and passwords, or pre-generated keys would be a good first step, maybe obfuscating the HTML/PHP page serving the Web Player might help a bit also, and Site-Locking the Web Player… is there anything I might be missing to Secure my Web Player Closed Alpha Build?

Any other possible methods of theft you can think of I need to be concerned about? Or anyway for someone to bypass the Site Lock if they did manage to get the .unity3d file?

2

You could check Application.absoluteURL and if it does not match your hosted address you can make the game not start at all (Check in a loader scene), that way they may have the .unity3d file but it is kind of useless them. (Probebly what you meant with “Site-Locking the Web Player”).

That combined with your login system should do the trick fine.

1 Like
3

Awesome that’s very helpful! I was planing to use this Method:

I found that snipt of code here at the bottom of this link:
http://docs.unity3d.com/Manual/UnityWebPlayerandbrowsercommunication.html

Although this might be good to add as a second layer of security for Site-Locking, I think your mention of Application.absoluteURL is better because it does not rely on Javascript. To my understanding this Application.ExternalEval is an external Javascript call which probably someone could easily disable Javascript from running to bypass this one.

4

One other thing you might think of doing… Use a .php page to serve your .unity3d file and secure access to it. This is something I do when I sell my asset through FastSpring. The users can log into my site to download updates but they are secured. I basically have this (not exact, it’s just an example):

Database:
FileId (int), VersionId (uniqueidentifier), OriginalFileName (nvarchar)

So the record might look like this:

27 | e880caa4-bdaa-4248-ad9d-80e903d6aeb2 | jsondotnetunity_version.unitypackage

In this case I also have a Product table with base info about the product and a ProductVersions table which manages the major, minor and build revisions for the product. VersionId points to the version. You won’t need anything quite that complicated as you’re just linking to a single file.

Now people log in and they hit download which hits a secured controller action on my site (I’m using MVC):

http://www.parentelement.com/private/downloadfile/e880caa4-bdaa-4248-ad9d-80e903d6aeb2

And on my system I have something like:

WebRoot
|
|___ App_Data
       |
       |___ Downloads

And in Downloads I have a file something like: e880caa4-bdaa-4248-ad9d-80e903d6aeb2.pedownload

Now in my controller action I get the GUID as a URL parameter. App_Data is not accessible via the web, only via code so it creates a filestream to e880caa4-bdaa-4248-ad9d-80e903d6aeb2.pedownload and writes it to the response stream with a content type of application/octet-stream and an attachment type of file with the filename being jsondotnetunity_version.unitypackage. So when the user downloads the file, they get the original file name and download it, but on the system it’s secured and unless you’re logged in you cannot directly access the file.

You could do the same thing with your .unity3d file. Just created a PHP page that will read in the hidden / secured file from disk, stream it back to the browser as originalFileName.unity3d and make sure you set the appropriate MIME Type when returning it. This will prevent non-logged in users from ever being able to directly download the file. It will also prevent other sites from hotlinking your unity3d file. You should still be checking that absolute URL as well though as that will be important.

One more thing you can do… when the game starts, have it just make a web request to your site. Just have a blank page that it can hit and make sure you don’t have a crossdomain.xml file that allows access from everywhere. As long as your game is hosted from your site the request will succeed. If someone hosts it elsewhere, it will puke when trying to make that request because it will be a disallowed cross domain request.

1 Like
5

Just reading this now @Dustin-Horne , that’s really impressive security there! Thank you!