웹플레이어의 보안 샌드박스

유니티 3.0 에서 웹플레이어는 어도비 플래시 플레이어가 사용하는 것과 매우 유사한 보안 모델을 구현한다. 이 보안 제한은 웹 플레이어 및 활성 빌드 대상이 웹 플레이어인 경우 편집기에만 적용됩니다. 보안 모델에는 여러 부분이 있습니다:

• 호스팅 한 이외의 도메인에 데이터를 액세스에 대한 제한 당신의.파일.
• 소켓의 사용에 대한 몇 가지 제한.
• 출입 금지로 간주되는 방법의 호출 허용 안 함. (파일 같은 것들.삭제 등).
• 시스템 사용을 허용하지 않습니다.반사.*당신이 자신을 작성하지 않은 클래스의 개인/내부 메소드를 호출합니다.

현재 보안 모델의 처음 두 부분만 편집기에서 에뮬레이트됩니다.

유니티(UnityEngine.Network,UnityEngine.NetworkView클래스 등)의 내장 된 무티 플레이어 네트워킹 기능은 영향을받지 않습니다.

이 문서는 유니티 웹 플레이어의 버전 3.0 에서 콘텐츠를 계속 사용할 수 있도록 하는 방법을 설명합니다.이 예제에서는 다음과 같이 설명합니다.

소켓 클래스에 대한 자세한 내용은 참조를 참조하십시오.

클래스와 소켓은 동일한 정책 스키마를 사용하지만 그 외에도 완전히 별개의 시스템입니다. 웹 서비스에 대한 사용 권한만 정의하지만 소켓 정책은 모든 소켓 연결에 적용됩니다.

유니티 에디터에는 웹 플레이어의 보안 모델을 부과하는”웹 보안 에뮬레이트”기능이 함께 제공됩니다.이 쉽게 편집기의 안락에서 문제를 감지 할 수 있습니다. 이 설정은 편집->프로젝트 설정->편집기에서 찾을 수 있습니다. 편집기 설정을 참조하십시오.하지만,이 파일은 호스팅하는 도메인과 동일한 도메인인 경우에는 필요하지 않습니다.

예를 들어,다음 웹 사이트에서 호스팅되는 테트리스 게임을 상상해보십시오.:

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

***********:

http://highscoreprovider.net/gethighscore.php

이 경우crossdomain.xml파일을 파일의 루트에 배치해야 합니다.highscoreprovider.net 이 같은 도메인: http://highscoreprovider.net/crossdomain.xml

crossdomain.xml파일의 내용은 플래시 플레이어가 사용하는 형식입니다. 이미 있는crossdomain.xml파일을 찾을 가능성이 매우 높습니다. 파일의 정책은 다음과 같습니다:

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

이 파일이http://highscoreprovider.net/crossdomain.xml에 배치되면 해당 도메인의 소유자는 모든 도메인에서 오는 웹 플레이어가 웹 서버의 내용에 액세스 할 수 있다고 선언합니다.도메인>및<사이트 제어 허용-도메인 간 정책>태그에서<허용 헤더를 지원하지 않습니다. crossdomain.xml은 아스키 파일이어야 합니다.

디버깅

환경 변수ENABLE_CROSSDOMAIN_LOGGING를1로 설정하면 유니티 런타임이crossdomain.xml파일을 가져오고 디코딩할 때 콘솔 메시지가 생성됩니다. 맥에서 당신은/etc/launchd.conf에서 글로벌 환경 변수를 설정할 수 있습니다. 시스템 및 보안->시스템->고급 시스템 설정->환경 변수…

:

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

편집기에서 실행할 때 이러한 메시지는 편집기에 기록됩니다.로그. BOM와utf16으로 잘못 저장된crossdomain.xml파일을 읽으려고 하면 구문 분석 실패가 발생합니다:

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

이는BOM가 예상되지 않기 때문입니다. BOM가 없는 지원되지 않는utf16파일을 사용하면:

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

파일의 첫 번째 바이트가 0 이므로 파서가 파일의 끝에 도달했다고 생각하기 때문입니다. Crossdomain.xml은 아스키 파일이어야 합니다.

소켓 사용에 대한 시사점:

