Security Sandbox of the Webplayer

in Unity 3.0 implementeert de webplayer een beveiligingsmodel dat erg lijkt op dat van de Adobe Flash player™. Deze beveiligingsbeperkingen gelden alleen voor de webplayer en voor de editor als het actieve build-doel WebPlayer is. Het beveiligingsmodel heeft verschillende onderdelen:

• beperkingen op de toegang tot gegevens op een ander domein dan het domein dat uw host .unity3d bestand.
• enige beperking op het gebruik van de Sockets.
• het niet toestaan van het inroepen van een methode die wij verboden achten. (dingen zoals File.Schrappen, enz.).
• het gebruik van het systeem niet toestaan.Reflectie.* om private/interne methoden in de lessen die je niet zelf geschreven.

momenteel worden alleen de eerste twee delen van het beveiligingsmodel geëmuleerd in de Editor.

de ingebouwde muti-player netwerkfunctionaliteit van Unity (UnityEngine.Network, UnityEngine.NetworkView klassen enz.) wordt niet beïnvloed.

dit document beschrijft hoe u ervoor kunt zorgen dat uw inhoud blijft werken met Versie 3.0 van de Unity webplayer.

• zie de Unity API-referentie voor informatie over de WWW-klasse.
• zie de. NET API-referentie voor informatie over de.net-Socket-klasse.

de WWW-klasse en sockets gebruiken hetzelfde beleidsschema, maar daarnaast zijn ze volledig gescheiden systemen. Het WWW-beleid definieert alleen machtigingen voor de webservice waar het beleid wordt gehost, maar socketbeleid is van toepassing op alle TCP/UDP-socket-verbindingen.

de Unity editor wordt geleverd met een” Emulate Web Security ” functie, die het beveiligingsmodel van de webplayer oplegt.Dit maakt het gemakkelijk om problemen te detecteren vanuit het comfort van de editor. U kunt deze instelling vinden inEdit – >projectinstellingen – >Editor. Zie ook de Editor-instellingen.

de Unity webplayer verwacht dat een HTTP-bestand met de naam crossdomain.xml beschikbaar is op het domein dat u wilt benaderen met de WWW-klasse,(hoewel dit niet nodig is als het hetzelfde domein is dat het unity3d-bestand host).

stel je bijvoorbeeld een tetris-spel voor, gehost op de volgende url:

http://gamecompany.com/games/tetris.unity3d

moet toegang krijgen tot een highscore lijst van de volgende url:

http://highscoreprovider.net/gethighscore.php

in dit geval moet u een crossdomain.xml bestand aan de root van de highscoreprovider.net domein zoals dit: http://highscoreprovider.net/crossdomain.xml

de inhoud van het crossdomain.xml – bestand is in het formaat dat door de Flash player wordt gebruikt. Het is zeer waarschijnlijk dat u het crossdomain.xml bestand al vindt. Het beleid in het bestand ziet er zo uit:

<?xml version="1.0"?><cross-domain-policy><allow-access-from domain="*"/></cross-domain-policy>

wanneer dit bestand op http://highscoreprovider.net/crossdomain.xml wordt geplaatst, verklaart de eigenaar van dat domein dat de inhoud van de webserver toegankelijk is voor elke webspeler die uit elk domein komt.

de Unity webplayer ondersteunt de<allow-http-request-headers-from domain > and<site-control permitted-cross-domain-policies > tags niet. Merk op dat crossdomain.xml een ASCII-bestand moet zijn.

Debugging

door een omgevingsvariabele ENABLE_CROSSDOMAIN_LOGGING in te stellen op 1 zullen consoleberichten worden gegenereerd terwijl de Unity runtime het crossdomain.xml bestand ophaalt en decodeert. Op een Mac kunt u globale omgevingsvariabelen instellen in /etc/launchd.conf. Op een PC gebruik Configuratiescherm – >systeem en beveiliging – >systeem – >Geavanceerde systeeminstellingen – >omgevingsvariabelen …

hier is een voorbeeld uitvoer met deze omgevingsvariabele set, wanneer de webplayer een image probeert op te halen van een externe server:

