Security Sandbox of the Webplayer

in Unity 3.0, webplayer toteuttaa tietoturvamallin, joka on hyvin samankaltainen kuin Adobe Flash player™. Nämä tietoturvarajoitukset koskevat vain webplayeria ja editoria, kun aktiivinen build-kohde on WebPlayer. Turvamallissa on useita osia:

• rajoitukset, jotka koskevat tietojen käyttöä verkkotunnuksessa, joka on muu kuin se, joka isännöi sinua .unity3d-tiedosto.
• jonkin verran rajoituksia pistorasioiden käytölle.
• kiellämme käyttämästä mitään menetelmää, jonka olemme katsoneet kielletyksi. (asioita, kuten tiedosto.Poista jne.).
• järjestelmän käytön kieltäminen.Heijastus.* soittaa yksityisiä / sisäisiä menetelmiä tunneilla et kirjoittanut itse.

tällä hetkellä Editorissa emuloidaan vain tietoturvamallin kahta ensimmäistä osaa.

Unityn (UnityEngine.Network, UnityEngine.NetworkView luokat jne.) sisäänrakennettu mutipelaajien verkostoitumistoiminto ei vaikuta.

tässä asiakirjassa kerrotaan, miten voit varmistaa, että sisältösi toimii Unity webplayerin version 3.0 kanssa.

• Katso tietoa WWW-luokasta Unity API-viitteestä.
• Katso. Net API-viite. Net Socket-luokasta.

WWW-luokka ja pistorasiat käyttävät samaa käytäntörakennetta, mutta sen lisäksi ne ovat täysin erillisiä järjestelmiä. WWW-käytäntö määrittää käyttöoikeudet vain verkkopalvelussa, jossa käytäntö on hostattu, mutta socket-käytännöt koskevat kaikkia TCP/UDP-socket-yhteyksiä.

Unity-editorin mukana tulee” emuloida Web Security ” – ominaisuus, joka määrää webplayerin tietoturvamallin.Näin ongelmat on helppo havaita toimittajan mukavuudesta. Tämä asetus löytyy osoitteesta edit – > Project Settings – >Editor. Katso myös muokkaimen asetukset.

Unity webplayer odottaa, että http served policy-tiedosto crossdomain.xml on saatavilla verkkotunnuksella, jota haluat käyttää WWW-luokan kanssa(vaikka tätä ei tarvita, jos kyseessä on sama verkkotunnus, joka isännöi unity3d-tiedostoa).

esimerkiksi, kuvittele tetris-peli, jota isännöidään seuraavassa osoitteessa:

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

tarvitsee käyttää highscore-luetteloa seuraavasta url-osoitteesta:

http://highscoreprovider.net/gethighscore.php

tällöin crossdomain.xml – tiedosto on sijoitettava highscoreprovider.net domain like this: http://highscoreprovider.net/crossdomain.xml

crossdomain.xml – tiedoston sisältö on Flash Playerin käyttämässä muodossa. On hyvin todennäköistä, että löydät crossdomain.xml – tiedoston jo valmiiksi. Tiedoston käytäntö näyttää tältä:

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

kun tämä tiedosto on sijoitettu http://highscoreprovider.net/crossdomain.xml, kyseisen verkkotunnuksen omistaja vakuuttaa, että mikä tahansa webplayer voi päästä käsiksi minkä tahansa verkkotunnuksen sisältöön.

Unity webplayer ei tue <allow-http-request-headers-from domain> ja <site-control allowed-cross-domain-policies> tageja. Huomaa, että crossdomain.xml pitäisi olla ASCII-tiedosto.

virheenkorjaus

ympäristömuuttujan ENABLE_CROSSDOMAIN_LOGGING asettaminen arvoon 1 aiheuttaa konsoliviestien syntymisen, kun Unity runtime hakee ja purkaa crossdomain.xml – tiedoston. Macissa voi asettaa globaaleja ympäristömuuttujia /etc/launchd.conf. PC: llä käytä ohjauspaneelia – > järjestelmä ja turvallisuus – > järjestelmä – > Järjestelmän lisäasetukset – > ympäristömuuttujat …

tässä on esimerkki tulosteesta tällä ympäristömuuttujajoukolla, kun webplayer yrittää hakea kuvaa etäpalvelimelta:

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

Editorissa suoritettaessa nämä viestit kirjoitetaan Editorille.kirjaudu. Yrittämällä lukea crossdomain.xml tiedostoa, joka on tallennettu väärin nimellä utf16 kanssa BOM, xml: n jäsentäminen epäonnistuu:

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

tämä johtuu siitä, että BOM ei ole odotettavissa. Käyttämällä tukematonta utf16 tiedostoa, jonka numero on BOM, tuloksena on:

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

tämä johtuu siitä, että tiedoston ensimmäinen tavu on nolla, mikä saa jäsentäjän luulemaan sen tulleen tiedoston loppuun. Crossdomain.xml täytyy olla ASCII-tiedosto.

Implications for use of Sockets:

