flash.system.Security (Flex™ 2 레퍼런스 가이드)

	property	정의
		constructor : Object 특정의 object 인스턴스의 클래스 object 또는 constructor　　 함수에의 참조입니다.	Object
		exactSettings : Boolean [static] 특정의 Flash Player 설정에 사용하는 도메인을 Flash Player 가 어떻게 선택하는지를 지정합니다. 설정에는, 카메라와 마이크의 허가, 기억 area의 할당, 영속 공유 object의 기억 area등이 있습니다.	Security
		prototype : Object [static] 클래스 또는 함수 object의 prototype object에의 참조입니다.	Object
		sandboxType : String [static][read-only] 호출원의 SWF 파일이 동작하고 있는 시큐러티 샌드 박스의 타입을 나타냅니다.	Security

	Methods	정의
		allowDomain (... domains):void [static] 지정된 도메인의 SWF 파일 및 HTML 파일이,`allowDomain()` 호출을 포함한 SWF 파일의 object 및 변수에 액세스 하는 것을 허가합니다.	Security
		allowInsecureDomain (... domains):void [static] 지정한 도메인내의 SWF 파일 및 HTML 파일이, HTTPS 프로토콜로 호스트 된 호출원 SWF 파일의 object와 변수에 액세스 하는 것을 허가합니다.	Security
		hasOwnProperty (name:String ):Boolean object로 지정된 property가 정의되고 있는지 어떤지를 나타냅니다.	Object
		isPrototypeOf (theClass:Object ):Boolean Object 클래스의 인스턴스가, Parameters로서 지정된 object의 prototype 체인내에 있을지 어떨지를 나타냅니다.	Object
		loadPolicyFile (url:String ):void [static] `url` Parameters로 지정된 장소로부터 도메인간 policy 파일을 로드합니다.	Security
		propertyIsEnumerable (name:String ):Boolean 지정된 property가 존재해, 열거 가능한가 어떤가를 나타냅니다.	Object
		setPropertyIsEnumerable (name:String , isEnum:Boolean = true):void 루프 처리에 대한 다이나믹 property의 가용성을 설정합니다.	Object
		showSettings (panel:String = "default"):void [static] Flash Player 의 [시큐러티 설정] 패널을 표시합니다.	Security
		toString ():String 지정된 object의 string 표현을 돌려줍니다.	Object
		valueOf ():Object 지정된 object의 원시적치를 돌려줍니다.	Object

	정수	정의
		LOCAL_TRUSTED : String = "localTrusted" [static] SWF 파일은 로컬 파일이며, 설정 매니저 또는 "FlashPlayerTrust" 구성 파일을 사용해 신뢰성이 있습니다.	Security
		LOCAL_WITH_FILE : String = "localWithFile" [static] SWF 파일은 로컬 파일이며, 신뢰성은 없고, 네트워크를 지정해 Publish 되고 있는 것은 아닙니다.	Security
		LOCAL_WITH_NETWORK : String = "localWithNetwork" [static] SWF 파일은 로컬 파일이며, 신뢰성은 없습니다만, 네트워크를 지정해 Publish 되고 있습니다.	Security
		REMOTE : String = "remote" [static] SWF 파일은 인터넷 URL 로부터의 것이며, 도메인 베이스의 샌드 박스 규칙에 따라 기능합니다.	Security

property의 상세

exactSettings

property

exactSettings:Boolean [read-write]

특정의 Flash Player 설정에 사용하는 도메인을 Flash Player 가 어떻게 선택하는지를 지정합니다. 설정에는, 카메라와 마이크의 허가, 기억 area의 할당, 영속 공유 object의 기억 area등이 있습니다. Flash Player 6 으로 사용되고 있던 설정과 같은 설정을 SWF 파일로 사용하기 위해서,exactSettings 를 false 로 설정할 수 있습니다.

Flash Player 6 에서는, 이러한 플레이어 설정에 사용되고 있던 도메인은, SWF 파일의 도메인의 마지막 부분에 근거하고 있었습니다. www.example.com 와 같이 SWF 파일의 도메인에 3 개 이상의 세그먼트(segment)가 포함되어 있는 경우, 도메인의 최초의 세그먼트(segment) ("www")는 삭제되어 도메인의 나머지의 부분이 사용됩니다. 즉, example.com 입니다. 따라서, Flash Player 6 에서는, www.example.com 와 store.example.com 는 어느쪽이나 example.com 를 이러한 설정의 도메인으로서 사용합니다. 같이 www.example.co.uk 와 store.example.co.uk 는 어느쪽이나 example.co.uk 를 이러한 설정의 도메인으로서 사용합니다. Flash Player 7 이후에서는, 플레이어 설정은 디폴트로 SWF 파일의 정확한 도메인에 따라 선택됩니다. 예를 들어, www.example.com 의 SWF 파일은 www.example.com 의 플레이어 설정을 사용해, store.example.com 의 SWF 파일은 그것과는 다른 store.example.com 의 플레이어 설정을 사용합니다.

Security.exactSettings 가 true 로 설정되었을 경우, Flash Player 는 플레이어 설정에 대해서 정확한 도메인을 사용합니다. false 로 설정되었을 경우, Flash Player 는 Flash Player 6 으로 사용되고 있던 도메인 설정을 사용합니다. exactSettings 의 디폴트치는 false 입니다. exactSettings 를 디폴트치로부터 변경하는 경우는, Flash Player 로 플레이어 설정을 선택할 필요가 있는 이벤트가 발생하기 전에 그 변경을 실시할 필요가 있습니다. 예를 들어, 카메라 또는 마이크의 사용이나 영속 공유 object의 취득등의 이벤트의 전입니다.