Determining crossdomain.xml location for request: http://www.remoteserver.com/image.jpgAbout to parse url: http://www.remoteserver.com/image.jpgDetermining crossdomain.xml location for request: http://www.remoteserver.com/image.jpgAbout to parse url: http://www.remoteserver.com/crossdomain.xmlAbout to parse url: http://www.remoteserver.com/image.jpgDetermining crossdomain.xml location for request: http://www.remoteserver.com/image.jpgDownload had OK statuscodeReceived the following crossdomain.xml--------------------------------------<?xml version="1.0"?><cross-domain-policy><allow-access-from domain="*"/></cross-domain-policy>----------------------received policyParsing: cross-domain-policycross-domain-policyParsing: allow-access-fromallow-access-from domain: *done parsing policycrossdomain.xml was succesfully parsedAbout to parse url: http://www.remoteserver.com/image.jpgChecking if http://www.remoteserver.com/image.jpg is a valid domainChecking request-host: www.remoteserver.com against valid domain: *All requirements met, the request is approved

bij het draaien in de Editor worden deze berichten naar de Editor geschreven.log. Een poging om een crossdomain.xml – bestand te lezen dat onjuist is opgeslagen als utf16 met een BOM, zal resulteren in een fout bij het ontleden van de xml:

BuildFlashPolicy caught an exception while parsing http://www.remoteserver.com/crossdomain.xml: Expected element

dit komt omdat de BOM niet wordt verwacht. Het gebruik van een niet-ondersteund utf16 bestand zonder BOM zal resulteren in:

BuildFlashPolicy caught an exception while parsing http://www.remoteserver.com/crossdomain.xml: Policy can't be constructed from empty stream.

dit komt omdat de eerste byte in het bestand nul is, waardoor de parser denkt dat het einde van het bestand is bereikt. Crossdomain.xml moet een ASCII-bestand zijn.

implicaties voor het gebruik van Sockets:

een Unity webplayer heeft een socket-beleid nodig om verbinding te kunnen maken met een bepaalde host. Dit beleid wordt standaard gehost door de doelhost op poort 843, maar het kan ook gehost worden op andere poorten. Het functionele verschil met een niet-standaard poort is dat het handmatig moet worden opgehaald met beveiliging.PrefetchSocketPolicy () API call en als het wordt gehost op een poort hoger dan 1024 kan het beleid alleen toegang geven tot andere poorten hoger dan 1024.

bij het gebruik van de standaard poort werkt het als volgt: een Unity webplayer probeert een TCP socket verbinding te maken met een host, Het controleert eerst of de host server de connection.It doet dit door een TCP socket te openen op poort 843, geeft een verzoek uit, en verwacht een socket beleid te ontvangen over de nieuwe verbinding. De Unity webplayer controleert dan of het beleid van de host de verbinding toestaat door te gaan en het zal zonder fout gaan als dat zo is. Dit proces gebeurt transparant met de code van de gebruiker, die niet hoeft te worden gewijzigd om dit beveiligingsmodel te gebruiken. Een voorbeeld van een socket beleid ziet er als volgt uit:

<?xml version="1.0"?><cross-domain-policy> <allow-access-from domain="*" to-ports="1200-1220"/> </cross-domain-policy>"

dit Beleid effectief zegt “inhoud van elk domein is vrij om socket verbindingen te maken op poorten 1200-1220”. De Unity webplayer zal dit respecteren, en weigert elke poging tot aansluiting met een poort buiten dat bereik (een SecurityException zal worden gegooid).

bij het gebruik van UDP-verbindingen kan het beleid ook automatisch worden opgehaald wanneer ze op dezelfde manier moeten worden afgedwongen als bij TCP. Het verschil is dat automatisch ophalen met TCP gebeurt wanneer je verbinding maakt met iets (zorgt ervoor dat je verbinding kunt maken met een server), maar met UDP, omdat het geen verbinding heeft, gebeurt het ook wanneer je een API-punt aanroept dat gegevens verzendt of ontvangt (zorgt ervoor dat je verkeer naar/van een server mag verzenden/ontvangen).