a Unity webplayer needs a socket served policy to connect to a specific host. Tämä käytäntö on oletusarvoisesti target-isännän isännöimä portilla 843, mutta sitä voidaan isännöidä myös muissa porteissa. Toiminnallinen ero ei-oletus portti on, että se on käsin noudettava turvallisuus.PrefetchSocketPolicy () API-kutsu ja jos sitä isännöidään yli 1024-portissa, käytäntö voi antaa pääsyn vain muihin yli 1024-portteihin.

käytettäessä oletusporttia se toimii näin: Unity webplayer yrittää luoda TCP-socket-yhteyden isäntään, se tarkistaa ensin, että isäntäpalvelin hyväksyy connection.It tekee tämän avaamalla TCP-socket port 843, antaa pyynnön, ja odottaa saavansa socket politiikan yli uuden yhteyden. Unity webplayer sitten tarkistaa, että isäntä politiikka sallii yhteyden mennä eteenpäin ja se etenee virheettömästi, jos niin. Tämä prosessi tapahtuu läpinäkyvästi käyttäjän koodille, jota ei tarvitse muokata tämän suojausmallin käyttämiseksi. Esimerkki pistorasiapolitiikasta näyttää tältä:

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

tämä käytäntö sanoo tehokkaasti ”sisältöä tahansa verkkotunnuksen on vapaasti tehdä socket yhteydet satamissa 1200-1220”. Yhtenäisyys webplayer kunnioittaa tätä, ja hylkää kaikki yrittänyt pistorasia yhteyden portin ulkopuolella, että alue (SecurityException heitetään).

UDP-yhteyksiä käytettäessä käytäntö voidaan myös hakea automaattisesti silloin, kun se on pantava täytäntöön samalla tavalla kuin TCP: ssä. Ero on, että automaattinen noutaminen TCP tapahtuu, kun yhteyden johonkin (varmistaa, että sinulla on oikeus muodostaa yhteys palvelimeen), mutta UDP, koska se on connectionless, se tapahtuu myös, kun soitat API kohta, joka lähettää tai vastaanottaa tietoja (varmistaa, että sinulla on oikeus lähettää/vastaanottaa liikennettä/palvelimelta).

socket-käytäntöön käytetty muoto on sama kuin Flash Playerin käyttämä, paitsi että joitakin tägejä ei tueta. Unity webplayer tukee vain ” * ”kelvollisena arvona verkkotunnusasetukselle ja” to-ports ” – asetus on pakollinen.

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

socket-käytäntö koskee sekä TCP-että UDP-yhteystyyppejä, joten sekä UDP-että TCP-liikennettä voidaan ohjata yhdellä käytäntöpalvelimella.

avuksesi tarjoamme pienen ohjelman, joka yksinkertaisesti kuuntelee porttia 843; kun yhteys vastaanottaa pyynnön merkkijono, se vastaa voimassa socket politiikkaa.Palvelinkoodi löytyy Unity install-kansion sisältä, Windowsin Data/Tools/SocketPolicyServer tai /Unity-palvelusta.app/Contents/Tools / SocketPolicyServer on OS X. huomaa, että valmiiksi rakennettu suoritustiedosto voidaan ajaa Macissa, koska se on mono-suoritustiedosto. Kirjoita ” mono sockpol.exe ” johtaa sitä. Huomaa, että tämä esimerkkikoodi näyttää socket policy Serverin oikean käyttäytymisen. Erityisesti palvelin odottaa saavansa nollapäätetyn merkkijonon, joka sisältää <policy-file-request / >. Se lähettää asiakkaalle socket policy xml-asiakirjan vain, kun tämä merkkijono (ja juuri tämä merkkijono) on vastaanotettu. Lisäksi vaaditaan, että xml-otsikko ja xml-runko lähetetään yhdellä pistokkeella. Otsikon ja rungon murtaminen erillisiin socket write-operaatioihin voi aiheuttaa tietoturvapoikkeuksia, koska Unity saa epätäydellisen käytännön. Jos sinulla on ongelmia oman palvelimesi kanssa, harkitse tarjoamaamme esimerkkiä. Tämän pitäisi auttaa diagnosoimaan, onko sinulla palvelimen tai verkon ongelmia.

kolmansien osapuolten verkostoitumiskirjastojen, joita käytetään yleisesti moninpeliverkostoon, pitäisi pystyä toimimaan näiden vaatimusten mukaisesti, kunhan ne eivät riipu peer 2-vertaispalveluista (KS.jäljempänä) vaan käyttävät dedikoituja palvelimia. Nämä joskus jopa tulevat ulos laatikosta tukea hosting politiikkaa.

Huom.: Vaikka crossdomain.xml – ja socket-käytäntötiedostot ovat molemmat xml-dokumentteja ja suurin piirtein samanlaisia, näiden dokumenttien toimitustapa on hyvin erilainen. Crossdomain.xml (joka koski http-pyyntöjä) noudetaan http-portista 80, jossa-socket-käytäntö haetaan portista 843 käyttäen triviaalia palvelinta, joka toteuttaa <policy-file-request/>. Et voi käyttää http-palvelinta socket-käytäntötiedoston antamiseen, etkä perustaa palvelinta, joka yksinkertaisesti lähettää socket-käytäntötiedoston vastauksena socket-yhteyden porttiin 843. Huomaa myös, että jokainen palvelin, johon muodostat yhteyden, vaatii oman socket policy-palvelimensa.

