GameSec – Unity3D – 1

Unity’s documentation is pretty good for the developers who want to create cool games, but ones on the critical supporting features like security are not very detailed. Make no mistake, Unity does have good security features like the web player sandbox that helps maintain the security posture but I feel the documentation coverage on these needs to be more detailed.

As I try to get more acquainted with Unity’s world of game development I am taking some notes on the questions I had, and kind of got answers to. And hence the ramblings below 🙂

Unity Security – Permissions Policy files

There are two security policy files that control the access permissions on content that a Unity web player is allowed to access, or not. These are: crossdomain.xml and socket security policy file.

Difference between crossdomain.xml file and the socket security policy file.

The crossdomain.xml file affects HTTP, HTTPS and FTP access to content on a server and it has no effect on restrictions to be imposed for socket connections. To impose restrictions for socket connections, a socket policy server is required to allow, or disallow, Unity web player based socket access.

Does Unity use/require both crossdomain.xml as well as the socket security policy files?

Yes! While both the files use the same policy schema, the crossdomain.xml file only defines permissions on the web services hosted on the server where the crossdomain.xml file is placed, the socket security policies apply to all TCP/UDP socket connections to that server.

For Unity, the http served policy file, crossdomain.xml, is relevant for WWW class in the UnityEngine namespace. For domains different from the domain that is hosting the unity3d file, the Unity web player expects the crossdomain.xml file to be available on the domain it wants to access with the WWW class.

Unity Socket Connections

Before Unity web players can connect to any serve, like the ones on the networks, it is required that the hosts permit such connections. The hosts can manage the socket level connection permissions using the socket policy file.

This socket security policy file is by default hosted by the target host on port 843.

Note: The socket security policy file can be hosted on other ports as well. The functional difference with a non-default port is that it must be manually fetched with Security.PrefetchSocketPolicy() API call and if it is hosted on a port higher than 1024 the policy can only give access to other ports higher than 1024.

A Socket policy file defines what hosts (think client) can connect to a system (think server) and to which ports those hosts are permitted to connect.

The format used for the Unity socket policy file is similar to that used by the Flash player. The schema of the file is as below:

Example Unity security socket policy file:

This policy effectively says “Content from any domain is free to make socket connections at ports 80 and 443”. The Unity web-player will reject any attempted socket connections using a port outside that range and will throw a SecurityException.

Note: The to-ports field in the allow-access-from element in the socket security policy file specifies what ports are available to the Unity web player trying to connect to the server. While wildcards (“*”), port ranges, and/or individual ports can be specified within this field, it recommended that administrators specify only those ports for which they explicitly want to allow access to the connecting web player.

The main points of distinction between the Flash and Unity socket security policy file are:

1. A limitation with the Unity’s socket policy file vis-à-vis Flash socket policy file is that Unity web player only supports “*” as a valid value for the domain setting. The implication is that any web player in the wild can attempt to establish socket connectivity to the server.
2. The Unity webplayer does not support the and tags.

To be continued…