i Unity 3.0 implementerer internetspilleren en sikkerhedsmodel, der ligner den, der bruges af Adobe Flash player turt. Disse sikkerhedsbegrænsninger gælder kun for netspilleren og for editoren, når det aktive build-mål er Netspilleren. Sikkerhedsmodellen har flere dele:
- begrænsninger for adgang til data på et andet domæne end det, der er vært for din .unity3d-fil.
- nogle begrænsninger på brugen af stikkene.
- afvisning af påkaldelse af enhver metode, vi anså for uden grænser. (ting som fil.Slet osv.).
- ikke tillader brugen af systemet.Refleksion.* for at ringe til private / interne metoder i klasser skrev du ikke selv.
i øjeblikket er kun de to første dele af sikkerhedsmodellen emuleret i editoren.
den indbyggede muti-player netværksfunktionalitet af Unity (UnityEngine.Network, UnityEngine.NetworkView klasser osv.) påvirkes ikke.
dette dokument beskriver, hvordan du sikrer dig, at dit indhold fortsætter med at fungere med version 3.0.
- se Unity API reference for oplysninger om klassen.
- Se.Net API reference for oplysninger om. net Socket klasse.
den første klasse og stikkontakter bruger det samme politikskema, men udover at de er helt separate systemer. Politikken definerer kun tilladelser på den internettjeneste, hvor politikken er hostet, men socket-politikker gælder for alle TCP/UDP-stikforbindelser.
Unity-editoren leveres med en” emulere internetsikkerhed ” – funktion, der pålægger netspillerens sikkerhedsmodel.Dette gør det nemt at opdage problemer fra editorens komfort. Du kan finde denne indstilling inEdit – >Projektindstillinger-> Editor. Se også redigeringsindstillingerne.
Enhedsspilleren forventer, at en http-serveret politikfil med navnet crossdomain.xml er tilgængelig på det domæne, du vil have adgang til med klassen, (selvom dette ikke er nødvendigt, hvis det er det samme domæne, der er vært for unity3d-filen).
forestil dig for eksempel et Tetris-spil, der er vært på følgende url:
http://gamecompany.com/games/tetris.unity3d
skal have adgang til en highscore liste fra følgende url:
http://highscoreprovider.net/gethighscore.php
i dette tilfælde skal du placere en crossdomain.xml fil ved roden af highscoreprovider.net domæne som dette: http://highscoreprovider.net/crossdomain.xml
indholdet af crossdomain.xml – filen er i det format, der bruges af Flash player. Det er meget sandsynligt, at du finder filen crossdomain.xml, der allerede er på plads. Politikken i filen ser sådan ud:
<?xml version="1.0"?><cross-domain-policy><allow-access-from domain="*"/></cross-domain-policy>når denne fil er placeret på http://highscoreprovider.net/crossdomain.xml, erklærer ejeren af dette domæne, at indholdet af hjemmesidens server kan tilgås af enhver internetspiller, der kommer fra ethvert domæne.
Unity-afspilleren understøtter ikke <Tillad-http-anmodning-overskrifter-fra domæne> og <site-kontrol tilladt-cross-domain-Politikker> tags. Bemærk, at crossdomain.xml skal være en ASCII-fil.
Debugging
Indstilling af en miljøvariabel ENABLE_CROSSDOMAIN_LOGGING til 1 vil medføre, at konsolmeddelelser genereres, når Unity runtime henter og afkoder filen crossdomain.xml. På en Mac kan du indstille globale miljøvariabler i /etc/launchd.conf. På en PC brug Kontrolpanel – > System og sikkerhed- >System- >Avancerede systemindstillinger- > miljøvariabler…
her er et eksempel på output med dette miljøvariabelsæt, når netspilleren forsøger at hente et billede fra en fjernserver:
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 approvednår du kører i editoren, skrives disse meddelelser til editoren.log. Forsøg på at læse en crossdomain.xml fil forkert gemt som utf16 med en BOM vil resultere i en manglende analyse af:
BuildFlashPolicy caught an exception while parsing http://www.remoteserver.com/crossdomain.xml: Expected elementdette skyldes, at BOM ikke forventes. Brug af en ikke-understøttet utf16 fil uden BOM vil resultere i:
BuildFlashPolicy caught an exception while parsing http://www.remoteserver.com/crossdomain.xml: Policy can't be constructed from empty stream.dette skyldes, at den første byte i filen er nul, hvilket får parseren til at tro, at den er nået til slutningen af filen. Crossdomain.xml skal være en ASCII-fil.
implikationer for brug af stikkontakter:
en Enhedsspiller har brug for en sokkelbetjent politik for at oprette forbindelse til en bestemt vært. Denne politik er som standard hostet af målværten på port 843, men den kan også hostes på andre porte. Den funktionelle forskel med en ikke-standardport er, at den skal hentes manuelt med sikkerhed.PREFETCHSOCKETPOLICY () API-opkald, og hvis det hostes på en port, der er højere end 1024, kan politikken kun give adgang til andre porte, der er højere end 1024.
når du bruger standardporten, fungerer det sådan: en Enhedspiller forsøger at oprette en TCP-stikforbindelse til en vært, den kontrollerer først, at værtsserveren accepterer connection.It gør dette ved at åbne en TCP-stik på port 843, udsteder en anmodning og forventer at modtage en sokkelpolitik over den nye forbindelse. Enheden kontrollerer derefter, at værtens politik tillader forbindelsen at gå videre, og den fortsætter uden fejl, hvis det er tilfældet. Denne proces sker gennemsigtigt med brugerens kode, som ikke behøver at blive ændret for at bruge denne sikkerhedsmodel. Et eksempel på en sokkelpolitik ser sådan ud:
<?xml version="1.0"?><cross-domain-policy> <allow-access-from domain="*" to-ports="1200-1220"/> </cross-domain-policy>"denne politik siger effektivt “indhold fra ethvert domæne er gratis at oprette sokkelforbindelser I Porte 1200-1220”. Enheden vil respektere dette og afvise ethvert forsøg på sokkelforbindelse ved hjælp af en port uden for dette interval (en Sikkerhedsundtagelse vil blive kastet).
når du bruger UDP-forbindelser, kan politikken også hentes automatisk, når de skal håndhæves på samme måde som med TCP. Forskellen er, at automatisk hentning med TCP sker, når du opretter forbindelse til noget (sikrer, at du har lov til at oprette forbindelse til en server), men med UDP, da det er forbindelsesløst, sker det også, når du ringer til et API-punkt, der sender eller modtager data (sikrer, at du har lov til at sende/modtage trafik til/fra en server).
det format, der bruges til socket-politikken, er det samme som det, der bruges af Flash player, bortset fra at nogle tags ikke understøttes. Enheden understøtter kun “*” som en gyldig værdi for domæneindstillingen, og indstillingen “til-Porte” er obligatorisk.
<?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-politikken gælder for både TCP-og UDP-forbindelsestyper, så både UDP-og TCP-trafik kan styres af en politikserver.
for nemheds skyld leverer vi et lille program, der blot lytter i port 843; når den på en forbindelse modtager en anmodningsstreng, svarer den med en gyldig sokkelpolitik.Serverkoden kan findes i mappen Unity install, I Data/Tools/SocketPolicyServer på vinduer eller /Unity.bemærk, at den forudbyggede eksekverbare kan køres på Mac, da den er en Mono-eksekverbar. Skriv bare ” mono sockpol.ekse ” at køre det. Bemærk, at denne eksempelkode viser den korrekte opførsel af en socket-politikserver. Specifikt forventer serveren at modtage en nul-afsluttet streng, der indeholder <politik-fil-anmodning/>. Det sender kun til klienten socket policy-dokumentet, når denne streng (og netop denne streng) er modtaget. Desuden er det nødvendigt, at header og krop sendes med en enkelt socket skrive. At bryde overskriften og kroppen i separate sokkelskrivningsoperationer kan medføre sikkerhedsundtagelser på grund af enhed, der modtager en ufuldstændig politik. Hvis du oplever problemer med din egen server, kan du overveje at bruge det eksempel, Vi leverer. Dette skal hjælpe dig med at diagnosticere, om du har server-eller netværksproblemer.
tredjeparts netværksbiblioteker, der ofte bruges til multiplayer-spilnetværk, skal kunne arbejde med disse krav, så længe de ikke er afhængige af peer 2 peer-funktionalitet (se nedenfor), men bruger dedikerede servere. Disse kommer undertiden endda ud af kassen med support til hostingpolitikker.
Bemærk: Mens crossdomain.xml og socket policy filer er begge dokumenter og er stort set ens, den måde, at disse dokumenter serveres er meget forskellige. Crossdomain.xml(som anvendes på http-anmodninger) hentes ved hjælp af http på port 80, hvor-som socket-politikken hentes fra port 843 ved hjælp af en triviel server, der implementerer <politik-fil-anmodning/>. Du kan ikke bruge en http-server til at udstede socket policy-filen eller oprette en server, der blot sender socket policy-filen som svar på en socket-forbindelse på port 843. Bemærk også, at hver server, du opretter forbindelse til, kræver sin egen socket policy server.
Debugging
du kan bruge telnet til at oprette forbindelse til socket policy server. Et eksempel session er vist nedenfor:
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$i dette eksempel session, telnet bruges til at oprette forbindelse til localhost på port 843. Telnet reagerer med de første tre linjer og sidder derefter og venter på, at brugeren indtaster noget. Brugeren har indtastet den politiske anmodningsstreng < politik-fil-anmodning / >, som socket policy-serveren modtager og reagerer med socket-politikken. Serveren afbryder derefter, hvilket får telnet til at rapportere, at forbindelsen er lukket.
Lyttestik
du kan ikke oprette lyttestik i netspilleren, den kan ikke fungere som en server. Derfor kan internetspillere ikke kommunikere direkte med hinanden (peer 2 peer). Når du bruger TCP-stik, kan du kun oprette forbindelse til eksterne slutpunkter, forudsat at det er tilladt via socket policy-systemet. For UDP fungerer det samme, men konceptet er lidt anderledes, da det er en forbindelsesløs protokol, du behøver ikke at oprette forbindelse/lytte til at sende/modtage pakker. Det fungerer ved at håndhæve, at du kun kan modtage pakker fra en server, hvis han først har svaret med en gyldig politik med tagget allow-access-from domain.
dette er bare så irriterende, hvorfor findes alle disse ting?
sikkerhedsfunktionerne i socket findes for at beskytte folk, der installerer Unity-afspilleren. Uden disse begrænsninger ville et angreb som følgende være muligt:
- Bob arbejder i Det Hvide Hus.
- Frank er ond. Han skriver et unity-spil, der foregiver at være et spil, men i baggrunden anmoder han om http://internal.whitehouse.gov/LocationOfNuclearBombs.pdf. intern.hvidhus.gov er en server, der ikke kan nås fra internettet, men kan nås fra Bobs arbejdsstation, fordi han arbejder i Det Hvide Hus.
- Frank sender disse pdf-bytes til http://frank.com/secretDataUploader.php
- Frank placerer dette spil på http://www.frank.com/coolgame.unity3d
- Frank overbeviser på en eller anden måde Bob om at spille spillet.
- Bob spiller spillet.
- spillet lydløst henter det hemmelige dokument, og sender det til Frank.
med sikkerhedsfunktionerne i sikkerhedssystemet vil dette angreb mislykkes, for før du henter pdf ‘ En, kontrollerer unity http://internal.whitehouse.gov/crossdomain.xml med den hensigt at spørge den server: “er de data, du har på din server, tilgængelige til offentlig brug?”. Placering af et crossdomain.det kan ses som svaret på dette spørgsmål. I tilfælde af dette eksempel er systemoperatøren af internal.whitehouse.gov vil ikke placere et crossdomain.på sin server, hvilket vil føre til, at Unity ikke henter pdf-filen.
for at beskytte de mennesker, der installerer Unity-afspilleren, skal mennesker, der udvikler sig i Unity, desværre tage disse sikkerhedsforanstaltninger i betragtning, når de udvikler indhold. De samme begrænsninger er til stede i alle større plugin-teknologier. (Flash, Silverlight, chokbølge)
undtagelser
for at finde den rette balance mellem at beskytte brugere af Internetafspillere og gøre livet for indholdsudviklere let, har vi implementeret en undtagelse fra sikkerhedsmekanismen beskrevet ovenfor:
du har lov til at hente billeder fra servere, der ikke har et crossdomain.fil. Det eneste, du har lov til at gøre med disse billeder, er dog at bruge dem som teksturer i din scene. Du må ikke bruge Getpiksel () på dem. Du har heller ikke lov til at læse tilbage fra skærmen. Begge forsøg vil resultere i, at en Sikkerhedsundtagelse kastes:
SecurityException: No read access to the texture data: at (wrapper managed-to-native) UnityEngine.Texture2D:GetPixel (int,int)ræsonnementet er her er, at det er okay at hente billedet, så længe indholdsudvikleren ikke får adgang til det. Så du kan vise det til brugeren, men du kan ikke sende bytes af billedet tilbage til en anden server. Hvis du har brug for adgang til billeddataene, skal du placere en crossdomain.xml – fil på den server, hvor billederne hentes fra.