Vianetsintä

voit käyttää telnet: ää yhteyden muodostamiseen socket policy-palvelimeen. Esimerkkisessio näkyy alla:

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$

tässä esimerkkitilaisuudessa telnetiä käytetään yhteyden muodostamiseen localhost-portille 843. Telnet vastaa kolmella ensimmäisellä rivillä ja istuu sitten odottamassa, että käyttäjä syöttää jotain. Käyttäjä on syöttänyt käytäntöpyyntömerkkijonon <policy-file-request / >, jonka socket-käytäntöpalvelin vastaanottaa ja vastaa socket-käytäntöpyyntömerkkiin. Tämän jälkeen palvelin katkeaa aiheuttaen telnetin ilmoituksen, että yhteys on suljettu.

Kuuntelupistokkeet

verkkopeliin ei voi luoda kuuntelupistokkeita, se ei voi toimia palvelimena. Siksi Verkkopelaajat eivät voi kommunikoida suoraan keskenään (peer 2 peer). Kun käytät TCP-pistorasioita, voit muodostaa yhteyden etäpisteisiin vain, jos se on sallittua socket policy-järjestelmän kautta. UDP se toimii sama, mutta käsite on hieman erilainen, koska se on connectionless protokolla, sinun ei tarvitse liittää/kuunnella lähettää / vastaanottaa paketteja. Se toimii valvomalla, että voit vastaanottaa paketteja palvelimelta vain, jos hän on vastannut ensin voimassa olevalla käytännöllä allow-access-from domain – tunnisteella.

tämä kaikki on vain niin ärsyttävää, miksi kaikki tämä on olemassa?

pistorasia ja WWW-turvaominaisuudet ovat olemassa suojaamaan ihmisiä, jotka asentavat Unity Web Playerin. Ilman näitä rajoituksia seuraavan kaltainen hyökkäys olisi mahdollinen:

• Bob on töissä Valkoisessa talossa.
• Frank on paha. Hän kirjoittaa unity webgame, joka teeskentelee olevansa peli,mutta taustalla tekee WWW-pyynnön http://internal.whitehouse.gov/LocationOfNuclearBombs.pdf. sisäinen.whitehouse.Gov on palvelin, joka ei ole tavoitettavissa Internetistä, mutta on tavoitettavissa Bobin työasemalta, koska hän työskentelee Valkoisessa talossa.
• Frank lähettää nämä pdf-tavut http://frank.com/secretDataUploader.php
• Frank asettaa tämän pelin http://www.frank.com/coolgame.unity3d
• Frank jotenkin vakuuttaa Bobin pelaamaan peliä.
• RoPS pelaa peliä.
• Game Lataa salaisen dokumentin hiljaisesti ja lähettää sen Frankille.

WWW-ja socket-suojausominaisuuksilla tämä hyökkäys epäonnistuu, koska ennen PDF-tiedoston lataamista unity tarkistaa http://internal.whitehouse.gov/crossdomain.xml tarkoituksenaan kysyä palvelimelta: ”onko palvelimellasi oleva data julkista käyttöä varten?”. Asetan ristiviittauksen.xml webserver voidaan nähdä vastaus tähän kysymykseen. Tässä esimerkissä verkonhaltija internal.whitehouse.gov ei aseta risteys.xml palvelimellaan, mikä johtaa Unity Ei Lataa pdf.

valitettavasti Unity Web Playerin asentajien suojelemiseksi Unityssa kehittyvien ihmisten on otettava nämä turvatoimet huomioon sisältöä kehitettäessä. Samat rajoitukset ovat kaikissa tärkeimmissä liitännäistekniikoissa. (Flash, Silverlight, Shockwave)

poikkeukset

löytääksemme oikean tasapainon Verkkosoittimien käyttäjien suojaamisen ja sisällönkehittäjien elämän helpottamisen välillä olemme toteuttaneet poikkeuksen yllä kuvattuun tietoturvamekanismiin:

voit ladata kuvia palvelimilta, joilla ei ole ristiverkkoa.xml-tiedosto. Kuitenkin, ainoa asia, mitä sinulla on lupa tehdä näitä kuvia on käyttää niitä tekstuurit kohtaus. Niihin ei saa käyttää Getpixeliä (). Et myöskään saa lukea takaisin näytöltä. Molemmat yritykset johtavat Security Exception heitetään:

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

perusteluna on, että kuvan lataaminen on sallittua, kunhan sisällönkehittäjä ei pääse siihen käsiksi. Voit siis näyttää sen käyttäjälle, mutta et voi lähettää kuvan tavuja takaisin jollekin toiselle palvelimelle. Jos tarvitset pääsyn pikselitietoihin, aseta crossdomain.xml – tiedosto palvelimelle, josta kuvat haetaan.