het formaat dat gebruikt wordt voor het socket beleid is hetzelfde als dat van de Flash player, behalve dat sommige tags niet ondersteund worden. De Unity webplayer ondersteunt alleen ” * ” als een geldige waarde voor de domeininstelling en de instelling “naar Poorten” is verplicht.

<?xml version="1.0" encoding="ISO-8859-1"?><!ELEMENT cross-domain-policy (allow-access-from*)><!ELEMENT allow-access-from EMPTY><!ATTLIST allow-access-from domain CDATA #REQUIRED><!ATTLIST allow-access-from to-ports CDATA #REQUIRED>

het socket-beleid is van toepassing op zowel TCP-als UDP-verbindingstypen, zodat zowel UDP-als TCP-verkeer door één beleidsserver kan worden beheerd.

voor uw gemak bieden we een klein programma dat gewoon luistert op poort 843; wanneer het op een verbinding een verzoekstring ontvangt, zal het antwoorden met een geldig socket beleid.De servercode kan gevonden worden in de Unity install map, in Data/Tools/SocketPolicyServer op Windows of /Unity.app/Contents/Tools / SocketPolicyServer op OS X. merk op dat de pre-built uitvoerbare kan worden uitgevoerd op Mac, omdat het een Mono uitvoerbare. Typ ” mono sockpol.exe ‘ om het te runnen. Merk op dat deze voorbeeldcode het correcte gedrag van een socket policy server laat zien. Specifiek verwacht de server een nul-beëindigde tekenreeks te ontvangen die <policy-file-request/>bevat. Het stuurt alleen het socket policy xml-document naar de client als deze string (en precies deze string) is ontvangen. Verder is het vereist dat de XML header en xml body worden verzonden met een enkele socket write. Het breken van de header en de body in afzonderlijke Socket schrijfbewerkingen kan leiden tot beveiligingsuitzonderingen als gevolg van Unity die een onvolledig beleid ontvangt. Als u problemen ondervindt met uw eigen server, overweeg dan om het voorbeeld te gebruiken dat wij u geven. Dit zou u moeten helpen te diagnosticeren of u server-of netwerkproblemen heeft.

netwerkbibliotheken van derden, vaak gebruikt voor multiplayer-gamenetwerken, moeten met deze vereisten kunnen werken zolang ze niet afhankelijk zijn van peer 2 peer-functionaliteit (zie hieronder) maar gebruik maken van dedicated servers. Deze komen soms zelfs uit de doos met ondersteuning voor het hosten van beleid.

Noot: Hoewel de crossdomain.xml – en socket-beleidsbestanden beide xml-documenten zijn en in grote lijnen gelijk zijn, is de manier waarop deze documenten worden aangeboden zeer verschillend. Crossdomain.xml (toegepast op http-aanvragen) wordt opgehaald met http op poort 80, waarbij-as het socket-beleid wordt opgehaald van poort 843 met behulp van een triviale server die het <beleid-bestand-verzoek/>implementeert. U kunt geen http-server gebruiken om het socket policy-bestand uit te geven, noch een server instellen die het Socket policy-bestand gewoon verzendt als antwoord op een socket-verbinding op poort 843. Merk ook op dat elke server waarmee u verbinding maakt een eigen socket policy server vereist.

Debugging

u kunt telnet gebruiken om verbinding te maken met de socket policy server. Een voorbeeldsessie wordt hieronder getoond:

host$ telnet localhost 843Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.<policy-file-request/><?xml version='1.0'?><cross-domain-policy> <allow-access-from domain="*" to-ports="*" /></cross-domain-policy>Connection closed by foreign host.host$

in deze voorbeeldsessie wordt telnet gebruikt om verbinding te maken met de localhost op poort 843. Telnet reageert met de eerste drie regels, en zit dan te wachten tot de gebruiker iets invoert. De gebruiker heeft de string policy request <policy-file-request/> ingevoerd, die de socket policy server ontvangt en reageert met het socket policy. De server verbreekt vervolgens de verbinding waardoor telnet meldt dat de verbinding is gesloten.

