a Webplayer biztonsági homokozója

a Unity 3.0-ban a webplayer olyan biztonsági modellt valósít meg, amely nagyon hasonló az Adobe Flash player által használt modellhez. Ezek a biztonsági korlátozások csak a webplayerre és a szerkesztőre vonatkoznak, ha az aktív build cél a WebPlayer. A biztonsági modell több részből áll:

• korlátozások az adatokhoz való hozzáférés a domain nem az egyik tárhely .unity3d fájl.
• néhány korlátozás az aljzatok használatára.
• minden olyan módszer meghívásának letiltása, amelyet korlátoknak tekintünk. (például Fájl.Törlés stb.).
• a rendszer használatának letiltása.Reflexió.* privát/belső módszerek hívása az osztályokban, amelyeket nem maga írt.

jelenleg csak a biztonsági modell első két része emulálódik a szerkesztőben.

a Unity (UnityEngine.Network, UnityEngine.NetworkView osztályok stb.) Beépített muti-player hálózati funkcióit ez nem érinti.

ez a dokumentum leírja, hogyan lehet biztosítani, hogy a tartalom továbbra is működjön a Unity webplayer 3.0 verziójával.

• lásd a Unity API referencia információt a WWW osztály.
• a.net Socket osztályra vonatkozó információkért lásd a. net API hivatkozást.

a WWW osztály és a socketek ugyanazt a házirend-sémát használják, de emellett teljesen különálló rendszerek. A WWW házirend csak azon webszolgáltatás engedélyeit határozza meg, ahol a házirend található, de a socket házirendek az összes TCP/UDP socket kapcsolatra vonatkoznak.

a Unity editor egy “Emulate Web Security” funkcióval rendelkezik, amely előírja a webplayer biztonsági modelljét.Ez megkönnyíti a problémák felismerését a szerkesztő kényelméből. Ez a beállítás megtalálható inEdit – >Projektbeállítások-> szerkesztő. Lásd még a szerkesztő beállításait.

a Unity webplayer elvárja, hogy a crossdomain.xml nevű http-kiszolgálási házirend-fájl elérhető legyen azon a domainen, amelyhez a WWW osztállyal szeretne hozzáférni(bár erre nincs szükség, ha ugyanaz a tartomány tárolja az unity3d fájlt).

képzeljen el például egy tetris játékot, amely a következő url-en található:

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

a toplista listához a következő url-ről kell hozzáférnie:

http://highscoreprovider.net/gethighscore.php

ebben az esetben egy crossdomain.xml fájlt kell elhelyeznie a highscoreprovider.net domain mint ez: http://highscoreprovider.net/crossdomain.xml

a crossdomain.xml fájl tartalma a Flash player által használt formátumban van. Nagyon valószínű, hogy megtalálod a crossdomain.xml fájlt már a helyén. A fájlban lévő házirend így néz ki:

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

amikor ez a fájl http://highscoreprovider.net/crossdomain.xml – re kerül, a domain tulajdonosa kijelenti, hogy a webszerver tartalmát bármely tartományból érkező webplayer elérheti.

a Unity webplayer nem támogatja a < allow-http-request-headers-from domain>és < site-control allowed-cross-domain-policies> címkéket. Ne feledje, hogy a crossdomain.xml fájlnak ASCII fájlnak kell lennie.

hibakeresés

ha egy ENABLE_CROSSDOMAIN_LOGGING környezeti változót 1 értékre állít be, akkor konzolüzenetek keletkeznek, amikor a Unity futásidejű letölti és dekódolja a crossdomain.xml fájlt. Mac számítógépen a globális környezeti változókat /etc/launchd.conf – ben állíthatja be. PC – n használja a Vezérlőpultot – > System And Security – >System – > Advanced system settings – > környezeti változók …

Íme egy példa a környezeti változók készletével, amikor a webplayer megpróbál lekérni egy képet egy távoli szerverről:

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

amikor a szerkesztőben fut, ezeket az üzeneteket a szerkesztőnek írják.napló. A crossdomain.xml fájl utf16 – ként helytelenül BOM – ként tárolt olvasásának kísérlete az xml elemzésének sikertelenségét eredményezi:

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

ez azért van, mert a BOM nem várható. Egy nem támogatott utf16 fájl használata BOM nélkül:

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

ennek oka az, hogy a fájl első bájtja nulla, ami miatt az elemző azt gondolja, hogy elérte a fájl végét. Crossdomain.xml ASCII fájlnak kell lennie.

a socketek használatának következményei:

a Unity webplayernek socket kiszolgálási házirendre van szüksége ahhoz, hogy egy adott gazdagéphez csatlakozzon. Ezt a házirendet alapértelmezés szerint a célállomás üzemelteti a 843-as porton, de más portokon is tárolható. A funkcionális különbség egy nem alapértelmezett porttal szemben az, hogy manuálisan kell letölteni a biztonsággal.PrefetchSocketPolicy() API hívás, és ha 1024-nél nagyobb porton van tárolva, a házirend csak 1024-nél nagyobb portokhoz adhat hozzáférést.

