카메라 및 마이크 권한, 저장소 할당량 및 영구 공유 객체 저장에 대한 설정을 비롯한 특정 Flash Player 설정에 사용할 도메인을 선택하는 방법을 결정합니다. SWF 파일에서 Flash Player 6에 사용했던 설정을 사용하려면 exactSettings를 false로 설정해야 합니다.

Flash Player 6에서 이러한 플레이어 설정에 사용되는 도메인은 SWF 파일 도메인의 첫 번째 부분을 제외한 나머지 부분입니다. 예를 들어, SWF 파일의 도메인이 www.example.com과 같이 세 부분 이상으로 구성된 경우 도메인의 첫 번째 부분("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의 기본값은 true입니다. 기본값에서 exactSettings를 변경하려면 Flash Player에서 카메라 또는 마이크 사용, 영구 공유 객체 검색 등 플레이어 설정을 선택해야 하는 이벤트가 발생하기 전에 변경해야 합니다.

이전에 버전 6 SWF 파일을 제작했고 이를 바탕으로 영구 공유 객체를 만든 경우 이 파일을 버전 7 이상으로 포팅한 후 해당 SWF 파일에서 영구 공유 객체를 검색하거나 버전 7 이상인 다른 SWF 파일에서 영구 공유 객체를 검색하려면 SharedObject.getLocal()을 호출하기 전에 Security.exactSettings를 false로 설정해야 합니다.

참고 사항

호출하는 SWF 파일이 작동 중인 보안 샌드박스의 유형을 나타냅니다.

Security.sandboxType은 다음 값 중 하나를 갖습니다.

• remote(Security.REMOTE): 인터넷 URL에서 가져온 SWF 파일이며 도메인 기반 샌드박스 규칙에 따라 작동합니다.
• localWithFile(Security.LOCAL_WITH_FILE): SWF 파일이 로컬 파일이고 사용자가 신뢰하지 않았으며 네트워킹 지정과 함께 제작되지 않았습니다. 이 SWF 파일은 로컬 데이터 소스에서 읽을 수 있지만 인터넷과 통신할 수는 없습니다.
• localWithNetwork(Security.LOCAL_WITH_NETWORK): SWF 파일이 로컬 파일이고 사용자가 신뢰하지 않았으며 네트워킹 지정과 함께 제작되었습니다. 이 SWF 파일은 인터넷과 통신할 수 있지만 로컬 데이터 소스에서 읽을 수는 없습니다.
• localTrusted(Security.LOCAL_TRUSTED): 이 SWF 파일은 로컬 파일로, 사용자가 설정 관리자 또는 FlashPlayerTrust 구성 파일을 사용하여 신뢰했습니다. 이 SWF 파일은 로컬 데이터 소스에서 읽을 수 있고 인터넷과 통신할 수 있습니다.

이 속성은 모든 버전의 SWF 파일에서 사용할 수 있지만 Flash Player 8 이상에서만 지원됩니다. 따라서 이 속성은 Flash Player 8에서 재생하는 버전 7 SWF 파일 등에서 검사할 수 있습니다. 이러한 모든 버전 지원은 버전 8 이하용으로 제작할 경우 제작 시 이 속성의 재생 가능 여부를 알 수 없음을 의미합니다. 따라서 버전 7 이하의 SWF 파일에서 즉, flash.system.Capabilities.version에 표시되는 플레이어 버전이 8보다 낮은 경우 이 속성은 정의되지 않은 값을 가집니다. 이러한 경우 SWF 파일이 로컬 파일인지 여부에 따라 샌드박스 유형을 결정할 수 있습니다. 로컬 파일이면 SWF 파일이 localTrusted로 분류됩니다. Flash Player 8 이전에는 모든 로컬 내용이 이러한 방식으로 처리되었습니다. 로컬 파일이 아니면 SWF 파일이 remote로 분류됩니다.

자세한 내용은 다음을 참조하십시오.

• 보안 장(ActionScript 3.0 프로그래밍 설명서) 및 LiveDocs의 최신 의견
• Flash Player 9 보안 백서

참고 사항

지정된 도메인의 SWF 파일과 HTML 파일이 allowDomain() 호출을 포함하는 SWF 파일의 객체 및 변수에 액세스할 수 있도록 합니다.

예를 들어, http://mysite.com/swfA.swf 및 http://mysite.com/swfB.swf와 같이 두 개의 SWF 파일이 동일한 도메인에서 제공되는 경우, swfA.swf는 swfB.swf의 변수, 객체, 속성, 메서드 등을 검사 및 수정할 수 있고, swfB.swf도 swfA.swf에 대해 동일한 작업을 수행할 수 있습니다. 이를 크로스 무비 스크립팅 또는 간단히 크로스 스크립팅이라고 합니다.

http://siteA.com/swfA.swf와 http://siteB.com/siteB.swf처럼 두 SWF 파일이 서로 다른 도메인에서 제공되는 경우에는, 기본적으로 swfA.swf에서 swfB.swf를, swfB.swf에서 swfA.swf를 스크립팅할 수 없습니다. SWF 파일은 Security.allowDomain()을 호출하여 다른 도메인의 SWF 파일을 제공합니다. 이것을 크로스 도메인 스크립팅이라고 합니다. siteB.swf에서 Security.allowDomain("siteA.com")을 호출하면 siteA.swf에 스크립팅 권한이 부여됩니다.

크로스 도메인 상황에서는 관련되는 두 도메인을 명확하게 구별하는 것이 중요합니다. 이 설명서에서는 크로스 스크립팅을 수행하는 쪽을 액세스하는 항목(일반적으로 액세스하는 SWF)이라고 하고, 다른 한 쪽을 액세스되는 항목(일반적으로 액세스되는 SWF)이라고 합니다. siteA.swf에서 siteB.swf를 스크립팅하는 경우, siteA.swf는 액세스하는 항목이고 siteB.swf는 액세스되는 항목입니다.

allowDomain()으로 설정된 크로스 도메인 권한은 비대칭적입니다. 앞의 예제에서 siteA.swf는 siteB.swf를 스크립팅할 수 있지만 siteB.swf는 siteA.swf를 스크립팅할 수 없습니다. siteA.swf에서 allowDomain()을 호출하여 siteB.com에 있는 SWF 파일에 스크립팅 권한을 부여하지 않았기 때문입니다. 대칭적인 권한을 설정하려면 두 SWF 파일 모두에서 allowDomain()을 호출합니다.

Flash Player에서 SWF 파일은 다른 SWF 파일의 크로스 도메인 스크립팅으로부터 보호될 뿐 아니라 HTML 파일의 크로스 도메인 스크립팅으로부터도 보호됩니다. HTML에서 SWF로의 스크립팅은 SetVariable 등의 이전 Flash 브라우저 함수 또는 ExternalInterface.addCallback()을 통해 설정된 콜백에서 발생할 수 있습니다. HTML에서 SWF로의 스크립팅이 다른 도메인 간에 발생하는 경우 액세스하는 항목이 SWF 파일일 때와 마찬가지로 액세스되는 SWF 파일에서 allowDomain()을 호출해야 하며, 그렇지 않으면 작업이 실패합니다.

IP 주소를 allowDomain()의 매개 변수로 지정하더라도 지정된 IP 주소에 있는 모든 항목에 액세스가 허용되는 것은 아닙니다. 이때 해당 IP 주소에 매핑되는 도메인 이름이 아닌 URL에 지정한 IP 주소가 들어 있는 항목에만 액세스가 허용됩니다.

버전별 차이점

Flash Player의 크로스 도메인 보안 규칙은 버전이 높아짐에 따라 개선되어 왔습니다. 다음 표는 이러한 차이점을 요약한 것입니다.

Flash Player의 비헤이비어를 제어하는 것은 Flash Player 자체의 버전이 아니라 SWF 버전(SWF의 제작 버전)입니다. 예를 들어 Flash Player 8에서 버전 7용으로 제작된 SWF 파일을 재생하는 경우 버전 7과 같은 비헤이비어가 적용됩니다. 따라서 플레이어를 업그레이드해도 배포된 SWF 파일의 Security.allowDomain()의 비헤이비어가 변경되지 않습니다.

앞에 나온 표의 버전 열에서는 크로스 스크립팅 작업과 관련된 최신 SWF 버전을 보여 줍니다. Flash Player의 비헤이비어는 액세스하는 SWF 파일의 버전과 액세스되는 SWF 파일의 버전 중 더 높은 버전에 따라 결정됩니다.

다음 단락에서는 Security.allowDomain()과 관련된 Flash Player의 보안 변경 내용을 보다 자세히 설명합니다.

버전 5: 크로스 도메인 스크립팅에 대한 제한이 없습니다.

버전 6: 크로스 도메인 스크립팅 보안이 도입됩니다. 기본적으로 Flash Player에서 크로스 도메인 스크립팅이 금지되며, Security.allowDomain()을 통해 허용할 수 있습니다. 두 파일이 동일한 도메인에 있는지 확인하기 위해 Flash Player는 파일 URL의 정확한 호스트 이름에서 첫 부분을 제외한 나머지 최소 두 부분으로 이루어진, 각 파일의 수퍼 도메인을 사용합니다. 예를 들어 www.mysite.com의 수퍼 도메인은 mysite.com입니다. www.mysite.com과 store.mysite.com에 있는 SWF 파일은 Security.allowDomain()을 호출하지 않아도 서로 스크립팅할 수 있습니다.

버전 7: 수퍼 도메인 일치에서 정확한 도메인 일치로 변경되었습니다. 두 파일의 URL에서 호스트 이름이 동일한 경우에만 서로 스크립팅할 수 있으며, 그렇지 않을 경우 Security.allowDomain()을 호출해야 합니다. 두 파일이 정확히 같은 도메인에서 로드된 경우에도 기본적으로 HTTPS가 아닌 URL에서 로드된 파일은 HTTPS URL에서 로드된 파일을 스크립팅할 수 없습니다. 이러한 제한을 통해 HTTPS 파일을 보호할 수 있습니다. HTTPS가 아닌 파일은 다운로드 과정에서 수정될 위험이 있으며 악의적으로 수정된 경우, 이러한 수정이 불가능한 HTTPS 파일을 손상시킬 수 있기 때문입니다. Security.allowInsecureDomain()이 도입되어 액세스되는 HTTPS SWF 파일에서 이러한 제한을 임의로 해제할 수 있게 되었으나, 가급적 Security.allowInsecureDomain()을 사용하지 않는 것이 좋습니다.

버전 8: 두 가지 주요 영역이 변경되었습니다.

• 이제 액세스되는 SWF 파일에서 Security.allowDomain()을 호출한 경우에만 Security.allowDomain()을 통해 크로스 스크립팅 작업이 허용됩니다. 즉, Security.allowDomain()을 호출하는 SWF 파일에서는 이제 자신에 대한 액세스만 허용할 수 있습니다. 이전 버전에서는 Security.allowDomain()을 호출하면 크로스 스크립팅 작업에서 Security.allowDomain()을 호출한 SWF 파일과 동일한 도메인에 있는 모든 SWF 파일에 액세스할 수 있습니다. 즉, 이전에는 Security.allowDomain()을 호출하면 호출하는 SWF 파일의 도메인 전체가 열렸습니다.
• Security.allowDomain("*") 및 Security.allowInsecureDomain("*")을 통해 와일드카드 값에 대한 지원이 추가되었습니다. 와일드카드(*) 값을 사용하면 로드되는 위치에 관계없이 액세스하는 모든 파일에서 크로스 스크립팅 작업이 허용됩니다. 와일드카드는 전역 권한으로 생각하면 됩니다. 와일드카드 권한은 로컬 파일 보안 규칙 하에서 특정 종류의 작업을 위해 필요합니다. 특히 인터넷의 SWF 파일을 스크립팅할 수 있는 권한이 있는 로컬 SWF 파일의 경우 로컬 SWF 파일의 출처를 알 수 없으므로 액세스되는 인터넷 SWF 파일에서 Security.allowDomain("*")을 호출해야 합니다. 인터넷 SWF 파일이 HTTPS URL에서 로드되는 경우에는 인터넷 SWF 파일에서 Security.allowInsecureDomain("*")을 대신 호출해야 합니다.

경우에 따라 다른 도메인에서 자식 SWF 파일을 로드하고 자식 SWF 파일에서 부모 SWF 파일을 스크립팅할 수 있는 권한을 부여해야 하지만 자식 SWF 파일의 최종 도메인을 알 수 없는 경우가 있습니다. 로드 균형 조정 리디렉션이나 타사 서버를 사용하는 경우 이러한 상황이 발생할 수 있습니다.

이러한 경우 Loader.load()에 전달하는 URLRequest 객체의 url 속성을 사용할 수 있습니다. 예를 들어 자식 SWF 파일을 부모 SWF 파일로 로드하는 경우 다음과 같이 부모 SWF에서 Loader 객체의 contentLoaderInfo 속성에 액세스할 수 있습니다.

Security.allowDomain(loader.contentLoaderInfo.url)

이때 올바른 url 속성 값을 가져오려면 자식 SWF 파일이 로드되기 시작할 때까지 기다려야 합니다. 자식 SWF가 로드되기 시작하는 시점을 확인하려면 progress 이벤트를 사용합니다.

이와 반대의 상황이 발생할 수도 있습니다. 즉, 자식 SWF 파일을 만들고 부모에 자식 SWF 파일을 스크립팅할 수 있는 권한을 부여해야 하지만 부모의 도메인을 알 수 없습니다. 이러한 경우 SWF의 루트 객체인 표시 객체의 loaderInfo 속성에 액세스할 수 있습니다. 자식 SWF에서 Security.allowDomain(this.root.loaderInfo.loaderURL)을 호출합니다. 자식이 로드될 때 부모가 이미 로드되었기 때문에 부모 SWF 파일이 로드될 때까지 기다릴 필요가 없습니다.

Flash Player 8 이상용으로 제작하는 경우 Security.allowDomain("*")을 호출하여 이러한 상황을 처리할 수도 있습니다. 그러나 경우에 따라 이 방법은 위험할 수 있습니다. 도메인에 관계없이 다른 모든 SWF 파일이 액세스할 수 있도록 호출하는 SWF 파일이 열리게 되기 때문입니다. 일반적으로 _url 속성을 사용하는 것이 더 안전합니다.

자세한 내용은 다음을 참조하십시오.

• 보안 장(ActionScript 3.0 프로그래밍 설명서) 및 LiveDocs의 최신 의견
• Flash Player 9 보안 백서

매개 변수

참고 사항

지정된 도메인의 SWF 파일과 HTML 파일이, 호출하는 SWF 파일(HTTPS 프로토콜을 통해 호스팅되는)의 객체 및 변수에 액세스할 수 있도록 합니다. 이 메서드는 사용하지 않는 것이 좋습니다. 이 항목의 뒷부분에서 "보안 고려 사항"을 참조하십시오.

이 메서드는 Security.allowDomain()과 동일한 방식으로 작동하지만 액세스하는 항목이 HTTPS가 아닌 프로토콜을 사용하여 로드되고, 액세스되는 항목이 HTTPS를 사용하여 로드되는 경우에도 작업을 허용합니다. Flash Player 7 이상에서는 HTTPS가 아닌 파일이 HTTPS 파일을 스크립팅할 수 없습니다. 액세스되는 HTTPS SWF 파일에서 allowInsecureDomain() 메서드를 사용하면 이 제한이 해제됩니다.

allowInsecureDomain()은 HTTPS가 아닌 파일에서 HTTPS 파일로의 스크립팅을 허용하기 위해서만 사용합니다. 이 메서드는 http://mysite.com의 SWF 파일에서 http://mysite.com의 SWF 파일을 스크립팅하려는 경우와 같이 액세스하는 파일(HTTPS가 아닌 파일)과 액세스되는 HTTPS 파일이 같은 도메인에서 제공되는 경우에 사용합니다. 이 메서드를 HTTPS가 아닌 파일 간, HTTPS 파일 간 또는 HTTPS 파일에서 HTTPS가 아닌 파일로 스크립팅하는 데 사용하지 마십시오. 이러한 상황에서는 대신 allowDomain()을 사용합니다.

보안 고려 사항: Flash Player는 유연성을 최대화하기 위해 allowInsecureDomain()을 제공하지만 이 메서드는 호출하지 않는 것이 좋습니다. HTTPS상에서 파일을 제공하는 경우 여러 가지 보호 기능이 사용되는데, allowInsecureDomain을 호출하면 이러한 보호 기능 중 하나가 약화됩니다. 다음 시나리오는 allowInsecureDomain()을 주의하여 사용하지 않을 경우 보안이 약화될 수 있음을 보여 줍니다.

다음 정보는 크로스 스크립팅의 실제 예를 통해 allowInsecureDomain()에 대한 이해를 돕기 위한 것으로 발생 가능한 시나리오 중 하나에 불과합니다. 이 정보는 보안 아키텍처와 관련한 모든 문제를 다루지 않으며, 배경 정보로만 사용되어야 합니다. Flash Player 개발자 센터에는 Flash Player와 보안에 대한 풍부한 정보가 있습니다. 자세한 내용은 http://www.adobe.com/devnet/security/를 참조하십시오.

여기서는 공개 정보만 들어 있으므로 보안이 필요하지 않은 카탈로그와 사용자의 금융 및 개인 정보 보호를 위해 보안 기능이 필요한 장바구니/체크 아웃 구성 요소라는 두 가지 구성 요소로 이루어진 전자 상거래 사이트를 구축하는 시나리오를 가정해 봅니다. 카탈로그는 http://mysite.com/catalog.swf에서 장바구니는 https://mysite.com/cart.swf에서 제공하려고 합니다. 이때 사이트에서 제3자가 보안 아키텍처의 약점을 이용하여 사용자의 신용 카드 번호를 도용할 수 없도록 해야 합니다.

중간 공격자가 서버와 사용자 사이에 끼어들어 사용자가 장바구니 응용 프로그램에 입력하는 신용 카드 번호를 훔치려고 하는 상황을 생각해 보십시오. 예를 들어, 중간 공격자는 사용자 중 일부가 이용하는 비양심적인 ISP 또는 사용자 작업 공간의 악의적인 관리자와 같이 공개 인터넷을 통해 사용자와 서버 간에 전송되는 네트워크 패킷을 보거나 변경할 수 있는 모든 사람이 될 수 있습니다. 이러한 상황은 흔히 있을 수 있습니다.

cart.swf가 HTTPS를 사용하여 서버에 신용 카드 정보를 전송하는 경우에는 HTTPS 전송 내용이 암호화되기 때문에 중간 공격자가 네트워크 패킷에서 이 정보를 직접 훔칠 수 없습니다. 하지만 공격자는 사용자에게 제공되는 SWF 파일 중 하나의 내용을 변경하여 자신이 소유한 다른 서버로 사용자 정보를 전송하는 변경된 버전으로 기존의 SWF 파일을 바꾸는 등의 다른 기법을 사용할 수 있습니다.

HTTPS 전송 내용은 암호화될 뿐 아니라 부당한 변경이 불가능하므로 HTTPS 프로토콜은 무엇보다도 이러한 "수정" 공격을 방지합니다. 즉, 중간 공격자가 패킷을 변경하면 받는 쪽에서 이러한 변경 사실을 감지하여 해당 패킷을 폐기합니다. 따라서 이 상황에서는 공격자가 HTTPS를 통해 제공되는 cart.swf를 변경할 수 없습니다.

그러나 HTTP를 통해 제공되는 catalog.swf에 버튼을 허용하거나 HTTPS를 통해 제공되는 cart.swf의 장바구니에 항목을 추가하려는 경우를 가정해 보겠습니다. 이를 위해 cart.swf는 allowInsecureDomain()을 호출하여 catalog.swf에서 cart.swf를 스크립팅할 수 있도록 합니다. 이렇게 하면 의도하지 않은 결과가 나타날 수 있는데, catalog.swf가 HTTP로 제공되어 부당한 변경을 방지할 수 없으므로 공격자는 사용자가 처음으로 catalog.swf를 다운로드할 때 이 파일을 수정할 수 있게 됩니다. cart.swf에는 allowInsecureDomain()에 대한 호출이 들어 있으므로 공격자가 변경한 catalog.swf에서 이제 cart.swf를 스크립팅할 수 있습니다. 변경된 catalog.swf 파일은 ActionScript를 사용하여 cart.swf의 변수에 액세스하여 사용자의 신용 카드 정보 및 기타 기밀 데이터를 읽을 수 있습니다. 그 후 변경된 catalog.swf는 이러한 데이터를 공격자의 서버로 보낼 수 있습니다.

확실히 이러한 상황은 바람직하지 않지만 사이트상의 두 SWF 파일 간에 크로스 스크립팅을 계속 허용해야 하는 경우가 있습니다. 다음은 allowInsecureDomain()을 피하도록 가상 전자 상거래 사이트를 다시 설계할 수 있는 두 가지 방법입니다.

• 응용 프로그램의 모든 SWF 파일을 HTTPS를 통해 제공합니다. 이는 단연 가장 간단하면서도 가장 안정적인 솔루션입니다. 위의 시나리오에서는 catalog.swf와 cart.swf를 모두 HTTPS를 통해 제공합니다. catalog.swf와 같은 파일을 HTTP에서 HTTPS로 전환하면 대역폭 소비량과 CPU 로드가 약간 늘어나고 사용자의 응용 프로그램 로드 시간이 약간 길어질 수 있습니다. 실제 서버를 사용하여 이러한 영향의 심각도를 판단해야 하는데 각각 10~20% 이상 저하되지 않는 것이 일반적이며 전혀 저하되지 않는 경우도 있습니다. 일반적으로 서버에 HTTPS 가속 하드웨어나 소프트웨어를 사용하여 이러한 영향을 줄일 수 있습니다. HTTPS를 통해 모든 관련 SWF 파일을 제공할 경우의 주요 이점은 브라우저에서 혼합 내용 경고를 생성하지 않으면서 사용자 브라우저의 기본 URL로 HTTPS URL을 사용할 수 있다는 것입니다. 또한 브라우저의 자물쇠 아이콘이 표시되어 일반적이고 신뢰할 수 있는 보안 정보를 제공합니다.
• 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에 제공할 위험이 있음을 고려해야 합니다. 일반적인 체크 아웃 과정에서는 장바구니 내용과 총 비용을 표시하여 사용자가 최종 승인토록 함으로써 이러한 위험을 어느 정도 완화하고 있지만 위험은 여전히 남아 있습니다.

지난 수년 간 웹 브라우저는 HTTPS 파일과 HTTPS가 아닌 파일의 구분을 강화해 왔으며 위의 시나리오는 이 제한이 필요한 한 가지 이유를 잘 보여 줍니다. Flash Player에서는 반드시 필요할 경우 이 보안 제한을 피할 수 있는 방법을 제공하지만, 이를 이용하기 전에 먼저 그 결과에 대해 주의깊게 생각해 봐야 합니다.

자세한 내용은 다음을 참조하십시오.

• 보안 장(ActionScript 3.0 프로그래밍 설명서) 및 LiveDocs의 최신 의견
• Flash Player 9 보안 백서

매개 변수

참고 사항

url 매개 변수에 의해 지정된 위치에서 크로스 도메인 정책 파일을 로드합니다. Flash Player는 정책 파일을 사용하여 Flash 무비에서 자체 서버가 아닌 다른 서버에 있는 데이터를 로드할 수 있도록 허용할지 여부를 결정합니다.

기본적으로 Flash Player는 데이터 로드 요청이 발생한 대상 서버의 /crossdomain.xml에서만 정책 파일을 찾습니다.

다음 예제와 같이 Security.loadPolicyFile()을 사용하면 Flash Player에서 임의의 위치에 있는 정책 파일을 로드할 수 있습니다.

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

이렇게 하면 Flash Player는 지정된 URL에서 정책 파일을 가져옵니다. 해당 위치의 정책 파일에서 허가된 모든 권한은 서버의 가상 디렉토리 계층에서 동일한 수준 또는 이하 수준의 모든 내용에 적용됩니다. 예를 들어 위의 코드를 사용하면 다음 행에서 예외가 발생하지 않습니다.

 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()을 사용하여 정책 파일을 개수에 관계없이 로드할 수 있습니다. 정책 파일이 필요한 요청의 경우 항상 Flash Player는 요청을 거부하기 전에 모든 정책 파일 다운로드가 완료되기를 기다립니다. loadPolicyFile()로 지정된 정책 파일 중에서 요청을 허가하는 정책 파일이 없을 경우 최종적으로 Flash Player는 원래의 기본 위치인 /crossdomain.xml을 참조합니다.

다음 예제와 같이 특정 포트 번호와 함께 xmlsocket 프로토콜을 사용하면 XMLSocket 서버에서 정책 파일을 직접 검색할 수 있습니다.

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

이렇게 하면 Flash Player는 지정된 호스트 및 포트에서 정책 파일을 가져옵니다. 1024 이상의 포트뿐만 아니라 모든 포트를 사용할 수 있습니다. 지정된 포트와 연결이 설정되면 Flash Player는 null 바이트로 끝나는 <policy-file-request />를 전송합니다. 정책 파일을 전송하기 전에 서버에서 <policy-file-request />를 기다려야 하는 경우 동일한 포트를 통해 정책 파일과 일반 XMLSocket 연결을 모두 제공하도록 XMLSocket 서버를 구성할 수 있습니다. 표준 연결과 다른 포트를 통해 정책 파일을 제공하도록 서버를 설정할 수도 있으며 이러한 경우 전용 정책 파일 포트에 연결함과 동시에 서버에서 정책 파일을 전송할 수 있습니다. 서버는 정책 파일을 종료하기 위해 null 바이트를 전송해야 하며 그 이후에 연결을 닫을 수 있습니다. 서버에서 연결을 닫지 않으면 Flash Player에서 종료 null 바이트를 받는 즉시 연결을 닫습니다.

XMLSocket 서버에서 제공하는 정책 파일은 액세스가 허용되는 포트를 지정해야 한다는 점을 제외하고 다른 정책 파일과 동일한 구문을 사용합니다. 1024보다 낮은 포트에서 제공되는 정책 파일에서는 모든 포트에 액세스를 허용할 수 있고, 1024 이상의 포트에서 제공되는 정책 파일에서는 1024 이상의 다른 포트에만 액세스를 허용할 수 있습니다. 허용되는 포트는 <allow-access-from> 태그의 "to-ports" 특성에 지정됩니다. 단일 포트 번호, 포트 범위 및 와일드카드가 모두 허용됩니다. 다음 예제에서는 XMLSocket 정책 파일을 보여 줍니다.

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

이전 기본 위치인 포트 80 HTTP 서버의 /crossdomain.xml에서 가져온 정책 파일은 1024 이상의 모든 포트에 암시적으로 액세스를 허가합니다. XMLSocket 작업을 허가하기 위해 HTTP 서버의 다른 위치에서 정책 파일을 가져올 수 있는 방법은 없습니다. XMLSocket 정책 파일에 대한 모든 사용자 정의 위치는 XMLSocket 서버에 있어야 합니다.

1024보다 낮은 포트에 연결하는 기능은 loadPolicyFile()을 사용하여 로드한 정책 파일을 통해서만 사용할 수 있습니다.

SWF 내용을 포함하는 HTML 페이지에서 object 및 embed 태그의 allowNetworking 매개 변수를 설정하여 SWF 파일에서 이 메서드를 사용하지 않도록 할 수 있습니다.

자세한 내용은 다음을 참조하십시오.

• 보안 장(ActionScript 3.0 프로그래밍 설명서) 및 LiveDocs의 최신 의견
• Flash Player 9 보안 백서

매개 변수

참고 사항

Flash Player에서 [보안 설정] 패널을 표시합니다.

매개 변수

참고 사항

SWF 파일이 로컬 파일이고 사용자가 설정 관리자 또는 FlashPlayerTrust 구성 파일을 사용하여 신뢰했습니다. 이 SWF 파일은 로컬 데이터 소스에서 읽을 수 있고 인터넷과 통신할 수 있습니다.

참고 사항

SWF 파일이 로컬 파일이고 사용자가 신뢰하지 않았으며 네트워킹 지정과 함께 제작되지 않았습니다. 이 SWF 파일은 로컬 데이터 소스에서 읽을 수 있지만 인터넷과 통신할 수는 없습니다.

참고 사항

SWF 파일이 로컬 파일이고 사용자가 신뢰하지 않았으며 네트워킹 지정과 함께 제작되었습니다. 이 SWF 파일은 인터넷과 통신할 수 있지만 로컬 데이터 소스에서 읽을 수는 없습니다.

참고 사항

인터넷 URL에서 가져온 SWF 파일이며 도메인 기반 샌드박스 규칙에 따라 작동합니다.

참고 사항