i Unity 3.0 implementerar webplayer en säkerhetsmodell som är mycket lik den som används av Adobe Flash player bisexual. Dessa säkerhetsbegränsningar gäller endast för webplayer och för redigeraren när det aktiva byggmålet är WebPlayer. Säkerhetsmodellen har flera delar:
- begränsningar för åtkomst till data på en annan domän än den som är värd för din .unity3d-fil.
- viss begränsning av användningen av uttagen.
- att inte tillåta åberopande av någon metod som vi ansåg utanför gränserna. (saker som fil.Radera, etc).
- att inte tillåta användning av systemet.Reflektion.* att ringa privata / interna metoder i klasser du inte skriva själv.
för närvarande emuleras endast de två första delarna av säkerhetsmodellen i redigeraren.
den inbyggda muti-player-nätverksfunktionen för Unity (UnityEngine.Network, UnityEngine.NetworkView klasser etc) påverkas inte.
det här dokumentet beskriver hur du ser till att ditt innehåll fortsätter att fungera med version 3.0 av Unity webplayer.
- se Unity API-referensen för information om WWW-klassen.
- se.net API-referensen för information om. NET-Uttagsklassen.
WWW-klassen och uttagen använder samma policyschema men förutom att de är helt separata system. WWW-policyn definierar bara behörigheter för webbtjänsten där policyn är värd men socket-policyer gäller för alla TCP/UDP-socket-anslutningar.
Unity editor levereras med en” emulera Web Security ” – funktionen, som ställer webplayer säkerhetsmodell.Detta gör det enkelt att upptäcka problem från redaktörens komfort. Du hittar den här inställningen iedit – >Projektinställningar – > Editor. Se även Redigeringsinställningarna.
Unity webplayer förväntar sig att en HTTP-serverad principfil med namnet crossdomain.xml ska vara tillgänglig på domänen du vill komma åt med WWW-klassen(även om det inte behövs om det är samma domän som är värd för unity3d-filen).
föreställ dig till exempel ett tetris-spel, värd på följande url:
http://gamecompany.com/games/tetris.unity3d
behöver komma åt en highscore lista från följande url:
http://highscoreprovider.net/gethighscore.php
i det här fallet måste du placera en crossdomain.xml – fil i roten till highscoreprovider.net domän som denna: http://highscoreprovider.net/crossdomain.xml
innehållet i crossdomain.xml – filen är i det format som används av Flash player. Det är mycket troligt att du hittar filen crossdomain.xml redan på plats. Policyn i filen ser ut så här:
<?xml version="1.0"?><cross-domain-policy><allow-access-from domain="*"/></cross-domain-policy>när den här filen placeras på http://highscoreprovider.net/crossdomain.xml, ägaren av den domänen förklarar attinnehållet i webbservern kan nås av någon webplayer som kommer från en domän.
Unity webplayer stöder inte<Tillåt-http-request-headers-från domänen > och<site-control tillåten-cross-domain-policyer > taggar. Observera att crossdomain.xml ska vara en ASCII-fil.
felsökning
om du ställer in en miljövariabel ENABLE_CROSSDOMAIN_LOGGING till 1 skapas konsolmeddelanden när Unity runtime hämtar och avkodar filen crossdomain.xml. På en Mac kan du ställa in globala miljövariabler i /etc/launchd.conf. På en PC använd Kontrollpanelen – >System och säkerhet – >System – > Avancerade systeminställningar->miljövariabler …
här är ett exempel ut med denna miljövariabeluppsättning, när webplayer försöker hämta en bild från en fjärrserver:
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ör i redigeraren skrivs dessa meddelanden till redigeraren.logga. Försök att läsa en crossdomain.xml fil felaktigt lagrad som utf16 med en BOM kommer att resultera i ett misslyckande att tolka xml:
BuildFlashPolicy caught an exception while parsing http://www.remoteserver.com/crossdomain.xml: Expected elementdetta beror på att BOM inte förväntas. Om du använder en icke-stödd utf16 – fil utan BOM kommer det att resultera i:
BuildFlashPolicy caught an exception while parsing http://www.remoteserver.com/crossdomain.xml: Policy can't be constructed from empty stream.detta beror på att den första byten i filen är noll, vilket får tolkaren att tro att den har nått slutet av filen. Crossdomain.xml måste vara en ASCII-fil.
konsekvenser för användning av uttag:
en Unity webplayer behöver en socket serverad policy för att ansluta till en viss värd. Denna policy är som standard värd för målvärden på port 843 men den kan också vara värd för andra portar. Den funktionella skillnaden med en icke-standardport är att den måste hämtas manuellt med säkerhet.PrefetchSocketPolicy () API-anrop och om det finns på en port som är högre än 1024 kan policyn bara ge åtkomst till andra portar som är högre än 1024.
när du använder standardporten fungerar det så här: en Unity webplayer försöker göra en TCP-socket-anslutning till en värd, den kontrollerar först att värdservern accepterar connection.It gör detta genom att öppna ett TCP-uttag på port 843, utfärdar en förfrågan och förväntar sig att få en uttagspolicy över den nya anslutningen. Unity webplayer kontrollerar sedan att värdens policy tillåter anslutningen att gå vidare och det kommer att fortsätta utan fel om så är fallet. Denna process sker transparent för användarens kod, som inte behöver ändras för att använda denna säkerhetsmodell. Ett exempel på en uttagspolicy ser ut så här:
<?xml version="1.0"?><cross-domain-policy> <allow-access-from domain="*" to-ports="1200-1220"/> </cross-domain-policy>"denna policy säger effektivt ”innehåll från vilken domän som helst är gratis att göra uttagsanslutningar vid portarna 1200-1220”. Unity webplayer kommer att respektera detta och avvisa alla försök till uttagsanslutning med en port utanför det intervallet (en SecurityException kommer att kastas).
när du använder UDP-anslutningar kan policyn också hämtas automatiskt när de behöver verkställas på liknande sätt som med TCP. Skillnaden är att automatisk hämtning med TCP händer när du ansluter till något (säkerställer att du får ansluta till en server), men med UDP, eftersom det är anslutningslöst, händer det också när du ringer till någon API-punkt som skickar eller tar emot data (säkerställer att du får skicka/ta emot trafik till/från en server).
formatet som används för uttagspolicyn är detsamma som det som används av Flash player, förutom att vissa taggar inte stöds. Unity webplayer stöder bara ” * ”som ett giltigt värde för domäninställningen och inställningen” till-portar ” är 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-principen gäller både TCP-och UDP-anslutningstyper så att både UDP-och TCP-trafik kan styras av en principserver.
för din bekvämlighet tillhandahåller vi ett litet program som helt enkelt lyssnar på port 843; när den är på en anslutning får den en förfrågningssträng, kommer den att svara med en giltig uttagspolicy.Serverkoden finns i mappen Unity install, I Data/Tools /SocketPolicyServer på Windows eller / Unity.app/innehåll/verktyg / SocketPolicyServer på OS X. Observera att den förbyggda körbara kan köras på Mac eftersom det är en mono körbar. Skriv bara ” mono sockpol.exe ” för att köra den. Observera att den här exempelkoden visar korrekt beteende hos en socket-principserver. Specifikt förväntar sig servern att få en nollterminerad sträng som innehåller <policy-file-request/>. Det skickar bara xml-dokumentet socket policy till klienten när den här strängen (och exakt den här strängen) har tagits emot. Vidare krävs att xml-rubriken och xml-kroppen skickas med en enda socket-skrivning. Att bryta huvudet och kroppen i separata socket-skrivoperationer kan orsaka säkerhetsundantag på grund av att Unity får en ofullständig policy. Om du upplever några problem med din egen server kan du överväga att använda exemplet som vi tillhandahåller. Detta bör hjälpa dig att diagnostisera om du har server-eller nätverksproblem.
tredje parts nätverksbibliotek, som vanligtvis används för multiplayer-spelnätverk, bör kunna arbeta med dessa krav så länge de inte är beroende av peer 2 peer-funktionalitet (se nedan) men använder dedikerade servrar. Dessa kommer ibland till och med ut ur lådan med stöd för värdpolicyer.
notera: Medan crossdomain.xml och socket-policyfilerna båda är xml-dokument och är i stort sett lika, är det sätt som dessa dokument serveras mycket olika. Crossdomain.xml(som tillämpades på http-förfrågningar) hämtas med http på port 80, där-som socket-principen hämtas från port 843 med en trivial server som implementerar <policy-file-request/>. Du kan inte använda en http-server för att utfärda Socket-principfilen eller konfigurera en server som helt enkelt skickar Socket-principfilen som svar på en socket-anslutning på port 843. Observera också att varje server du ansluter till kräver en egen Socket policy server.
felsökning
du kan använda telnet för att ansluta till socket policy server. En exempelsession visas nedan:
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 den här exempelsessionen används telnet för att ansluta till localhost på port 843. Telnet svarar med de tre första raderna och sitter sedan och väntar på att användaren ska ange något. Användaren har angett policybegäran <policy-file-request / >, som socket policy-servern tar emot och svarar med socket-principen. Servern kopplar sedan från vilket telnet rapporterar att anslutningen har stängts.
Lyssningsuttag
du kan inte skapa lyssningsuttag i webplayer, det kan inte fungera som en server. Därför kan webbspelare inte kommunicera med varandra direkt (peer 2 peer). När du använder TCP-uttag kan du bara ansluta till fjärrslutpunkter förutsatt att det är tillåtet via socket policy-systemet. För UDP fungerar det på samma sätt men konceptet är lite annorlunda eftersom det är ett anslutningslöst protokoll, du behöver inte ansluta/lyssna för att skicka/ta emot paket. Det fungerar genom att genomdriva att du bara kan ta emot paket från en server om han först har svarat med en giltig policy med taggen allow-access-from domain.
det här är bara så irriterande, varför finns alla dessa saker?
säkerhetsfunktionerna socket och WWW finns för att skydda personer som installerar Unity Web Player. Utan dessa begränsningar skulle en attack som följande vara möjlig:
- Bob arbetar i Vita huset.
- Frank är ond. Han skriver ett unity webgame som låtsas vara ett spel, men i bakgrunden gör en WWW-begäran till http://internal.whitehouse.gov/LocationOfNuclearBombs.pdf. intern.whitehouse.gov är en server som inte kan nås från internet, men kan nås från Bobs arbetsstation eftersom han arbetar i Vita huset.
- Frank skickar dessa pdf-byte tillhttp://frank.com/secretDataUploader.php
- Frank placerar detta spel påhttp://www.frank.com/coolgame.unity3d
- Frank övertygar på något sätt Bob att spela spelet.
- Bob spelar spelet.
- Game hämtar tyst det hemliga dokumentet och skickar det till Frank.
med säkerhetsfunktionerna WWW och socket kommer denna attack att misslyckas, för innan du laddar ner pdf-filen kontrollerar unity http://internal.whitehouse.gov/crossdomain.xml , med avsikt att fråga den servern: ”är de data du har på din server tillgängliga för allmän användning?”. Placera en crossdomain.xml på en webbserver kan ses som svaret på den frågan. I fallet med detta exempel är systemoperatören av internal.whitehouse.gov kommer inte att placera en crossdomain.xml på sin server, vilket leder till att Unity inte laddar ner pdf-filen.
tyvärr, för att skydda de personer som installerar Unity Web Player, måste människor som utvecklas i Unity ta hänsyn till dessa säkerhetsåtgärder när de utvecklar innehåll. Samma begränsningar finns i alla större plugin-tekniker. (Flash, Silverlight, Shockwave)
undantag
för att hitta rätt balans mellan att skydda användare av webbspelare och göra livet för innehållsutvecklare enkelt har vi implementerat ett undantag från säkerhetsmekanismen som beskrivs ovan:
du får ladda ner bilder från servrar som inte har en tvärdomän.xml-fil. Det enda du får göra med dessa bilder är dock att använda dem som texturer i din scen. Du får inte använda GetPixel() på dem. Du får inte heller läsa tillbaka från skärmen. Båda försöken kommer att resultera i en SecurityException kastas:
SecurityException: No read access to the texture data: at (wrapper managed-to-native) UnityEngine.Texture2D:GetPixel (int,int)resonemanget är här är att det är okej att ladda ner bilden, så länge innehållsutvecklaren inte får tillgång till den. Så du kan visa den för användaren, men du kan inte skicka byte av bilden tillbaka till någon annan server. Om du behöver åtkomst till pixeldata placerar du en crossdomain.xml – fil på servern där bilderna hämtas från.