az alapértelmezett port használatakor ez így működik: a Unity webplayer megpróbál TCP socket kapcsolatot létesíteni egy gazdagéppel, először ellenőrzi, hogy a gazdagép szerver elfogadja-e a connection.It ezt úgy teszi, hogy megnyit egy TCP socket-et a 843-as porton, kérést ad ki, és elvárja, hogy socket házirendet kapjon az új kapcsolaton keresztül. A Unity webplayer ezután ellenőrzi, hogy a gazdagép házirendje lehetővé teszi-e a kapcsolat folytatását, és ha igen, hiba nélkül folytatódik. Ez a folyamat átláthatóan történik a felhasználó kódjával, amelyet nem kell módosítani a biztonsági modell használatához. Egy példa a socket politika így néz ki:

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

ez a házirend gyakorlatilag azt mondja: “bármely tartomány tartalma szabadon csatlakozhat az 1200-1220 portokhoz”. A Unity webplayer tiszteletben tartja ezt, és elutasít minden olyan socket kapcsolatot, amely ezen a tartományon kívüli portot használ (a SecurityException dobásra kerül).

UDP-kapcsolatok használatakor a házirend automatikusan lekérhető, ha a TCP-hez hasonló módon kell végrehajtani őket. A különbség az, hogy az automatikus Lekérés a TCP-vel akkor történik, amikor csatlakozik valamihez (biztosítja, hogy csatlakozhasson egy szerverhez), de az UDP-vel, mivel kapcsolat nélküli, akkor is megtörténik, ha bármilyen API-pontot hív, amely adatokat küld vagy fogad (biztosítja, hogy forgalmat küldhet/fogadhat egy szerverre/szerverről).

a socket házirend formátuma megegyezik a Flash player által használt formátummal, kivéve, ha egyes címkék nem támogatottak. A Unity webplayer csak a ” * ” -t támogatja érvényes értékként a domain beállításhoz, a “to-ports” beállítás pedig kötelező.

<?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>

a socket házirend mind a TCP, mind az UDP kapcsolattípusokra vonatkozik, így mind az UDP, mind a TCP forgalmat egy házirend-kiszolgáló vezérelheti.

az Ön kényelme érdekében egy kis programot biztosítunk, amely egyszerűen a 843-as porton hallgat; amikor egy kapcsolaton kérési karakterláncot kap, érvényes socket házirenddel válaszol.A kiszolgáló kódja megtalálható a Unity install mappában, a Data/Tools/SocketPolicyServer Windows vagy /Unity alatt.app / tartalom / eszközök / SocketPolicyServer OS X. vegye figyelembe, hogy az előre elkészített futtatható futtatható Mac, mivel ez egy mono futtatható. Csak írja be a ” mono sockpol.exe ” futtatni. Vegye figyelembe, hogy ez a példakód a socket házirend-kiszolgáló helyes viselkedését mutatja. Pontosabban a kiszolgáló egy nulla végződésű karakterláncot vár, amely <policy-file-request/> – et tartalmaz. Csak akkor küldi el az ügyfélnek a Socket policy xml dokumentumot, amikor ez a karakterlánc (és pontosan ez a karakterlánc) megérkezett. Ezenkívül szükséges, hogy az xml fejléc és az xml törzs egyetlen socket írással legyen elküldve. A fejléc és a törzs külön socket írási műveletekre bontása biztonsági kivételeket okozhat, mivel a Unity hiányos házirendet kap. Ha bármilyen problémát tapasztal a saját szerverével kapcsolatban, kérjük, fontolja meg az általunk nyújtott példa használatát. Ez segít diagnosztizálni, hogy van-e szerver vagy hálózati problémája.

harmadik féltől származó hálózati könyvtáraknak, amelyeket általában a többjátékos játékokhoz használnak, képesnek kell lenniük ezeknek a követelményeknek való megfelelésre, mindaddig, amíg nem függenek a peer 2 peer funkciójától (lásd alább), de dedikált szervereket használnak. Ezek néha még a dobozból is kijönnek a tárhely-Irányelvek támogatásával.

Megjegyzés: Míg a crossdomain.xml és a socket policy fájlok egyaránt xml dokumentumok, és nagyjából hasonlóak, ezeknek a dokumentumoknak a kiszolgálása nagyon eltérő. Crossdomain.xml (amely a http kérésekre vonatkozik) a http használatával kerül letöltésre a 80-as porton, ahol-mivel a socket házirendet a 843-as portról tölti be egy triviális szerver segítségével, amely végrehajtja a <házirendet-file-request/>. Nem használhat http-kiszolgálót a socket policy fájl kiadására, sem olyan kiszolgálót, amely egyszerűen elküldi a socket policy fájlt a 843-as porton lévő socket kapcsolatra válaszul. Vegye figyelembe azt is, hogy minden kiszolgálóhoz, amelyhez csatlakozik, saját socket policy kiszolgálóra van szükség.