버젼 6 의 SWF 파일을 Publish 해, 그 파일로부터 영속 공유 object를 작성할 때, 버젼 7 이후에 그 SWF 파일을 이식한 다음에 SWF 파일로부터 그 영속 공유 object를 취득하는지, 또는 버젼 7 이후의 다른 SWF 파일로부터 그 영속 공유 object를 취득할 필요가 있는 경우는,SharedObject.getLocal() 을 호출하기 전에 Security.exactSettings 를 false 로 설정할 필요가 있습니다.

Implements
public static function get exactSettings():Boolean
public function set exactSettings(value:Boolean ):void

Throws

SecurityError — Flash Player 는, 플레이어 설정에 관한 결정으로 exactSettings 의 값을 적어도 한 번 사용했습니다.

See also

Flash Player 시큐러티

sandboxType

property

sandboxType:String [read-only]

호출원의 SWF 파일이 동작하고 있는 시큐러티 샌드 박스의 타입을 나타냅니다.

Security.sandboxType 는, 다음의 몇개의 값이 됩니다.

remote (Security.REMOTE): 이 SWF 파일은 인터넷 URL 로부터의 것이며, 도메인 베이스의 샌드 박스 규칙에 따라 기능합니다.
localWithFile (Security.LOCAL_WITH_FILE): 이 SWF 파일은 로컬 파일이며, 신뢰성은 없고, 네트워크를 지정해 Publish 되고 있는 것은 아닙니다. 로컬의 데이터 소스로부터 읽어낼 수가 있습니다만, 인터넷에서의 교환은 할 수 없습니다.
localWithNetwork (Security.LOCAL_WITH_NETWORK): 이 SWF 파일은 로컬 파일이며, 신뢰성은 없습니다만, 네트워크를 지정해 Publish 되고 있습니다. 이 SWF 파일은 인터넷과의 교환은 할 수 있습니다만, 로컬 데이터 소스로부터의 독해는 할 수 없습니다.
localTrusted (Security.LOCAL_TRUSTED): 이 SWF 파일은 로컬 파일이며, 설정 매니저 또는 "FlashPlayerTrust" 구성 파일을 사용해 신뢰성이 있습니다. 로컬의 데이터 소스로부터 읽어내는 일도, 인터넷으로 교환할 수도 있습니다.

Flash Player 8 이후에 지원(support)되고 있는 임의의 버젼의 SWF 파일은, 이 property를 사용할 수 있습니다. 즉, 예를 들어 Flash Player 8 으로 재생하고 있는 버젼 7 의 SWF 파일로부터, 이 property를 확인할 수가 있습니다. 이 지원(support)에서는, 8 보다 낡은 버젼에 대해 Publish 하는 경우, 이 property가 재생시에 지원(support)될지 어떨지가 Publish시에는 모릅니다. 따라서, 버젼 7 이전의 SWF 파일에서는, 이 property는 미정도리의 값입니다. 이것은, Flash Player 의 버젼 (flash.system.Capabilities.version 로 지정)이 8 보다 낡을 때에만 생기는 상황입니다. 이 경우, SWF 파일의 URL 가 로컬 파일일지 어떨지에 의해 샌드 박스의 타입을 판별할 수 있습니다. 로컬 파일의 경우, SWF 파일은 localTrusted 로서 분류됩니다. Flash Player 8 보다 전은, 모든 로컬 컨텐츠가 이 방법으로 처리되고 있었습니다. 로컬 파일이 아닌 경우, SWF 파일은 remote 로서 분류됩니다.

상세한 것에 대하여는, 다음의 주제를 참조해 주세요.

「ActionScript 3.0 의 프로그래밍」의시큐러티의 장과 LiveDocs 의 최신 코멘트

Flash Player 9 시큐러티에 관한 화이트 페이퍼

Implements
public static function get sandboxType():String

Methods의 상세

allowDomain

()

Methods

public static function allowDomain(... domains):void

지정된 도메인의 SWF 파일 및 HTML 파일이,allowDomain() 호출을 포함한 SWF 파일의 object 및 변수에 액세스 하는 것을 허가합니다.

