웹플레이어의 보안 샌드박스(Security Sandbox of the Webplayer)

Desktop!

유니티 3.0에서 웹 플레이어는 Adobe Flash player�에서 사용한 것과 매우 흡사한 보안 모델을 구현합니다. 이 보안 제한은 오직 웹 플레이어와 엑티브 구축 타깃이 웹 플레이어인 경우의 편집기에만 적용됩니다. 해당 보안모델은 몇 가지 부분으로 이루어집니다:

*사용자의 unity3d 파일을 호스트 하는 것을 제외한 도메인에 접근하는 데이터에 대한 제한. *소켓(Socket) 사용에 대한 일부 제한사항. *출입 금지로 간주하는 메소드(파일 삭제 등)의 호출의 불허함. *사용자가 직접 쓰기를 실행하지 않은 클래스 내의 사적/내부적 메소드의 호출에 대한 System.Reflection의 사용을 불허함.

현재는 처음 2개의 보안 모델만 편집기(Editor)에 적용하였습니다. 다음에서 a detailed list of which methods / classes are available in the webplayer 를 확인하십시오.

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

이 문서는 어떻게 하면 사용자의 콘텐츠가 유니티 웹플레이어의 3.0 버전과 계속 작동할 수 있게 하는지를 설명합니다.

비록 WWW 클래스와 소켓이 같은 정책 스키마(policy schema)를 사용하지만 그 둘은 완전히 별개의 시스템입니다. WWW 정책은 해당 정책이 주관하는 웹 서비스에서만 승인사항을 설정하지만, 소켓 정책은 모든 TCP/UDP 소켓 연결에 다 적용됩니다.

유니티 편집기는 "Emulate Web Security"라는 기능과 함께 제공되는데 이는 웹 플레이어의 보안 모델을 시행합니다. 이것을 사용하면 익숙한 편집기에서 쉽게 문제점을 감지해 낼 수 있습니다. 사용자가 해당 설정을 찾으려면 _Edit→Project Settings→Editor_을 통하면 됩니다.

WWW 클래스 사용의 의미

유니티의 웹 플레이어는 "_crossdomain.xml_"라는 http에 제공하는 정책파일이 사용자가 WWW 클래스를 통하여 접근하고자 하는 도메인에 존재하리라 전제합니다 (unity3d 파일을 호스트 하는 동일한 도메인 내에 있다면 필요치 않습니다).

예를 들면, 테트리스 게임을 생각하면, 다음 url에서 호스트 한다면:

http://gamecompany.com/games/tetris.unity3d// 다음 url에서 고득점 리스트를 사용해야 한다면: http://highscoreprovider.net/gethighscore.php//