hibakeresés

a telnet használatával csatlakozhat a socket házirend-kiszolgálóhoz. Az alábbiakban egy példa munkamenet látható:

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$

ebben a példában a telnet a 843-as porton található localhosthoz való csatlakozásra szolgál. A Telnet az első három sorral válaszol, majd várja, hogy a felhasználó beírjon valamit. A felhasználó beírta a <policy-file-request/> karakterláncot, amelyet a Socket policy server fogad és a socket policy-val válaszol. A kiszolgáló ezután leválasztja a kapcsolatot, aminek következtében a telnet jelzi, hogy a kapcsolat lezárult.

Listening sockets

nem hozhat létre listening socketeket a webplayerben, nem működhet szerverként. Ezért a webplayerek nem tudnak közvetlenül kommunikálni egymással (peer 2 peer). TCP sockets használata esetén csak távoli végpontokhoz csatlakozhat, feltéve, hogy ez megengedett a socket policy rendszeren keresztül. Az UDP esetében ugyanúgy működik, de a koncepció egy kicsit más, mivel kapcsolat nélküli protokoll, nem kell csatlakozni/hallgatni a csomagok küldéséhez / fogadásához. Úgy működik, hogy érvényesíti, hogy csak akkor fogadhat csomagokat egy szerverről, ha először érvényes házirenddel válaszolt a allow-access-from domain címkével.

ez az egész annyira idegesítő, miért létezik ez a sok cucc?

a Socket és a WWW biztonsági funkciók azért léteznek, hogy megvédjék a Unity Weblejátszót telepítő embereket. E korlátozások nélkül a következő támadás lehetséges:

• Bob a fehér házban dolgozik.
• Frank gonosz. Ír egy unity webgame, hogy úgy tesz, mintha egy játék, de a háttérben nem egy WWW kérést http://internal.whitehouse.gov/LocationOfNuclearBombs.pdf. belső.whitehouse.a gov egy olyan szerver, amely nem érhető el az internetről, de Elérhető Bob munkaállomásáról, mert a fehér házban dolgozik.
• Frank elküldi azokat a pdf bájtokat http://frank.com/secretDataUploader.php
• Frank elhelyezi ezt a játékot http://www.frank.com/coolgame.unity3d
• Frank valahogy meggyőzi Bobot, hogy játsszon a játékkal.
• Bob játssza a játékot.
• a játék csendben letölti a titkos dokumentumot, és elküldi Franknek.

a WWW és socket biztonsági funkciókkal ez a támadás sikertelen lesz, mert a PDF letöltése előtt a unity ellenőrzi http://internal.whitehouse.gov/crossdomain.xml, azzal a szándékkal, hogy megkérdezze a szervert: “a szerveren lévő adatok nyilvános használatra elérhetők?”. Elhelyezése crossdomain.xml egy webszerver lehet tekinteni, mint a válasz erre a kérdésre. Ebben a példában a rendszer üzemeltetője internal.whitehouse.gov nem tesz egy crossdomain.xml a szerverén, ami arra készteti az Unity-t, hogy ne töltse le a pdf-t.

sajnos a Unity Weblejátszót telepítő emberek védelme érdekében a Unity-ben fejlődő embereknek figyelembe kell venniük ezeket a biztonsági intézkedéseket a tartalom fejlesztésekor. Ugyanezek a korlátozások vannak jelen az összes főbb plugin technológiában. (Flash, Silverlight, Shockwave)

kivételek

annak érdekében, hogy megtaláljuk a megfelelő egyensúlyt a Weblejátszó felhasználók védelme és a tartalomfejlesztők életének megkönnyítése között, a fent leírt biztonsági mechanizmus alóli kivételt alkalmaztunk:

képeket tölthet le olyan szerverekről, amelyek nem rendelkeznek crossdomainnel.xml fájl. Ezekkel a képekkel azonban csak annyit tehet, hogy textúraként használja őket a jelenetben. Nem használhatja a GetPixel() függvényt. Azt is nem szabad olvasni vissza a képernyőn. Mindkét kísérlet a SecurityException dobását eredményezi:

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

az érvelés itt az, hogy rendben van a kép letöltése, mindaddig, amíg a tartalomfejlesztő nem fér hozzá. Így megjelenítheti a felhasználónak, de a kép bájtjait nem küldheti vissza más szerverre. Ha hozzáférésre van szüksége a pixeladatokhoz, akkor helyezzen el egy crossdomain.xml fájlt arra a kiszolgálóra, ahonnan a képeket letölti.