2 개의 SWF 파일이 같은 도메인에 소속해 있는 경우 (예를 들어, http://mysite.com/swfA.swf 및 http://mysite.com/swfB.swf), swfA.swf 로 swfB.swf 내의 변수, object, property, Methods등을 조사, 변경할 수 있어 swfB.swf 에서도 swfA.swf 에 대해서 같은 일을 실행할 수 있습니다. 이것은,크로스 무비 스크립트또는크로스 스크립트로 불립니다.

2 개의 SWF 파일이 다른 도메인에 소속해 있는 경우 (예를 들어, http://siteA.com/swfA.swf 및 http://siteB.com/siteB.swf), 디폴트에서는, swfA.swf 로 swfB.swf 를 스크립트 하는 일도, swfB.swf 로 swfA.swf 를 스크립트 하는 일도 허가되지 않습니다. Security.allowDomain() 를 호출하는 것으로, SWF 파일에 의해 다른 도메인의 SWF 파일이 부여됩니다. 이것을크로스 도메인 스크립트라고 부릅니다. Security.allowDomain("siteA.com") 를 호출하는 것으로, siteB.swf 에 의해 siteA.swf 에 siteB.swf 를 스크립트 하는 허가가 부여됩니다.

크로스 도메인의 경우는, 관여하는 2 개의 도메인을 명확하게 하는 것이 중요합니다. 설명을 위해, 여기에서는, 크로스 스크립트를 실행하는 측을액세스원 (통상, 액세스 하는 SWF)이라고 불러, 외를액세스처 (통상, 액세스 되는 SWF)라고 부릅니다. siteA.swf 가 siteB.swf 를 스크립트 하는 경우, siteA.swf 가 액세스원으로, siteB.swf 가 액세스처가 됩니다.

allowDomain() 를 사용해 확립되는 크로스 도메인 허가는, 비대칭입니다. 전의 예에서는, siteA.swf 는 siteB.swf 를 스크립트 할 수 있습니다만, siteB.swf 는 siteA.swf 를 스크립트 할 수 없습니다. siteA.swf 로, siteA.swf 를 스크립트 하는 허가를 siteB.com 의 SWF 파일에 부여하기 위한 allowDomain() 를 호출하지 않기 때문입니다. 대칭적인 허가를 설정하려면 , 양쪽 모두의 SWF 파일로 allowDomain() 를 호출하도록(듯이) 할 필요가 있습니다.

Flash Player 에서는, SWF 파일을 다른 SWF 파일에 의한 크로스 도메인 스크립트로부터 보호할 뿐만 아니라, HTML 파일에 의한 크로스 도메인 스크립트로부터도 보호합니다. HTML 로부터 SWF 에의 스크립트는,SetVariable 등이 낡은 Flash 브라우저의 함수를 사용하는지,ExternalInterface.addCallback() 로 확립한 콜백을 사용하는 것으로 실행할 수 있습니다. HTML 로부터 SWF 에의 스크립트가 도메인을 횡단하는 경우, 액세스처 SWF 파일은, 액세스원이 SWF 파일의 경우와 같게,allowDomain() 를 호출할 필요가 있습니다. 그 이외의 경우, 조작은 실패합니다.

allowDomain() 에 Parameters로서 IP 주소를 지정해도, 지정된 IP 주소에 존재하는 모든 액세스원으로부터의 액세스가 허가되는 것은 아닙니다. 허가되는 것은, 그 IP 주소에 매핑 되는 도메인명은 아니고, 지정된 IP 주소가 URL 에 포함되는 액세스원으로부터의 액세스 뿐입니다.

버젼 고유의 차이점
Flash Player 의 크로스 도메인 시큐러티 규칙은, 버젼을 쫓을 때 마다 발전해 왔습니다. 다음의 겉(표)는, 차이점을 집계한 것입니다.

크로스 스크립트에 관계하는 최신의 SWF 의 버젼	allowDomain()의 필요성	allowInsecureDomain()의 필요성	allowDomain() 또는 allowInsecureDomain()를 호출할 필요가 있는 SWF	allowDomain() 또는 allowInsecureDomain()로 지정할 수 있는 항목
5 이전	불가	불가	N/A
6	네 (super 도메인이 일치하지 않는 경우)	불가	액세스처 SWF 파일, 또는 액세스처 SWF 파일과 같은 super 도메인에 있는 임의의 SWF 파일	텍스트 베이스의 도메인 (mysite.com) IP 주소 (192.168. 1.1)
7	네 (도메인이 완전하게 일치하지 않는 경우)	네 (HTTP 로부터 HTTPS 에의 액세스를 실행하는 경우 (도메인이 완전하게 일치하는 경우에서도))	액세스처 SWF 파일, 또는 액세스처 SWF 파일과 완전히 같은 도메인에 있는 임의의 SWF 파일	텍스트 베이스의 도메인 (mysite.com) IP 주소 (192.168. 1.1)
8 이후	네 (도메인이 완전하게 일치하지 않는 경우)	네 (HTTP 로부터 HTTPS 에의 액세스를 실행하는 경우 (도메인이 완전하게 일치하는 경우에서도))	액세스처 SWF	텍스트 베이스의 도메인 (mysite.com) IP 주소 (192.168. 1.1) 와일드 카드 (*)

Flash Player 의 동작을 제어하는 버젼은, Flash Player 자신의 버젼이 아니고,SWF 버젼 (SWF 파일의 Publish바젼)입니다. 예를 들어, Flash Player 8 으로 버젼 7 용으로 Publish 된 SWF 파일을 재생하는 경우, 버젼 7 으로 일관한 동작이 적용됩니다. 이것에 의해, 업그레이드 해도, deploy된 SWF 파일내의 Security.allowDomain() 의 동작은 변경되지 않게 됩니다.

전의 겉(표)의 버젼열은, 크로스 스크립트 조작에 관계하는 최신의 SWF 의 버젼을 나타내고 있습니다. Flash Player 의 동작은, 액세스원 SWF 파일 또는 액세스처 SWF 파일의 버젼의 언젠가 새로운 (분)편의 버젼에 의해 정해집니다.

다음의 단락에서는,Security.allowDomain() 에 관계하는 Flash Player 의 시큐러티 기능의 변경에 대해 상세하게 설명합니다.

버젼 5 :크로스 도메인 스크립트의 제한은 없습니다.

버젼 6 :크로스 도메인 스크립트의 시큐러티가 도입되었습니다. 디폴트에서는, 크로스 도메인 스크립트는 금지되고 있습니다. Security.allowDomain() 로 허가할 수 있습니다. 2 개의 파일이 같은 도메인에 속하고 있는지 어떤지를 판별하기 위해(때문에), 각 파일의 super 도메인이 사용됩니다. 이 super 도메인은, 파일의 URL 의 완전한 호스트명으로부터 최초의 세그먼트(segment)를 제외해, 최저 2 세그먼트(segment)에까지 한 것입니다. 예를 들어, www.mysite.com 의 super 도메인은, mysite.com 가 됩니다. www.mysite.com 의 SWF 파일과 store.mysite.com 의 SWF 파일은,Security.allowDomain() 를 호출하지 않고 , 서로를 스크립트 합니다.

버젼 7 :super 도메인 일치가, 완전한 도메인 일치로 변경되었습니다. 2 개의 파일로 서로 스크립트의 실행이 허가되는 것은, 그러한 URL 의 호스트명이 같은 경우 뿐입니다. 그 이외의 경우는,Security.allowDomain() 를 호출할 필요가 있습니다. 디폴트에서는, HTTPS 이외의 URL 로부터 로드한 파일은, 완전히 같은 도메인으로부터 파일을 로드했다고 해도, HTTPS 의 URL 로부터 로드한 파일을 스크립트 할 수 없습니다. 이 제한은 HTTPS 파일의 보호에 도움이 됩니다. HTTPS 이외의 파일은, 다운로드중으로 변경되기 쉽고, HTTPS 이외의 파일이 악의를 가져 변경되면, 이러한 부정 조작을 받기 어려운 HTTPS 파일을 손상할 가능성이 있습니다. 액세스처의 HTTPS SWF 파일이 자발적으로 이 제한을 무효로 할 수 있도록(듯이),Security.allowInsecureDomain() 를 도입했습니다만,Security.allowInsecureDomain() 를 사용하지 않는 것을 추천합니다.

버젼 8 :2 개의 주요한 변경점은 다음과 같습니다.

Security.allowDomain() 를 호출했을 경우, 액세스처 SWF 파일이 Security.allowDomain() 를 호출한 SWF 파일일 때에만, 크로스 스크립트 조작이 허가되게 되었습니다. 즉,Security.allowDomain() 를 호출한 SWF 파일만이, 자신에게로의 액세스를 허가할 수 있게 되었습니다. 전의 버젼에서는,Security.allowDomain() 를 호출했을 경우에, 액세스처 SWF 파일이 Security.allowDomain() 를 호출한 SWF 파일과 같은 도메인에 있는 SWF 파일이면, 크로스 스크립트 조작이 허가되고 있었습니다. 전의 버젼에서는,Security.allowDomain() 를 호출하면, 호출원 SWF 파일의 도메인 전체가 열렸습니다.
Security.allowDomain("*") 및 Security.allowInsecureDomain("*") 에서는, 와일드 카드치의 지원(support)가 추가되었습니다. 와일드 카드 (*) 값를 사용하면, 액세스원파일이 어디에서 로드 되었는지를 불문하고, 임의의 파일로 크로스 스크립트 조작을 허가할 수 있습니다. 와일드 카드는, 글로벌 허가라고 생각해 주세요. 와일드 카드 허가는, 로컬 파일 시큐러티 규칙아래에서 특정의 조작을 유효하게 하는 경우에 필요합니다. 구체적으로는, 로컬 SWF 파일로, 그 SWF 파일에 인터넷상의 SWF 파일을 스크립트 하는 네트워크 액세스 허가가 있는 경우, 액세스처의 인터넷 SWF 파일은, 로컬 SWF 파일의 출처(소)가 불명한 것을 반영해,Security.allowDomain("*") 를 호출할 필요가 있습니다. 인터넷 SWF 파일이 HTTPS URL 로부터 로드 되는 경우는, 인터넷 SWF 파일에서는, 대신에 Security.allowInsecureDomain("*") 를 호출할 필요가 있습니다.

경우에 따라서는, 다른 도메인으로부터 child SWF 파일을 로드해, 그 child SWF 파일로 친 SWF 파일을 스크립트 하고 싶지만, child SWF 파일의 최종적인 도메인을 모른다고 하는 상황이 되는 일이 있습니다. 이러한 상황은, 예를 들어 load balancing 리디렉트나 써드파티제 서버를 사용하는 경우에 발생합니다.

이 상황에서는,Loader.load() 에 건네주는 URLRequest object의 url property를 사용할 수 있습니다. 예를 들어, child SWF 파일을 친 SWF 에 로드하는 경우, 친 SWF 의 Loader object의 contentLoaderInfo property에 다음과 같이 액세스 할 수 있습니다.
Security.allowDomain(loader.contentLoaderInfo.url)

url property의 올바른 값을 취득하기 위해서, child SWF 파일의 로드가 개시될 때까지 기다리도록 해 주세요. child SWF 의 로드가 언제 개시되었는지를 확인하려면 ,progress 이벤트를 사용합니다.

이 반대의 상황이 발생하는 경우도 있습니다. 즉, 친 SWF 파일로 child SWF 파일을 스크립트 하고 싶지만, 친 SWF 파일의 도메인을 모르는 경우입니다. 이 상황에서는, SWF 의 루트 object인 표시 object의 loaderInfo property에 액세스 할 수 있습니다. child SWF 로,Security.allowDomain( this.root.loaderInfo.loaderURL) 를 호출합니다. 친 SWF 파일이 로드 될 때까지 기다릴 필요는 없습니다. 친 SWF 파일은 child SWF 파일이 로드 된 시점에서 이미 로드 되고 있습니다.

Flash Player 8 이후용으로 Publish 하는 경우,Security.allowDomain("*") 를 호출하는 것에 의해 이러한 상황을 처리할 수도 있습니다. 다만, 이것은 위험한 지름길이 될 수 있습니다. 임의의 도메인의 임의의 다른 SWF 파일로부터 호출해 원 SWF 파일에 액세스 할 수 있게 되기 (위해)때문에입니다. 통상,_url property를 사용하는 것이 안전합니다.

상세한 것에 대하여는, 다음의 주제를 참조해 주세요.

「ActionScript 3.0 의 프로그래밍」의시큐러티의 장과 LiveDocs 의 최신 코멘트

Flash Player 9 시큐러티에 관한 화이트 페이퍼

Parameters

... domains — 액세스원으로서 허가하는 도메인을 지정하는 string 또는 URLRequest object. 특별한 도메인 "*" 을 지정해, 모든 도메인으로부터의 액세스를 허가할 수 있습니다.

"*" (을)를 지정하는 것은, Flash authoring tool로 [로컬에서의 재생에 관한 시큐러티] 옵션의 [네트워크에게만 액세스 하는] 을 사용해 Publish 된 로컬 SWF 파일로부터, 로컬 이외의 SWF 파일에의 액세스를 허가하는 유일한 방법입니다.

allowInsecureDomain

()

Methods

public static function allowInsecureDomain(... domains):void

지정한 도메인내의 SWF 파일 및 HTML 파일이, HTTPS 프로토콜로 호스트 된 호출원 SWF 파일의 object와 변수에 액세스 하는 것을 허가합니다. 이 Methods는 추천할 수 없습니다. 후의 「시큐러티에 대한 고려사항」을 참조해 주세요.

이 Methods는,Security.allowDomain() 와 같게 기능합니다. 다만, 액세스원이 HTTPS 이외의 프로토콜로 로드 되어 액세스처가 HTTPS 로 로드 되는 조작도 허가합니다. Flash Player 7 이후에서는, HTTPS 이외의 파일로, HTTPS 파일을 스크립트 하는 것은 허가되지 않습니다. 액세스처 HTTPS SWF 파일로 allowInsecureDomain() Methods를 사용하면, 이 제한이 해제됩니다.

HTTPS 이외의 파일로부터 HTTPS 파일에의 스크립트를 유효하게 하는 경우에게만,allowInsecureDomain() 를 사용해 주세요. 액세스원의 HTTPS 이외의 파일과 액세스처의 HTTPS 파일이, 같은 도메인에 소속해 있을 때의 스크립트 (예를 들어, http://mysite.com 에 있는 SWF 파일로 https://mysite.com 에 있는 SWF 파일을 스크립트 하는 경우)를 유효하게 하기 위해서 사용합니다. HTTPS 이외의 파일간에서의 스크립트, HTTPS 파일간에서의 스크립트, 또는 HTTPS 파일로부터 HTTPS 이외의 파일에의 스크립트를 유효하게 하기 위해서는 사용하지 말아 주세요. 이러한 상황에서는, 대신에 allowDomain() 를 사용합니다.

시큐러티에 대한 고려사항 :Flash Player 에서는 유연성을 최대화하기 위해서 allowInsecureDomain() 가 준비되어 있습니다만, 이 Methods를 호출하지 않는 것을 추천합니다. HTTPS 를 개입시켜 파일을 제공하면, 개발자나 유저에 대해서 복수의 보호 기능을 제공할 수 있습니다만,allowInsecureDomain 의 호출에 의해, 이러한 보호 기능은 취약하게 됩니다. 다음의 시나리오에서는,allowInsecureDomain() 를 충분한 고려없이 사용했을 경우에 시큐러티가 위험에 처해지는 상황을 설명합니다.

다음의 정보는, 생각되는 시나리오 가운데 1 개로, 크로스 스크립트의 실제예를 통해서 allowInsecureDomain() 를 이해할 수 있도록(듯이) 설계되고 있습니다. 시큐러티 아키텍쳐에 관한 문제를 모두 채택하고 있는 것은 아니고, 배경 정보로서의 보고 사용할 필요가 있습니다. Flash Player 디벨로퍼 센터에는, Flash Player 및 시큐러티에 관한 광범위한 정보가 있습니다. 상세한 것에 대하여는,http://www.adobe.com/devnet/security/ 를 참조해 주세요.

다음의 2 개의 컴퍼넌트로부터 구성되는 e-코머스 사이트를 구축하는 시나리오에 대해 생각해 보겠습니다. 1 개은 카탈로그로, 공개 정보 밖에 포함되지 않기 때문에, 보호할 필요는 없습니다. 이제(벌써) 1 개은, 쇼핑카드/체크아웃 컴퍼넌트로, 유저의 재무 정보와 개인정보를 보호하기 위해서 시큐러티로 보호할 필요가 있습니다. 여기서, 카탈로그의 서비스는 http://mysite.com/catalog.swf 로부터, 카트의 서비스는 https://mysite.com/cart.swf 로부터 제공하는 것으로 합니다. 이 사이트의 1 개의 요건으로서 제삼자가 시큐러티 아키텍쳐의 취약성을 이용해, 유저의 크레디트 카드 번호를 훔치지 못하는 것을 들 수 있습니다.

여기서, 중간 당사자인 공격자가 서버와 유저의 사이에 개입해, 유저가 쇼핑카드 어플리케이션에 입력한 크레디트 카드 번호를 훔치려고 한다고 합니다. 중간 당사자로서는, 일부의 유저가 이용하고 있는 악질적인 ISP, 유저의 직장에 있는 악의가 있는 관리자 등, Public 인터넷 경유로 송신되는 네트워크 패킷을 유저와 서버간에 표시 또는 변경할 수 있는 사람이 생각됩니다. 이 상황은 드문 일이 아닙니다.

cart.swf 로 HTTPS 를 사용해 크레디트 카드 정보를 서버에 송신하고 있는 경우, 중간 당사자의 공격자는, HTTPS 송신이 암호화되고 있기 (위해)때문에, 네트워크 패킷으로부터 직접 이 정보를 훔칠 수가 없습니다. 다만, 공격자는 다른 수법을 사용할 수 있습니다. 그것은, 몇개의 SWF 파일의 내용을 유저에게로의 전달시로 변경해, 그 SWF 파일을 개변 버젼 (유저 정보를 공격자가 소유하는 다른 서버에 송신한다)과 옮겨놓는 수법입니다.

HTTPS 프로토콜은, 무엇보다도 우선 이 "변경" 공격을 방지합니다. 암호화되고 있을 뿐만 아니라, HTTPS 송신에 부정 조작 방지 기능이 붙어 있기 (위해)때문에입니다. 중간 당사자의 공격자가 패킷을 변경하면, 수신측은 그 변경을 검출해, 패킷을 폐기합니다. 이 때문에, 이 상황으로 공격자는 cart.swf 를 변경할 수 없습니다. 이 파일이 HTTPS 경유로 전달되기 때문입니다.

그런데, HTTP 경유로 제공되는 catalog.swf 내의 버튼으로, HTTP 경유로 제공되는 cart.swf 내의 쇼핑카드에 아이템을 추가할 수 있도록(듯이) 하고 싶다고 합니다. 이 기능을 실현하기 위해서(때문에), cart.swf 로 allowInsecureDomain() 를 호출합니다. 이것으로, catalog.swf 는 cart.swf 를 스크립트 할 수 있습니다. 다만, 이 액션에서는, 예기치 않은 결과가 발생합니다. 이 경우, 공격자는, catalog.swf 를 유저가 최초로 다운로드할 때, 그 내용을 변경할 수 있습니다. catalog.swf 는 HTTP 로 전달되어 부정 조작 방지 기능이 붙지 않기 때문입니다. 공격자가 변경한 catalog.swf 는, 이것으로 cart.swf 를 스크립트 할 수 있게 됩니다. cart.swf 에 allowInsecureDomain() 에의 호출이 포함되어 있기 (위해)때문에입니다. 변경된 catalog.swf 파일은, ActionScript 를 사용해, cart.swf 내의 변수에 액세스 할 수 있기 (위해)때문에, 유저의 크레디트 카드 정보나 그 외의 기밀 데이터를 읽어낼 수가 있습니다. 그 후, 변경된 catalog.swf 는, 이 데이터를 공격자의 서버에 송신할 수 있습니다.

이 Implements은 분명하게 바람직한 것으로는 없습니다만, 사이트상의 2 개의 SWF 파일간에 크로스 스크립트를 허가하고 싶은 경우가 있습니다. 다음에, 이 가상의 e-코머스 사이트를 재설계해 allowInsecureDomain() 를 제외하는 방법으로서 생각되는 방법을 2 개 가리킵니다.

어플리케이션내의 모든 SWF 파일을 HTTPS 경유로 제공합니다. 이것은 가장 단순해 신뢰성이 높은 솔루션입니다. 설명한 시나리오에서는, catalog.swf 와 cart.swf 의 양쪽 모두를 HTTPS 경유로 제공합니다. catalog.swf 등의 파일을 HTTP 로부터 HTTPS 로 전환할 때, 대역폭의 사용량과 서버의 CPU 부하가 조금 올라, 유저측에서는, 어플리케이션의 로드 시간이 약간 길어질 가능성이 있습니다. 실제의 서버로 실험해, 이러한 영향의 중대도를 판별할 필요가 있습니다. 통상은, 각각 10 ~ 20% 정도로, 전혀 영향이 없는 것도 있습니다. 서버에 있는 HTTPS 가속 하드웨어나 소프트웨어를 사용하면, 통상은 결과를 개선할 수 있습니다. 관계하는 모든 SWF 파일을 HTTPS 경유로 제공하는 주요한 메리트는, 브라우저로부터 내용이 혼재한 경고를 생성하지 않고 , HTTPS URL 를 유저의 브라우저내의 주요한 URL 로서 사용할 수 있는 것입니다. 또, 브라우저의 열쇠의 아이콘이 표시되기 (위해)때문에, 시큐러티에 관한 공통의 신뢰할 수 있는 인디케이터(indicator)가 유저에게 제공됩니다.
HTTP 로부터 HTTPS 에의 스크립트가 아니고, HTTPS 로부터 HTTP 에의 스크립트를 사용합니다. 설명한 시나리오에서는, 유저의 쇼핑카드의 내용을 catalog.swf 에 보존해, cart.swf 로 체크아웃 프로세스만 관리시킬 수가 있습니다. 체크아웃시에, cart.swf 로, catalog.swf 내의 ActionScript 변수로부터 카트의 내용을 취득할 수 있습니다. HTTP 로부터 HTTPS 에의 스크립트에 관한 제한은 비대칭적인 것입니다. HTTP 경유로 제공되는 catalog.swf 파일이 HTTPS 경유로 제공되는 cart.swf 파일을 스크립트 하는 것은 안전상 허가됩니다만, HTTPS 경유로 제공되는 cart.swf 파일은 HTTP 경유로 제공되는 catalog.swf 파일을 스크립트 할 수 있습니다. 이 어프로치는, 모두 HTTPS 경유의 어프로치보다 미묘한 점이 있습니다. 부정 조작을 받기 쉽기 때문에, HTTP 경유로 제공되는 SWF 파일은 신뢰하지 않게 주의할 필요가 있습니다. 예를 들어, cart.swf 로 카트의 내용을 기술한 ActionScript 변수를 취득할 때, cart.swf 내의 ActionScript 코드로, 이 변수의 값이 기대한 형식이 되어 있으면 신뢰할 수 없습니다. 카트의 내용을 확인해, cart.swf 에 바람직하지 않은 액션을 실행시키는 무효인 데이터가 포함되지 않은 것을 조사할 필요가 있습니다. 또, 중간 당사자가 catalog.swf 를 변경해, 예를 들어, 유저 카트에 아이템을 넣는 것으로, 유효하지만 부정확한 데이터를 cart.swf 에 제공하는 위험성을 감수 할 필요가 있습니다. 통상의 체크아웃 프로세스에서는, 카트의 내용과 합계 금액을 표시해 유저에게 마지막 승인을 요구하는 것으로, 이 위험성을 조금 완화하고 있습니다만, 그런데도 위험성은 남아 있습니다.

Web 브라우저에서는, 오랜 세월에 걸쳐 HTTPS 파일과 HTTPS 이외의 파일의 분리를 강제해 왔습니다. 설명한 시나리오에서는, 이 제한이 필요한 것의 1 개의 이유가 명확하게 나타나고 있습니다. Flash Player 에서는, 절대 필요한 경우, 이 시큐러티의 제한을 회피할 수 있습니다만, 그것을 실행하기 전에 결과를 신중하게 검토할 필요가 있습니다.

상세한 것에 대하여는, 다음의 주제를 참조해 주세요.

「ActionScript 3.0 의 프로그래밍」의시큐러티의 장과 LiveDocs 의 최신 코멘트

Flash Player 9 시큐러티에 관한 화이트 페이퍼

Parameters

"*" (을)를 지정하는 것은, Flash authoring tool로 [로컬에서의 재생에 관한 시큐러티] 설정 ([File]-[Publish 설정]-[Flash] 탭)의 [네트워크에게만 액세스 하는] 옵션을 사용해 Publish 된 로컬 SWF 파일로부터, 로컬 이외의 SWF 파일에의 액세스를 허가하는 유일한 방법입니다.

loadPolicyFile

()

Methods

public static function loadPolicyFile(url:String ):void

url Parameters로 지정된 장소로부터 도메인간 policy 파일을 로드합니다. Flash Player 에서는, Flash 무비가 놓여져 있는 서버 이외의 서버로부터 데이터를 로드하는 것을 허가할지 어떨지를 설정하기 위해서, policy 파일이 사용됩니다.

디폴트에서는, Flash Player 로 policy 파일의 검색을 하는 것은 데이터 로드 요구를 하고 있는 서버의 /crossdomain.xml 에 한정됩니다. XMLSocket 접속 시행의 경우, 디폴트에서는, XMLSocket 접속의 시행을 하고 있는 서브 도메인의 HTTP 서버의 포토 80 으로, /crossdomain.xml 에 검색을 합니다.

Security.loadPolicyFile() 에 의해, Flash Player 에서는 임의의 장소로부터 policy 파일을 로드할 수 있게 됩니다. 다음에 예를 나타냅니다.

  Security.loadPolicyFile("http://www.example.com/sub/dir/pf.xml");

이것에 의해, Flash Player 는 지정된 URL 로부터 policy 파일을 취득할 수 있게 됩니다. 이 장소에 놓여져 있는 policy 파일에 의해 얻을 수 있는 허가는, 서버의 가상 디렉토리 계층에서 동레벨 이하의 컨텐츠 모두에게 적용됩니다. 예를 들어, 전의 코드에 계속되는 이러한 행에 의해 예외는 슬로우 되지 않습니다.

 import flash.net. *;
  var request:URLRequest = new URLRequest("http://www.example.com/sub/dir/vars.txt");
  var loader:URLLoader = new URLLoader();
  loader.load(request);
  
  var loader2:URLLoader = new URLLoader();
  var request2:URLRequest = new URLRequest("http://www.example.com/sub/dir/deep/vars2.txt");
  loader2.load(request2);

다만, 다음의 코드에서는 시큐러티 예외가 슬로우 됩니다.

 import flash.net. *;
  var request3:URLRequest = new URLRequest("http://www.example.com/elsewhere/vars3.txt");
  var loader3:URLLoader = new URLLoader();
  loader3.load(request3);

loadPolicyFile() 를 사용해, 임의의 수의 policy 파일을 로드할 수 있습니다. policy 파일을 필요로 하는 요구가 있는 경우, Flash Player 는 policy 파일의 다운로드가 모두 완료할 때까지 반드시 대기합니다. 그 사이에 요구가 거부될 것은 없습니다. loadPolicyFile() 로 지정된 policy 파일에 의해 요구가 허가되지 않았던 경우는, 최종적으로 디폴트의 장소인 /crossdomain.xml 가 참조됩니다.

특정의 포토 번호로 xmlsocket 프로토콜을 사용하는 것으로, 직접 XMLSocket 서버로부터 policy 파일을 취득할 수가 있습니다. 다음에 예를 나타냅니다.

  Security.loadPolicyFile("xmlsocket://foo.com:414");

이 코드를 사용하면, Flash Player 는 지정된 호스트와 포토로부터 policy 파일을 취득하려고 합니다. 1024 이상의 포토 뿐만이 아니라, 임의의 포토를 사용할 수 있습니다. 지정된 포토를 사용해 접속이 확립되면, Flash Player 는 null 바이트로 종료하는 <policy-file-request /> 를 송신합니다. XMLSocket 서버를 설정하는 것으로, policy 파일과 통상의 XMLSocket 접속에 같은 포토를 사용할 수가 있습니다. 이 경우, 서버는 <policy-file-request /> 가 수신될 때까지 대기해, 그 후로 policy 파일을 송신할 필요가 있습니다. 표준의 접속과는 다른 포토를 사용해, policy 파일을 제공하도록(듯이) 서버를 설정할 수도 있습니다. 이 경우는, policy 파일 전용의 포토로 접속이 확립되자마자 policy 파일을 송신할 수 있습니다. policy 파일을 종료하기 위해서 서버로부터 null 바이트를 송신해, 그 이후의 접속을 닫을 필요가 있습니다. 서버측에서 접속을 닫지 않으면, 마지막 null 바이트가 수신되자마자 Flash Player 측에서 접속이 닫혀집니다.

XMLSocket 서버로 제공하는 policy 파일의 문장구조법은, 다른 policy 파일과 거의 같습니다만, 액세스를 허가하는 포토도 지정할 필요가 있는 점이 다릅니다. policy 파일이 1024 미만의 포토로부터 제공되는 경우, 임의의 포토에의 액세스가 허가됩니다. policy 파일이 1024 이상의 포토로부터 제공되는 경우, 다른 1024 이상의 포토에게만 액세스를 허가할 수 있습니다. 허가하는 포토는,<allow-access-from> 태그의 "to-ports" 속성으로 지정합니다. 단일의 포토 번호, 포토 범위, 와일드 카드를 사용할 수 있습니다. 다음에, XMLSocket policy 파일의 예를 나타냅니다.

  <cross-domain-policy>
    <allow-access-from domain="*" to-ports="507" />
    <allow-access-from domain="*. foo.com" to-ports="507,516" />
    <allow-access-from domain="*. bar.com" to-ports="516-523" />
    <allow-access-from domain="www.foo.com" to-ports="507,516-523" />
    <allow-access-from domain="www.bar.com" to-ports="*" />
  </cross-domain-policy>

원의 디폴트의 장소, 즉 HTTP 서버의 포토 80 의 /crossdomain.xml 로부터 취득된 policy 파일에서는, 1024 이상의 전포토에의 액세스가 암묵적으로 허가되고 있습니다. HTTP 서버의 다른 장소로부터, XMLSocket 조작을 허가하는 policy 파일을 취득할 수 없습니다. XMLSocket policy 파일을 독자적인 장소에 두는 경우, XMLSocket 서버상에 둘 필요가 있습니다.

1024 미만의 포토에 접속하는 기능은 새롭기 때문에, 무비 클립이 자기 자신의 서브 도메인에 접속하는 경우에서도,loadPolicyFile() 에 의해 로드하는 policy 파일을 사용해 항상 이 접속의 허가를 실시할 필요가 있습니다.

상세한 것에 대하여는, 다음의 주제를 참조해 주세요.

「ActionScript 3.0 의 프로그래밍」의시큐러티의 장과 LiveDocs 의 최신 코멘트

Flash Player 9 시큐러티에 관한 화이트 페이퍼

Parameters

url:String — 로드하는 도메인간 policy 파일의 URL 의 장소.

See also

Flash Player 시큐러티

showSettings

()

Methods

public static function showSettings(panel:String = "default"):void

Flash Player 의 [시큐러티 설정] 패널을 표시합니다.

Parameters

panel:String (default = "default") — 어느 [시큐러티 설정] 패널을 표시하는지를 지정하는 SecurityPanel 클래스의 값입니다. 이 Parameters를 생략 하면,SecurityPanel.DEFAULT 가 사용됩니다.

See also

SecurityPanel
Flash Player 시큐러티

정수의 상세

LOCAL_TRUSTED

정수

public static const LOCAL_TRUSTED:String = "localTrusted"

SWF 파일은 로컬 파일이며, 설정 매니저 또는 "FlashPlayerTrust" 구성 파일을 사용해 신뢰성이 있습니다. 로컬의 데이터 소스로부터 읽어내는 일도, 인터넷으로 교환할 수도 있습니다.

LOCAL_WITH_FILE

정수

public static const LOCAL_WITH_FILE:String = "localWithFile"

SWF 파일은 로컬 파일이며, 신뢰성은 없고, 네트워크를 지정해 Publish 되고 있는 것은 아닙니다. 로컬의 데이터 소스로부터 읽어낼 수가 있습니다만, 인터넷에서의 교환은 할 수 없습니다.

LOCAL_WITH_NETWORK

정수

public static const LOCAL_WITH_NETWORK:String = "localWithNetwork"

SWF 파일은 로컬 파일이며, 신뢰성은 없습니다만, 네트워크를 지정해 Publish 되고 있습니다. 이 SWF 파일은 인터넷과의 교환은 할 수 있습니다만, 로컬 데이터 소스로부터의 독해는 할 수 없습니다.

REMOTE

정수

public static const REMOTE:String = "remote"

SWF 파일은 인터넷 URL 로부터의 것이며, 도메인 베이스의 샌드 박스 규칙에 따라 기능합니다.

Examples

다음의 예는, Sprite object의 click 이벤트를, Flash Player 의 [설정] 의 [로컬 기억 area] 패널을 표시하기 위해서 어떻게 사용할 수 있는지를 나타내고 있습니다. 오렌지의 박스가, draw() 를 사용해 스테이지에 추가됩니다. draw() 에서는,click event listener에게 이름 첨부 clickHandler() 가 추가됩니다. 이것은 click 이벤트에 응답해 [로컬 기억 area] 패널을 열도록(듯이) Flash Player 에 지시합니다.

package {
    import flash.display.Sprite;
    import flash.text.TextField;
    import flash.events. *;
    import flash.system.Security;
    import flash.system.SecurityPanel;

    public class SecurityExample extends Sprite {
        private var bgColor:uint = 0xFFCC00;
        private var size:uint = 100;

        public function SecurityExample() {
            draw();
        }

        private function draw() :void {
            var child:Sprite = new Sprite();
            child.graphics.beginFill(bgColor);
            child.graphics.drawRect(0, 0, size, size);
            child.graphics.endFill();
            child.buttonMode = true;

            var label:TextField = new TextField();
            label.text = "settings";
            label.selectable = false;
            label.mouseEnabled = false;
            child.addChild(label);

            child.addEventListener(MouseEvent.CLICK, clickHandler);
            addChild(child);
        }

        private function clickHandler(event:MouseEvent) :void {
            Security.showSettings(SecurityPanel.LOCAL_STORAGE);
        }
    }
}

Adobe® Flex™ 2 Language Reference		모든 패키지 \| 모든 클래스 \| 언어 엘리먼트 \| 색인 \| 부록 \| 규칙 \| 프레임내에 표시 프레임 없음 버젼
Class Security	property \| Methods \| 정수 \| 예

Package	flash.system
Class	public final class Security
Inheritance	Security Object