이 경우, 사용자는_crossdomain.xml_파일을 다음http://highscoreprovider.net/crossdomain.xml//과 같은 highscoreprovider.net도메인의 루트에 둘 필요가 있을 것 입니다. 해당 _crossdomain.xml_의 내용은 Flash 플레이어에 사용한 포맷으로 되어 있습니다. 아마 사용자는 그 자리에 이미 _crossdomain.xml_파일이 존재하는 것을 볼 가능성이 아주 높습니다: <file csharp> <?xml version="1.0"?> <cross-domain-policy> <allow-access-from domain="*"/> </cross-domain-policy> </file> 그 파일이 http://highscoreprovider.net/crossdomain.xml에 놓이면, 해당 도메인의 소유자는 웹서버의 그 콘텐츠가 모든 도메인에서 접근하는 어떤 플레이어에 의해서도 사용이 가능함을 선언합니다. 유니티 웹 플레이어는 <allow-http-request-headers-from domain> and <site-control permitted-cross-domain-policies> 태그는 지원하지 않습니다. _crossdomain.xml_ 파일은 ASCII 파일이어야 함을 주의하십시오. ======소켓 사용의 의미:====== 유니티 웹 플레이어는 특정 호스트에 연결하려면 소켓 사용 정책을 필요로 합니다. 그 정책은 디폴트로는 타깃 호스트의 _843_번 포트에서 호스팅 되지만 다른 포트에서 호스팅 할 수 도 있습니다. 디폴트가 아닌 포트를 사용하는 경우 기능적으로 달라지는 것은 Security.PrefetchSocketPolicy() API call을 통하여 수동으로 불러와야 하며, 만일 1024번 보다 높은 번호의 포트에서 호스팅 된다면 해당 정책은 1024번보다 높은 포트에서만 접근을 허가할 수 있게 됩니다. 디폴트 포트를 사용하면 다음과 같이 동작합니다: 유니티 웹 플레이어가 호스트와 TCP 소켓 접속을 시도합니다. 우선 호스트 서버가 요청하는 접속을 수락할 지를 확인합니다. 이 작업은 843번 포트에 TCP 소켓을 하나 열고 해당 새 접속을 통해 소켓 정책을 수신하기를 기다립니다. 다음 유니티의 웹 플레이어는 호스트 서버의 정책이 해당 접속을 허가하는지를 확인하고 만일 그렇다면 에러 없이 진행합니다. 이 과정은 사용자의 코드에는 보이지 않게 발생하므로 해당 보안 모델을 사용하기 위해 사용자 코드를 변경할 필요가 없습니다. 소켓 정책의 한 예를 들면 다음과 같습니다: <file csharp> <?xml version="1.0"?> <cross-domain-policy> <allow-access-from domain="*" to-ports="1200-1220"/> </cross-domain-policy>" </file> 이 정책인 실질적으로 말하는 것은 “어떤 도메인에서 오는 콘텐츠이든 포트 1200-1220 사이에서는 자유롭게 소켓 접속을 생성 할 수 있습니다”라는 것 입니다. 유니티 웹 플레이어는 이를 준수하고, 이 포트 범위 밖에서 소켓 접속을 시도하면 거절할 것 입니다(SecurityException을 보냅니다). UDP 접속을 사용할 시의 해당 정책 역시, TCP와 비슷한 방식으로 시행될 필요가 있을 경우 자동 소환 될 수 있습니다. 차이점은 TCP에서 자동 소환은 사용자가 무언가에 Connect를 실행할 때 발생합니다(사용자가 해당 서버에 접속 허락을 보장하는). 하지만 UDP는 비 연결식이므로(connectionless) 이것 역시 사용자가 API call을 실행하여 데어나르 주거나 받을 때 발생합니다(사용자가 해당 서버와 데이터를 수신/발신이 허용되는지를 확인합니다). 소켓 정책에 사용된 포맷은 일부 태그가 지원되지 않는다는 것을 제외하면 Flash player에 사용된 것과 동일합니다. 유니티 웹 플레이어는 "*" 만을 도메인 설정에 유효한 값으로 지원하고, "to-ports" 설정은 필수사항입니다. <file csharp> <?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> </file> 해당 소켓 정책은 TCP와 UDP 연결 타입 둘 다에 적용되므로 TCP와 UDP 트래픽 모두 하나의 정책 서버에서 제어할 수 있습니다. 사용자 편의를 위하여, 포트 번호 843번을 그냥 모니터링만 하는 작은 프로그램 하나를 저희가 제공합니다; 여기서 연결요청을 수신하면 해당 프로그램은 유효한 소켓 정책을 보낼 것 입니다. 서버코드는 유니티 설치 폴더의 Tools/SocketPolicyServer에 있습니다. Mac에서는 이미 구축된 실행 파일이 작동할 수 있으면 그 이유는 그것이 Mono 실행파일이기 때문입니다. 이를 실행하려면 "mono sockpol.exe"라고 그냥 입력하면 됩니다. 외부업체의 네트워크 주로 멀티플레이어 게임 네트워킹에 사용되는 라이브러리(libraries)의 경우에 피어 투 피어 기능에 의존하지 않고 전용서버를 이용하는 한은 이러한 요구사항에 부합하여 작동할 수 있어야 합니다. =====감시 소켓(Listening sockets)===== Y사용자는 웹 플레이어에서는 서버 역할을 할 수가 _없_으므로 감시소켓(listening sockets)을 생성 할 수 없습니다. 그러므로 웹 플레이는 서로 직접 통신(peer 2 peer) 할 수는 없습니다. TCP 소켓을 사용하면 사용자는 소켓 정책시스템이 허용하는 한 원격 종점(endpoints)만 연결 할 수 있습니다. UDP에서도 동일하게 작동하지만 비 연결(connectionless) 방식 프로토콜이므로 개념이 약간 달라 사용자가 패킷을 수신/발신하기 위해 연결/감시(listen) 등을 수행할 필요가 없습니다. 이러한 정책은 서버가 초기에 allow-access-from domain가 달린 유효한 정책으로 답신을 보냈을 때만 사용자는 해당 서버로부터 패킷을 받을 수 있게 강제함으로써 작동합니다. =====이러한 성가신 정책이 왜 필요할까요?===== 이와 같은 소켓과 WWW 정책은 유니티 웹 플레이어를 설치하는 사용자를 보호하기 위해 존재하는 보안 기능입니다. 이러한 제한을 가하지 않으면, 다음과 같은 공격이 가능해지게 됩니다: *밥(Bob)은 백악관 직원입니다. *프랭크(Frank)는 사악합니다. 그는 게임인 척 하는 유니티 게임을 제작하지만, 백그라운드에서는http://internal.whitehouse.gov/LocationOfNuclearBombs.pdf. i에 WWW 작업을 실행합니다. internal.whitehouse.gov는 인터넷에서는 접속 할 수가 없는 서버이지만 밥은 백악관 직원이므로 그의 워크스테이션 컴퓨터에서는 접근 가능합니다. *프랭크가 http://frank.com/secretDataUploader.php로 pdf 데이터들을 전송합니다. *플랭크는 해당 게임을 http://www.frank.com/coolgame.unity3d에 둡니다 *프랭크가 어떻게 하여 밥이 같이 게임 할 것을 설득합니다. *밥이 게임을 합니다. *해당 게임이 조용히 기밀문서를 다운받아 프랭크에게 보냅니다. 이 경우 WWW와 소켓 보안이 지원되면 이러한 공격은 실패하게 됩니다. 왜냐하면 pdf 을 다운받기 전에 유니티가http://internal.whitehouse.gov/crossdomain.xml에게 “당신의 서버에 있는 이 데이터가 일반에게 공개되어도 되는 것인가요?” 하고 질문을 던집니다. 웹 서버에 crossdomain.xml을 둔다는 것은 그 질문에 대한 대답으로 볼 수 있습니다. 이 사례의 경우, of internal.whitehouse.gov의 시스템 오퍼레이터는 이러한 파일을 두지 않을 것이고, 그러므로 유니티는 해당 pdf을 다운받지 않을 것 입니다. 비록 불편하지만 유니티 웹 플레이어를 설치하는 사용자를 보호하기 위하여 유니티 개발자들은 콘텐츠 개발 시 이러한 보안 대책을 세울 필요가 있습니다. 동일한 제한이 모든 주요 플러그인 기술에도 있습니다(Flash, Silverlight, Shockwave). =====예외(Exceptions)===== 웹 플레이어 사용자를 보호하는 것과 콘텐츠 개발자의 편의성 사이에 균형을 잘 맞추기 위해서, 저희는 위에서 설명한 보안 메커니즘에 예외를 두었습니다. - 사용자는 crossdomain.xml 파일이 없는 서버로부터 이미지 다운로드를 할 수 있습니다. 하지만 해당 이미지를 사용하여 사용자가 할 수 있는 것은 사용자의 장면(scene)에 이것을 텍스처로 사용하는 것뿐입니다. 사용자는 그것에 GetPixel()을 사용할 수 없으며 스크린으로부터 되 읽어 올 수도 없습니다. 이 두 가지 모두 SecurityException이 발생할 될 것입니다. 이러한 논리는 이미지를 다운받는 것은 괜찮으나 콘텐츠 개발자가 그것에 대한 접근은 불가하다는 것 입니다. 그러므로 사용자는 그것을 디스플레이 할 수는 있지만 해당 이미지의 데이터를 다른 서버로 전송할 수는 없습니다. * 출처: 유니티코리아위키 (CC BY-NC-SA 2.0)

역링크