유니티 웹 플레이어는 특정 호스트에 연결하기 위해 소켓 서비스 정책이 필요합니다. 이 정책은 기본적으로 포트 843 의 대상 호스트에 의해 호스팅되지만 다른 포트에서도 호스팅될 수 있습니다. 기본 포트가 아닌 기능상의 차이점은 보안으로 수동으로 페치해야 한다는 점입니다.1024 보다 높은 포트에서 호스팅되는 경우 정책은 1024 보다 높은 다른 포트에 대한 액세스 만 제공 할 수 있습니다.

기본 포트를 사용할 때 다음과 같이 작동합니다.connection.It 포트 843 에서 소켓을 열고 요청을 발행하고 새 연결을 통해 소켓 정책을 받을 것으로 예상합니다. 그런 다음 유니티 웹 플레이어는 호스트의 정책이 연결을 진행하도록 허용하는지 확인하고 오류 없이 진행됩니다. 이 프로세스는 사용자 코드에 투명하게 수행되므로 이 보안 모델을 사용하기 위해 수정할 필요가 없습니다. 소켓 정책의 예는 다음과 같습니다:

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

이 정책은 효과적으로”모든 도메인의 콘텐츠는 포트 1200-1220 에서 소켓 연결을 자유롭게 할 수 있습니다”라고 말합니다. 유니티 웹 플레이어는 이것을 존중하고 그 범위 밖의 포트를 사용하여 시도한 소켓 연결을 거부합니다(보안 예외가 발생합니다).

정책을 자동으로 가져올 수도 있습니다. 이 응용 프로그램은 당신이 당신의 데이터를 전송하거나 수신하는 데 필요한 모든 정보를 제공합니다.

소켓 정책에 사용되는 형식은 일부 태그가 지원되지 않는 경우를 제외하고 플래시 플레이어에서 사용되는 형식과 동일합니다. 유니티 웹 플레이어는 도메인 설정에 대한 유효한 값으로”*”만 지원하며”포트”설정은 필수입니다.

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

소켓 정책은 하나의 정책 서버에 의해 제어될 수 있습니다.

사용자의 편의를 위해 포트 843 에서 간단히 수신하는 작은 프로그램을 제공합니다.서버 코드는 윈도우 또는/유니티에 데이터/도구/소켓 정치 서버에서 유니티 설치 폴더 내에서 찾을 수 있습니다.사전 빌드된 실행 파일은 모노 실행 파일이기 때문에 맥에서 실행할 수 있습니다. 그냥”모노 소켓 폴”을 입력하십시오.그것을 실행하려면. 이 예제 코드는 소켓 정책 서버의 올바른 동작을 보여줍니다. 특히 서버는<정책 파일 요청/>이 포함된 0 으로 종료된 문자열을 받을 것으로 예상합니다. 이 문자열(및 정확히이 문자열)이 수신 된 경우에만 클라이언트에 소켓 정책 문서를 보냅니다. 또한 단일 소켓 쓰기와 함께 보내야 합니다. 헤더와 본문을 별도의 소켓 쓰기 작업으로 분리하면 불완전한 정책을 받는 유니티로 인해 보안 예외가 발생할 수 있습니다. 당신이 당신의 자신의 서버에 문제가 발생하면 우리가 제공하는 예제를 사용하여 고려하시기 바랍니다. 이렇게 하면 서버 또는 네트워크 문제가 있는지 여부를 진단하는 데 도움이 됩니다.

멀티플레이어 게임 네트워킹에 일반적으로 사용되는 타사 네트워킹 라이브러리는 피어 2 피어 기능(아래 참조)에 의존하지 않고 전용 서버를 사용하는 한 이러한 요구 사항과 함께 작동할 수 있어야 합니다. 이들은 때때로 호스팅 정책에 대한 지원으로 상자 밖으로 나옵니다.

주: 그러나 이러한 문서가 제공되는 방식은 매우 다릅니다. 여기서 소켓 정책은<정책 파일 요청/>을 구현하는 사소한 서버를 사용하여 포트 843 에서 페치됩니다. 소켓 정책 파일을 발급하거나 포트 843 의 소켓 연결에 대한 응답으로 소켓 정책 파일을 보내는 서버를 설정할 수 없습니다. 또한 연결하는 각 서버에는 자체 소켓 정책 서버가 필요합니다.

