Security Sandbox of the Webplayer

w Unity 3.0, webplayer implementuje model zabezpieczeń bardzo podobny do tego używanego przez Adobe Flash player™. Te ograniczenia bezpieczeństwa dotyczą tylko webplayera i edytora, gdy aktywnym celem kompilacji jest WebPlayer. Model bezpieczeństwa ma kilka części:

• ograniczenia dostępu do danych w domenie innej niż domena hostująca Twoje dane .plik unity3d.
• pewne ograniczenie użycia gniazd.
• zakaz wywoływania dowolnej metody, którą uznaliśmy za wyłączoną. (things like File.Usunąć, itp).
• Zakaz korzystania z systemu.Odbicie.* aby wywoływać metody prywatne / wewnętrzne w klasach, nie napisałeś samodzielnie.

obecnie tylko dwie pierwsze części modelu bezpieczeństwa są emulowane w edytorze.

nie ma to wpływu na wbudowane funkcje sieciowe muti-player Unity (UnityEngine.Network, UnityEngine.NetworkView klas itp.).

ten dokument opisuje, jak upewnić się, że zawartość nadal działa z wersją 3.0 Unity webplayer.

• Zobacz referencję API Unity, aby uzyskać informacje o klasie WWW.
• Zobacz referencję API.NET, aby uzyskać informacje o klasie gniazda. NET.

Klasa WWW i sockety używają tego samego schematu zasad, ale poza tym są całkowicie oddzielnymi systemami. Zasady WWW definiują uprawnienia tylko w usłudze internetowej, w której zasady są hostowane, ale zasady gniazd odnoszą się do wszystkich połączeń gniazd TCP/UDP.

edytor Unity jest wyposażony w funkcję „Emuluj bezpieczeństwo sieci”, która narzuca model bezpieczeństwa webplayera.Ułatwia to Wykrywanie problemów z wygody edytora. Możesz znaleźć to ustawienie wedit – >ustawienia projektu-> edytor. Zobacz także ustawienia edytora.

Webplayer Unity oczekuje, że plik zasad obsługiwany przez HTTP o nazwie crossdomain.xml będzie dostępny w domenie, do której chcesz uzyskać dostęp za pomocą klasy WWW(chociaż nie jest to potrzebne, jeśli jest to ta sama domena, która hostuje plik unity3d).

na przykład wyobraź sobie grę tetris, hostowaną pod następującym adresem url:

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

musi uzyskać dostęp do listy najlepszych wyników z następującego adresu url:

http://highscoreprovider.net/gethighscore.php

w takim przypadku należy umieścić plik crossdomain.xml w katalogu głównym highscoreprovider.net domena jak ta: http://highscoreprovider.net/crossdomain.xml

zawartość pliku crossdomain.xml jest w formacie używanym przez Flash player. Jest bardzo prawdopodobne, że znajdziesz plik crossdomain.xml już na swoim miejscu. Polityka w pliku wygląda następująco:

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

gdy plik ten znajduje się pod adresem http://highscoreprovider.net/crossdomain.xml, właściciel tej domeny oświadcza, że zawartość serwera może być dostępna dla dowolnego webplayera pochodzącego z dowolnej domeny.

Unity webplayer nie obsługuje<allow-http-request-headers-from domain > and<site-control allowed-cross-domain-policies > tags. Zauważ, że crossdomain.xml powinien być plikiem ASCII.

debugowanie

ustawienie zmiennej środowiskowej ENABLE_CROSSDOMAIN_LOGGING na 1 spowoduje generowanie wiadomości konsoli podczas pobierania i dekodowania pliku crossdomain.xml przez środowisko wykonawcze Unity. Na komputerze Mac możesz ustawić globalne zmienne środowiskowe w /etc/launchd.conf. Na komputerze użyj panelu sterowania – > System i bezpieczeństwo – > System – >Zaawansowane ustawienia systemowe – >zmienne środowiskowe…

oto Przykładowe wyjście z ustawioną tą zmienną środowiskową, gdy webplayer próbuje pobrać obraz ze zdalnego serwera:

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

podczas pracy w edytorze wiadomości te są zapisywane do edytora.dziennik. Próba odczytania pliku crossdomain.xml nieprawidłowo zapisanego jako utf16 z plikiem BOM spowoduje niepowodzenie analizy pliku xml:

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

dzieje się tak dlatego, że BOM nie jest oczekiwany. Użycie nieobsługiwanego pliku utf16 bez BOM spowoduje:

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

dzieje się tak, ponieważ pierwszy bajt w pliku to zero, co powoduje, że parser myśli, że dotarł do końca pliku. Crossdomain.xml musi być plikiem ASCII.

implikacje dotyczące korzystania z gniazd:

Webplayer Unity potrzebuje zasady obsługi gniazd, aby połączyć się z określonym hostem. Ta zasada jest domyślnie hostowana przez host docelowy na porcie 843, ale może być również hostowana na innych portach. Różnica funkcjonalna w przypadku portu innego niż domyślny polega na tym, że musi być ręcznie pobierany z zabezpieczeniami.Wywołanie interfejsu API PrefetchSocketPolicy() i jeśli jest on hostowany na porcie wyższym niż 1024, zasada może dać dostęp tylko innym portom wyższym niż 1024.

przy użyciu domyślnego portu działa to w następujący sposób: Unity webplayer próbuje nawiązać połączenie z gniazdem TCP z hostem, najpierw sprawdza, czy serwer hosta zaakceptuje connection.It robi to otwierając Gniazdo TCP na porcie 843, wysyła żądanie i oczekuje otrzymania Zasady gniazda przez nowe połączenie. Unity webplayer następnie sprawdza, czy polityka hosta pozwala na połączenie iść dalej i będzie postępować bez błędu, jeśli tak. Proces ten odbywa się w sposób przejrzysty z kodem użytkownika, który nie musi być modyfikowany, aby korzystać z tego modelu bezpieczeństwa. Przykład polityki gniazda wygląda następująco:

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

ta polityka skutecznie mówi „zawartość z każdej domeny może swobodnie nawiązywać połączenia z gniazdami na portach 1200-1220”. Unity webplayer będzie to respektować i odrzuci próby połączenia z gniazdem przy użyciu portu poza tym zakresem (zostanie wyrzucony wyjątek SecurityException).

podczas korzystania z połączeń UDP zasady mogą być również automatycznie pobierane, gdy muszą być wymuszone w podobny sposób jak w przypadku TCP. Răłĺźnica polega na tym, Ĺźe automatyczne pobieranie z TCP odbywa siÄ ™ po poĹ 'Ä … czeniu siÄ ™ z czymĹ” (zapewnia, Ĺźe moĹźesz poĹ 'Ä … czyÄ ‡ siÄ ™ z serwerem), ale z UDP, poniewaĹź jest bez poĹ’ Ä … czenia, ma to miejsce rĂłwnieĹź po wywoĹ 'aniu dowolnego punktu API, ktĂłry wysyĹ’ a lub odbiera dane (Zapewnia, Ĺźe moĹźesz wysyĹ ’ aÄ ‡ /odbieraÄ ‡ ruch do/z serwera).

format używany dla zasad gniazd jest taki sam jak format używany przez Flash player, Z Wyjątkiem niektórych znaczników nie są obsługiwane. Unity webplayer obsługuje tylko ” * „jako prawidłową wartość dla ustawienia domeny, a ustawienie” to-ports ” jest obowiązkowe.

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

zasada gniazd dotyczy zarówno typów połączeń TCP, jak i UDP, więc zarówno ruch UDP, jak i TCP może być kontrolowany przez jeden serwer zasad.

dla Twojej wygody udostępniamy mały program, który po prostu nasłuchuje na porcie 843; gdy po połączeniu otrzyma ciąg żądania, odpowie z poprawną Polityką gniazd.Kod serwera można znaleźć w folderze instalacyjnym Unity, w Data / Tools / SocketPolicyServer w systemie Windows lub /Unity.app/Contents/Tools/SocketPolicyServer na OS X. należy pamiętać, że wstępnie zbudowany plik wykonywalny można uruchomić na komputerze Mac, ponieważ jest to plik wykonywalny Mono. Wystarczy wpisać ” mono sockpol.exe ” to run it. Zauważ, że ten przykładowy kod pokazuje poprawne zachowanie serwera zasad gniazda. W szczególności serwer oczekuje otrzymania zakończonego zerem ciągu zawierającego <policy-file-request/>. Wysyła do klienta dokument XML socket policy tylko wtedy, gdy ten łańcuch (a dokładnie ten łańcuch) został odebrany. Ponadto jest wymagane, aby nagłówek xml i treść XML były wysyłane z pojedynczym zapisem gniazda. Rozbicie nagłówka i ciała na oddzielne operacje zapisu gniazda może spowodować wyjątki bezpieczeństwa z powodu otrzymania przez Unity niekompletnej Zasady. Jeśli wystąpią jakiekolwiek problemy z własnym serwerem, rozważ skorzystanie z przykładu, który udostępniamy. To powinno pomóc zdiagnozować, czy masz problemy z serwerem lub siecią.

Biblioteki sieciowe innych firm, powszechnie używane do sieci gier wieloosobowych, powinny być w stanie pracować z tymi wymaganiami, o ile nie zależą one od funkcji peer 2 peer (patrz poniżej), ale wykorzystują serwery dedykowane. Te czasami nawet pochodzą z pudełka z obsługą zasad hostingu.