Luistersockets

u kunt geen luistersockets aanmaken in de webplayer, het kan niet fungeren als server. Daarom kunnen webplayers niet rechtstreeks met elkaar communiceren (peer 2 peer). Als u TCP-sockets gebruikt, kunt u alleen verbinding maken met externe eindpunten als dit is toegestaan via het socket-beleidssysteem. Voor UDP werkt het hetzelfde, maar het concept is een beetje anders omdat het een verbindingsloos protocol is, je hoeft niet te verbinden/luisteren om pakketten te verzenden/ontvangen. Het werkt door te afdwingen dat je alleen pakketten van een server kunt ontvangen als hij eerst heeft gereageerd met een geldig beleid met de allow-access-from domain tag.

dit is allemaal zo vervelend, waarom bestaat al dit spul?

de socket en WWW beveiligingsfuncties bestaan om mensen te beschermen die de Unity Web Player installeren. Zonder deze beperkingen zou een aanval als de volgende mogelijk zijn:

• Bob werkt in het Witte Huis.
• Frank is kwaadaardig. Hij schrijft een unity webgame die zich voordoet als een spel, maar op de achtergrond doet hij een WWW-verzoek aan http://internal.whitehouse.gov/LocationOfNuclearBombs.pdf. intern.whitehouse.gov is een server die niet bereikbaar is vanaf het internet, maar wel bereikbaar is vanaf Bob ‘ s werkstation omdat hij bij het Witte Huis werkt.
• Frank stuurt deze PDF-bytes naar http://frank.com/secretDataUploader.php
• Frank plaatst dit spel op http://www.frank.com/coolgame.unity3d
• Frank overtuigt Bob om het spel te spelen.
• Bob speelt het spel.
• spel downloadt stilletjes het geheime document en stuurt het naar Frank.

met de WWW en socket beveiligingsfuncties zal deze aanval mislukken, omdat voor het downloaden van de pdf unity http://internal.whitehouse.gov/crossdomain.xml controleert, met de bedoeling om die server te vragen: “zijn de gegevens die je op je server hebt Beschikbaar voor publiek gebruik?”. Het plaatsen van een crossdomain.xml op een webserver kan worden gezien als het antwoord op die vraag. In het geval van dit voorbeeld, de systeembeheerder van internal.whitehouse.gov zal geen crossdomain plaatsen.xml op de server, die Unity zal leiden om de pdf niet te downloaden.

om de mensen die de Unity Web Player installeren te beschermen, moeten mensen die zich in Unity ontwikkelen bij het ontwikkelen van content met deze beveiligingsmaatregelen rekening houden. Dezelfde beperkingen zijn aanwezig in alle belangrijke plugin technologieën. (Flash, Silverlight, Shockwave)

Exceptions

om de juiste balans te vinden tussen het beschermen van gebruikers van webspelers en het eenvoudig maken van het leven van content-ontwikkelaars, hebben we een uitzondering op het beveiligingsmechanisme zoals hierboven beschreven geïmplementeerd:

u mag afbeeldingen downloaden van servers die geen crossdomain hebben.xml-bestand. Echter, het enige wat je mag doen met deze afbeeldingen is ze te gebruiken als texturen in uw scène. Het is niet toegestaan om GetPixel() op hen te gebruiken. Het is ook niet toegestaan om terug te lezen vanaf het scherm. Beide pogingen zullen resulteren in een Veiligheidsuitzondering wordt gegooid:

SecurityException: No read access to the texture data: at (wrapper managed-to-native) UnityEngine.Texture2D:GetPixel (int,int)

de redenering is hier is dat het goed is om de afbeelding te downloaden, zolang de inhoud ontwikkelaar krijgt geen toegang tot het. Dus je kunt het aan de gebruiker tonen, maar je kunt de bytes van de afbeelding niet terugsturen naar een andere server. Als u toegang tot de pixelgegevens nodig hebt, plaats dan een crossdomain.xml – bestand op de server waar de afbeeldingen vandaan komen.