디버깅

telnet을 사용하여 소켓 정책 서버에 연결할 수 있습니다. 예제 세션이 아래에 나와 있습니다:

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$

이 예제 세션에서 텔넷은 포트 843 의 로컬 호스트에 연결하는 데 사용됩니다. 텔넷은 처음 세 줄로 응답 한 다음 사용자가 무언가를 입력 할 때까지 기다립니다. 사용자가 소켓 정책 서버가 소켓 정책으로 수신하고 응답하는 정책 요청 문자열<정책-파일-요청/>을 입력했습니다. 그런 다음 서버가 연결을 끊어 텔넷이 연결이 닫혔다고 보고합니다.

청취 소켓

웹 플레이어에서 청취 소켓을 만들 수 없으며 서버 역할을 할 수 없습니다. 따라서 웹 플레이어는 서로 직접 통신 할 수 없습니다(피어 2 피어). 소켓 정책 시스템을 통해 허용되는 경우에만 원격 끝점에 연결할 수 있습니다. 이 패키지에는 디버깅 심볼이 들어 있습니다. 이는allow-access-from domain태그가 있는 유효한 정책으로 먼저 응답한 경우에만 서버에서 패킷을 받을 수 있도록 하는 방식으로 작동합니다.

이 모든 것이 너무 짜증나는데 왜이 모든 것들이 존재합니까?

유니티 웹 플레이어를 설치하는 사람들을 보호하기 위해 소켓 및 보안 기능이 존재합니다. 이러한 제한이 없으면 다음과 같은 공격이 가능합니다:

• 밥은 백악관에서 일한다.
• 프랭크는 악합니다. “…….”…….”……….”………..”………..”………..”. 내부.화이트 하우스.정부는 인터넷에서 연결할 수없는 서버입니다,하지만 그는 백악관에서 작동하기 때문에 밥의 워크 스테이션에서 연결할 수 있습니다.2100>
• 프랭크는 어떻게 든 밥에게 게임을하도록 설득합니다.
• 밥이 게임을 한다.
• 게임은 비밀 문서를 자동으로 다운로드하여 프랭크에게 보냅니다.이 공격은 해당 서버에 요청하려는 의도로http://internal.whitehouse.gov/crossdomain.xml을 검사하기 때문에 실패합니다: “서버에 있는 데이터를 공공 용도로 사용할 수 있습니까?”. 크로스 도메인 배치.이 질문에 대한 응답으로 볼 수 있습니다. 이 예제의 경우,의 시스템 연산자 internal.whitehouse.gov 교차 도메인을 배치하지 않습니다.2015 년 11 월 15 일에 확인함.

  안타깝게도 유니티 웹 플레이어를 설치하는 사람들을 보호하기 위해 유니티에서 개발하는 사람들은 콘텐츠를 개발할 때 이러한 보안 조치를 고려해야합니다. 모든 주요 플러그인 기술에는 동일한 제한이 있습니다. (플래시,실버 라이트,쇼크 웨이브)

  예외

  웹 플레이어 사용자를 보호하고 콘텐츠 개발자의 삶을 쉽게 만드는 것 사이의 적절한 균형을 찾기 위해 위에서 설명한 보안 메커니즘에 대한 예외를 구현했습니다.

  교차 도메인이 없는 서버에서 이미지를 다운로드 할 수 있습니다.파일. 그러나 이러한 이미지를 사용할 수 있는 유일한 방법은 이러한 이미지를 장면의 텍스처로 사용하는 것입니다. 당신은 그들에 게 픽셀()를 사용할 수 없습니다. 또한 화면에서 다시 읽을 수 없습니다. 두 시도 모두 보안 예외가 발생합니다:

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

  여기에 있는 이유는 콘텐츠 개발자가 액세스할 수 없는 한 이미지를 다운로드해도 괜찮다는 것입니다. 따라서 사용자에게 표시 할 수는 있지만 이미지의 바이트를 다른 서버로 다시 보낼 수는 없습니다. 픽셀 데이터에 대한 액세스가 필요한 경우 이미지를 가져온 서버에crossdomain.xml파일을 배치합니다.