Uwaga: Podczas gdy pliki crossdomain.xml i socket policy są dokumentami xml i są zasadniczo podobne, sposób obsługi tych dokumentów jest bardzo różny. Crossdomain.xml(który stosuje się do żądań http) jest pobierany przy użyciu http na porcie 80, gdzie-jako zasada gniazda jest pobierana z portu 843 przy użyciu trywialnego serwera, który implementuje <policy-file-request/>. Nie można użyć serwera http do wydania pliku zasad gniazda, ani skonfigurować serwera, który po prostu wysyła plik zasad gniazda w odpowiedzi na połączenie gniazda na porcie 843. Należy również pamiętać, że każdy serwer, z którym się łączysz, wymaga własnego serwera zasad gniazda.

debugowanie

możesz użyć telnet, aby połączyć się z serwerem zasad gniazda. Przykładowa sesja jest pokazana poniżej:

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$

w tej przykładowej sesji telnet jest używany do łączenia się z localhostem na porcie 843. Telnet odpowiada pierwszymi trzema liniami, a następnie czeka, aż użytkownik coś wprowadzi. Użytkownik wprowadził łańcuch żądań zasad < policy-file-request/>, który serwer zasad gniazd odbiera i odpowiada za pomocą zasad gniazd. Następnie serwer rozłącza się, powodując, że telnet zgłasza zamknięcie połączenia.

gniazda nasłuchujące

nie możesz tworzyć gniazd nasłuchujących w webplayerze, nie może on działać jako serwer. Dlatego webplayerzy nie mogą komunikować się ze sobą bezpośrednio (peer 2 peer). Podczas korzystania z gniazd TCP można łączyć się tylko ze zdalnymi punktami końcowymi pod warunkiem, że jest to dozwolone przez system zasad gniazd. W przypadku UDP działa to tak samo, ale koncepcja jest nieco inna, ponieważ jest to protokół bezpołączeniowy, nie musisz łączyć/słuchać, aby wysyłać/odbierać pakiety. Działa poprzez wymuszenie, że można odbierać pakiety z serwera tylko wtedy, gdy on odpowiedział pierwszy z prawidłową Polityką z tagiem allow-access-from domain.

to wszystko jest takie denerwujące, dlaczego to wszystko istnieje?

gniazda i zabezpieczenia WWW istnieją, aby chronić ludzi, którzy instalują Unity Web Player. Bez tych ograniczeń, atak taki jak poniżej byłby możliwy:

• Bob pracuje w Białym Domu.
• Frank jest zły. Pisze unity webgame, który udaje grę, ale w tle robi żądanie WWW do http://internal.whitehouse.gov/LocationOfNuclearBombs.pdf. wewnętrzne.whitehouse.gov to serwer, który nie jest dostępny z internetu, ale jest dostępny ze stacji roboczej Boba, ponieważ pracuje w Białym Domu.
• Frank wysyła te bajty pdf do http://frank.com/secretDataUploader.php
• Frank umieszcza tę grę nahttp://www.frank.com/coolgame.unity3d
• Frank w jakiś sposób przekonuje Boba do gry.
• Bob gra w grę.
• gra po cichu pobiera tajny dokument i wysyła go do Franka.

przy zabezpieczeniach WWW i gniazd ten atak się nie powiedzie, bo przed pobraniem pliku PDF Unity sprawdza http://internal.whitehouse.gov/crossdomain.xml z zamiarem zapytania tego serwera: „czy dane, które posiadasz na swoim serwerze są dostępne do użytku publicznego?”. Umieszczenie crossdomeny.xml na serwerze internetowym może być postrzegany jako odpowiedź na to pytanie. W przypadku tego przykładu operator systemu internal.whitehouse.gov nie umieszczę crossdomeny.xml na swoim serwerze, co spowoduje, że Unity nie pobierze pliku pdf.

niestety, aby chronić ludzi, którzy instalują Unity Web Player, ludzie, którzy rozwijają się w Unity, muszą wziąć te środki bezpieczeństwa pod uwagę podczas tworzenia treści. Te same ograniczenia są obecne we wszystkich głównych technologiach wtyczek. (Flash, Silverlight, Shockwave)

wyjątki

aby znaleźć właściwą równowagę między ochroną użytkowników odtwarzaczy sieciowych a ułatwianiem życia twórcom treści, wdrożyliśmy wyjątek od opisanego powyżej mechanizmu bezpieczeństwa:

możesz pobierać obrazy z serwerów, które nie mają crossdomeny.plik xml. Jednak jedyne, co możesz zrobić z tymi obrazami, to używać ich jako tekstur w scenie. Nie wolno na nich używać GetPixel (). Nie możesz również czytać z ekranu. Obie próby spowodują wyrzucenie SecurityException:

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

rozumowanie polega na tym, że pobieranie obrazu jest w porządku, o ile twórca treści nie ma do niego dostępu. Możesz więc wyświetlić go użytkownikowi, ale nie możesz wysłać bajtów obrazu z powrotem do innego serwera. Jeśli potrzebujesz dostępu do danych pikseli, umieść plik crossdomain.xml na serwerze, z którego pobierane są obrazy.