Flash Player and AIR content can exchange data with servers. Loading data is a different kind of operation from loading media, because the loaded information appears as program objects, rather than being displayed as media. Generally, content may load data from the same domain that the content originated from. However, content usually requires policy files in order to load data from other domains (see Website controls (policy files)).
Note: Content running in the AIR application sandbox is never served from a remote domain (unless the developer intentionally imports remote content into the application sandbox), so it cannot participate in the types of attacks that policy files protect against. AIR content in the application sandbox is not restricted from loading data by policy files. However, AIR content in other sandboxes is subject to the restrictions described here.
Using URLLoader and URLStream
You can load data, such as an XML file or a text file. The load() methods of the URLLoader and URLStream classes are governed by URL policy file permissions. If you use the load() method to load content from a domain other than that of the code that is calling the method, the runtime checks for a URL policy file on the server of the loaded assets. If there is a policy file, and it grants access to the domain of the loading content, you can load the data.
Connecting to sockets
By default, the runtime looks for a socket policy file served from port 843. As with URL policy files, this file is called the master policy file. When policy files were first introduced in Flash Player 6, there was no support for socket policy files. Connections to socket servers were authorized by a policy file in the default location on an HTTP server on port 80 of the same host as the socket server. Flash Player 9 still supports this capability, but Flash Player 10 does not. In Flash Player 10, only socket policy files can authorize socket connections. Like URL policy files, socket policy files support a meta-policy statement that specifies which ports can serve policy files. However, instead of “master-only,” the default meta-policy for socket policy files is “all.” That is, unless the master policy file specifies a more restrictive setting, Flash Player assumes that any socket on the host can serve a socket policy file. Access to socket and XML socket connections is disabled by default, even if the socket you are connecting to is in the same domain as the SWF file. You can permit socket-level access by serving a socket policy file from any of the following locations:
Port 843 (the location of the master policy file)
The same port as the main socket connection
A different port than the main socket connection
By default, Flash Player looks for a socket policy file on port 843 and on the same port as the main socket connection. If you want to serve a socket policy file from a different port, the SWF file must call Security.loadPolicyFile(). A socket policy file has the same syntax as a URL policy file, except that it must also specify the ports to which it grants access. When a socket policy file is served from a port number below 1024, it may grant access to any ports; when a policy file comes from port 1024 or higher, it may grant access only to ports 1024 and higher. The allowed ports are specified in a to-ports attribute in the <allow-access-from> tag. Single port numbers, port ranges, and wildcards are accepted values. Here is an example socket policy file: <?xml version="1.0"?><!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd"><!-- Policy file for xmlsocket://socks.mysite.com --><cross-domain-policy><allow-access-fromdomain="*"to-ports="507" /><allow-access-fromdomain="*.example.com"to-ports="507,516" /><allow-access-fromdomain="*.example.org"to-ports="516-523" /><allow-access-fromdomain="adobe.com"to-ports="507,516-523" /><allow-access-fromdomain="192.0.34.166"to-ports="*" /></cross-domain-policy> To retrieve a socket policy file from port 843 or from the same port as a main socket connection, call the Socket.connect() or XMLSocket.connect() method. Flash Player first checks for a master policy file on port 843. If it finds one, it checks to see if the file contains a meta-policy statement that prohibits socket policy files on the target port. If access isn’t prohibited, Flash Player first looks for the appropriate allow-access-from statement in the master policy file. If it doesn’t find one, it then looks for a socket policy file on the same port as the main socket connection. To retrieve a socket policy file a different location, first call the Security.loadPolicyFile() method with the special "xmlsocket" syntax, as in the following: Security.loadPolicyFile("xmlsocket://server.com:2525"); Call the Security.loadPolicyFile() method before calling the Socket.connect() or XMLSocket.connect() method. Flash Player then waits until it has fulfilled your policy file request before deciding whether to allow your main connection. However, if the master policy file specifies that the target location can’t serve policy files, the call to loadPolicyFile() has no effect, even if there is a policy file at that location. If you are implementing a socket server and you need to provide a socket policy file, decide whether to provide the policy file using the same port that accepts main connections, or using a different port. In either case, your server must wait for the first transmission from your client before sending a response. When Flash Player requests a policy file, it always transmits the following string as soon as a connection is established: <policy-file-request/> Once the server receives this string, it can transmit the policy file. The request from Flash Player is always terminated by a null byte, and the response from the server must also be terminated by a null byte. Do not expect to reuse the same connection for both a policy file request and a main connection; close the connection after transmitting the policy file. If you do not, Flash Player closes the policy file connection before reconnecting to set up the main connection.
Protecting data
To protect data from eavesdropping and alteration as it travels over the Internet, you can use the Transport Layer Security (TLS) or Socket Layer Security (SSL) on the server where the data originates. You can then connect to the server using the HTTPS protocol. In applications created for AIR 2 or above, you can also protect TCP socket communications. The SecureSocket class allows you to initiate a socket connection to a socket server that uses TLS version 1or SSL version 4.
Sending data
Data sending occurs when code sends data to a server or resource. Sending data is always permitted for content from a network domain. A local SWF file can send data to network addresses only if it is in the local-trusted, local-with-networking, or AIR application sandbox. For more information, see Local sandboxes. You can use the flash.net.sendToURL() function to send data to a URL. Other methods also send requests to URLs. These include loading methods, such as Loader.load() and Sound.load(), and data-loading methods, such as URLLoader.load() and URLStream.load().
Uploading and downloading files
The FileReference.upload() method starts the upload of a file selected by a user to a remote server. You must call the FileReference.browse() or FileReferenceList.browse() method before calling the FileReference.upload() method. The code that initiates the FileReference.browse() or FileReferenceList.browse() method can be called only in response to a mouse event or keyboard event. If it is called in other situations, Flash Player 10 and later throws an exception. However, a user-initiated event is not required to call these methods from the AIR application sandbox. Calling the FileReference.download() method opens a dialog box in which the user can download a file from a remote server.
Note: If your server requires user authentication, only SWF files running in a browser—that is, using the browser plug-in or ActiveX control—can provide a dialog box to prompt the user for a user name and password for authentication, and only for downloads. Flash Player does not allow uploads to a server that requires user authentication.
Uploads and downloads are not allowed if the calling SWF file is in the local-with-filesystem sandbox. By default, a SWF file may not initiate an upload to, or a download from, a server other than its own. A SWF file may upload to, or download from, a different server if that server provides a policy file that grants permission to the domain of the invoking SWF file.
=================================
=================================
=================================
출처: http://ddongkang.tistory.com/89
Front - End 개발을 하다 보면 Flash player의 보안 범위를 판단하지 못해 곤란한 일을 겪은 일이 있을것이다. Flash 개발자의 경우에는 미쳐 알지 못한 내부 보안 설정을 하지 않아서 데이터를 못불러 온다거나, 바뀐 Flash player 보안 정책 때문에 고생을 했을 수도 있고, UI개발자의 경우에는 Flash 개발자가 없는 상태에서 여러 상황을 판단을 해야 하지만 Flash player의 보안 규칙에 대해 알지 못해서 혼란 스러운 경우가 있을 것이다. 이 문서는 모든 Flash 개발자와 UI개발자가 알아야 할 Flash player의 보안에 대해 기초적인 내용을 다룰 것이다.
Flash player 보안 개요
Flash player의 보안은 Flash, Flex 로 만들어진 SWF 파일이 발생 시킬 수 있는 보안 이슈에 대해 정의 및 제한 하고 있다. 텍스트 파일이나 이미지, 오디오 파일들을 로드 하거나 SWF 사이에 크로스 스크립팅을 할때 발생 할 수 있는 이슈들이 모두 여기에 포함 되어 있다. 예를 들어 SWF에서 http://www.ddongkang.com 에 존재 하는 http://www.ddongkang.com/data.xml 을 로드 한다고 할때, http://www.ddongkang.com 도메인에 crossdomain.xml 파일이 없다면 SecurityError를 발생시킨다. Flash player의 보안은 위와 같은 문제에 대해 Flash player 구현상으로 올바른 접근법을 제시 하고 있다.
기본적으로 다음과 같은 보안 규칙이 적용 된다.
동일한 보안 샌드 박스의 리소스를 항상 서로 접근(Excess) 할 수 있다.
원격 샌드박스의 SWF파일에서는 로컬 파일과 데이터에 접근 할 수 없다.
보안 샌드 박스 타입
Actionscript는 Flashplayer가 로드하는(열거나, 불러온 파일 포함) 모든 SWF파일에 보안 샌드박스 타입이라 불리는 보안 상태를 할당한다. Flashplayer는 아래와 같이 4가지 경우의 보안 샌드 박스 타입이 존재 한다.
remote 샌드박스 - Flash Player는 인터넷의 SWF 파일을 포함하여 에셋을 해당 웹 사이트의 원래 도메인에 해당하는 별도의 샌드박스에 분류한다. 기본적으로 이러한 파일은 해당 서버의 모든 리소스에 대한 액세스가 허용된다. 원격 SWF 파일은 URL 정책 파일 및 Security.allowDomain() 메서드와 같은 명시적인 웹 사이트 및 제작자 권한을 사용하여 다른 도메인의 데이터에 추가로 액세스할 수 있다.
local-with-filesystem 샌드박스 - 보안을 위해 Flash Player는 기본적으로 모든 로컬 SWF 파일을 local-with-file-system 샌드박스를 적용한다. 이 샌드박스에서 SWF 파일은 URLLoader 클래스 등을 사용하여 로컬 파일을 읽을 수 있지만, 네트워크와는 어떤 방식으로도 통신할 수 없다.
local-with-networking 샌드박스 - SWF 파일을 컴파일할 때, 로컬 파일로 실행되지만 네트워크 액세스가 가능하도록 지정할 수 있다. 이러한 파일은 local-with-networking 샌드박스가 적용 된다. local-with-networking 샌드박스에 할당된 SWF 파일에서는 해당 로컬 파일에 액세스할 수 없다. 대신, SWF 파일은 네트워크의 데이터에 액세스할 수 있다. 하지만 URL 정책 파일이나
Security.allowDomain()
메서드에 대한 호출을 통해 권한이 부여되지 않는 한 local-with-networking SWF 파일은 여전히 네트워크의 데이터를 읽을 수 없다. 이러한 권한을 부여하려면 URL 정책 파일에서
<allow-access-from domain="*"/>
또는
Security.allowDomain("*")
을 사용하여 모든 도메인에 권한을 부여해야 한다.
local-trusted 샌드박스 - 사용자나 설치 프로그램에 의해 신뢰할 수 있는 파일로 등록된 로컬 SWF 파일은 local-trusted 샌드박스에 배치된다. 시스템 관리자와 사용자는 보안 고려 사항에 따라 local-trusted 샌드박스에 또는 해당 샌드박스로부터 로컬 SWF 파일을 재할당하거나 이동할 수도 있다. local-trusted 샌드박스에 할당된 SWF 파일은 다른 SWF 파일과 상호 작용하고 원격이나 로컬의 모든 위치에서 데이터를 로드할 수 있다.
각각의 보안 샌드 박스 타입은 종류에 따라 Flashplayer의 보안 수행 범위가 정해 진다. 다음은 모든 보안 샌드 박스 타입에서 금지 할 가능성이 수도 외부 작업 들이다.
데이터 불러오기
데이터에 접근하기
크로스 스크립팅
외부 URL에 데이터 보내기
사용자의 카메라와 마이크로폰에 접근하기
로컬 공유 객체에 접근하기
사용자가 선택한 파일 업로드 또는 다운로드
.swf 파일에서의 HTML (javascript) 페이지 스크립팅과 그 반대 작업
LocalConnection 채널에 연결하기
보안 샌드 박스 타입이 할당 되는 방법
.SWF 파일의 보안 샌드박스 타입을 결정하기 위해 액션스크립트는먼저 .SWF 파일을 불러오거나 연 위치를 고려한다. 원격 샌드 박스(주로 웹에서 구동되는 SWF)는 remote 샌드박스가 적용되고, 컴파일러 설정, 환경 설정 파일등 로컬에서 구동되는 SWF 컨텐츠는 local-with-filesystem, local-with-networking, local-trusted 샌드박스에서 선택하여 작업 해야 한다.(각각 보안 기준이 다르다)
UI개발시 고려해야 할 Flash player의 보안
주로 UI개발시 고려해야 하는 상황은 웹이기 떄문에 remote 샌드박스를 고려 하면 된다. 아래 4가지 경우는 UI개발과 Flash개발 사이에 발생 할 수 있는 보안 이슈들이다.
1. SWF에서 외부 파일 로드 (이미지,오디오,텍스트파일 등등)
아무런 통신을 안하는 SWF에 대해서는 이러한 보안 이슈에 대해 주의해야 할 점들이 없지만, 대부분은 SWF들은 데이터를 불러오는 작업을 한다. SWF안에서 좀 더 깔끔한 폰트 처리를 위해서 font.swf를 로드 한다거나, 외부 데이터 파일을 불러와서 뿌려줘야 되는 경우가 종종 발생한다. 이때 font.swf 파일이나, data.xml 파일이 메인이 되는 SWF와 같은 도메인에 있다면 따로 보안 설정을 안해줘도 되지만, 다른 도메인에 존재 할 경우에는 설정을 해 줘야 한다. 좀 더 쉬운 상황 설명을 위해 로딩의 주체가 되는 SWF 파일을 main.swf , 로드 되어 지는 파일인 폰트 파일을 font.swf, 로드 되어 지는 데이터 파일을 data.xml 이라고 하자.
상황 1 .3개의 SWF파일들은 모두 http://www.ddongkang.com/flash/ 폴더안에 존재 하고 main.swf 에서 font.swf 와 data.xml 를 로드 하는 경우
모두 같은 폴더에 존재 하기 때문에 따로 보안 설정을 해줄 필요가 없다.
상황 2 .main.swf 파일은 http://www.ddongkang.com/flash/ 폴더에 존재 하고, font.swf 와 data.xml 은 http://www.daum.net/flash/data/ 에 존재 하는 경우
주체가 되는 main.swf 와 로드 되어 지는 데이터가 도메인에 존재 하기 때문에 Flash player의 보안에 막히게 된다. main.swf 에서 font.swf 와 data.xml 을 로드 하기 전에 main.swf 는 데이터가 존재 하는 http://www.daum.net 에 크로스 도메인 파일(정책파일)이 존재 하는지 확인 하고 그 설정이 맞는다면 로드를 하게 된다. (따로 확인 하지 않아도 Flash에서 Load 를 하게 되면 crossdomain.xml 파일을 로드 한다. 크로스 도메인 파일의 이름을 바꿔서 로드 하고 싶은 경우 Security.loadPolicyFile("파일URL"); 을 로드 하기 전에 호출 하면 된다. 주의 해야 할 점은 crossdomain.xml 파일의 위치이다. main.swf 가 data.xml의 로드를 시작 하면 Flashplayer에서는 우선 data.xml 파일이 존재 하는 폴더에서 crossdomain.xml 파일이 존재 하는지 확인 한다. 존재하면 바로 확인이 되어 로드를 하겠지만, 존재 하지 않는다면 상위 폴더에 crossdomain.xml 파일이 존재 하는지 확인하게 된다. 처음에 flash/data/ 폴더를 확인 하고 없으면 flash/ 폴더를 확인한다. crossdomain.xml(정책 파일)이 계속 존재 하지 않는다면 계속 상위 폴더에서 확인하고 결국엔 서버의 루트까지 확인하게 된다. 위의 예제에서는 http://www.daum.net 이 루트이다. 루트에도 crossdomain.xml(정책파일)이 존재 하지 않으면 Flashplayer는 로드를 못하게 되고 보안 에러를 발생 시키게 된다. 그러므로 상황에 따라 crossdomain.xml 파일의 위치를 잘 판단하여 업로드 해야 한다.
상황 3 .이미지 오디오 파일 로드
이미지 파일이나 오디오 파일을 로드 할때도 crossdomain.xml(정책파일)이 필요 하다. 하지만 정책 파일이 있더라도 Actionscript에서 보안 설정을 안해주면 이미지 파일의 크기를 조작하거나, 오디오 파일을 불러와서 조작 할 수 없다. 이미지를 조작할때 이러한 문제가 자주 발생하는데, 보안 설정을 안해주고 이미지의 크기가 변하지 않는 다고 이상하게 생각했던 경험을 가지고 있는 사람들이 많이 있을것이다. Flash 상에서 이미지를 로드 하는 것은 결국에는 Flash player에서 이미지를 BitmapData 로 가지고 있는 것이기 때문에 다음과 같은 설정을 해줘야만 로드된 이미지의 BitmapData에 접근할 수 있어서 이미지 크기 조작과 같은 동작이 가능하다.
LoaderContext 설정 방법 소스
// 정책파일이 기본 위치에 없다면 Security.loadPolicyFile("정책파일의위치"); var loadcontext:LoaderContext = new LoaderContext(); loadcontext.checkPolicyFile = true; var loader:Loader = new Loader(); loader.load(new URLRequest("이미지 URL"),loadcontext);
사운드의 경우도 마찬가지로 다음과 같은 설정을 해줘야 한다.
SoundLoaderContext 설정 방법 소스
// 정책파일이 기본 위치에 없다면 Security.loadPolicyFile("정책파일의위치"); var soundcontext:SoundLoaderContext = new SoundLoaderContext(); soundcontext.checkPolicyFile = true; var sloader:Sound = new Sound(); sloader.load(new URLRequest("오디오 URL"),soundcontext);
crossdomain.xml (정책 파일)
위의 정책파일은 www.ddongkang.com 과 ddongkang.com 에 대해 접근 허락을 나타내고 있다. 더 자세한 정책 파일 옵션은 웹 사이트 컨트롤(정책파일) 에서 확인할 수 있다.
2. SWF에서 HTML 브라우져 객체의 접근
AS3.0의 통신 - 브라우저와의 통신 에서 다뤘듯이 SWF는 자신을 가지고 있는 HTML객체와 통신을 할 수 있다. SWF를 HTML에 Embed 할때 allowScriptAccess매개변수를 설정하는데, 이 매개변수는 SWF파일 내에서 HTML에 있는 객체를 접근하는 것에 대한 기능을 제어한다.
allowSCriptAccess는 "always","sameDomain","never" 값중 하나를 가질 수 있다.
allowScriptAccess="always" : SWF파일은 HTML 페이지와 다른 도메인에 있는 경우에도 SWF파일이 포함된 HTML페이지와 통신 할 수 있다.
allowScriptAccess="sameDomain" : SWF파일은 HTML 페이지와 동일한 도메인에 속해 있는 경우에만 SWF파일이 포함된 HTML 페이지와 통신할 수 있다.
allowScriptAccess="never" : SWF파일에서 어떠한 HTML페이지와도 통신 할 수 없다.
allowScriptAccess에 따라 ExternalInterface.call 을 이용하여 HTML 에 있는 javascript 함수를 자유롭게 호출 할 수 있다. 하지만, HTML 객체에서 SWF 객체에 접근 할 때는 SWF 내부의 보안 정책이 필요 하다. javascript에서 아무런 제약 없이 SWF에 있는 모든 객체들에 접근 할 수 있다면, 심각한 보안 문제가 발생할 것이다.
상황 1. 같은 도메인에 HTML과 SWF파일이 존재 하는 경우(html파일이 swf파일을 포함할때)
같은 도메인에 존재 하기 때문에 따로 보안 설정을 안해줘도 된다. 예를 들어 http://www.ddongkang.com/html/ 폴더에 index.html이 있고 http://www.ddongkang/html/flash/ 에 swf파일이 존재할 경우 HTML에서 SWF에 존재 하는 객체에 제한 없이 접근 할 수 있다.
상황 2. 다른 도메인에 HTML과 SWF파일이 존재 하는 경우(html파일이 swf파일을 포함할때)
index.html 파일이 http://www.daum.net/html/ 폴더에 있고, movie.swf파일이 http://www.ddongkang.com/html/flash 폴더에 있을 경우 movie.swf파일에서 반드시 Security.allowDomain("http://www.daum.net/html/"); 해줘야 index.html 파일에서 movie.swf 에 있는 객체로 접근이 가능해 진다. AS3.0의 통신 - 브라우저와의 통신 에서 다뤘듯이 ExternalInterface.addCallback 을 이용하여 html 에서 swf에 있는 메소드를 실행 하는 것이 이 경우에 해당 한다.
3. 크로스 스크립팅
AS3.0 부터는 서로 다른 SWF 간에 크로스 스크립팅이 가능하다. 크로스스크립팅이란, 아래 그림과 같이 swfA.swf 에서 swfB.swf 를 로드 했을 경우 swfA.swf 에서 swfB.swf의 객체에 접근하여 스크립팅 하거나 swfB.swf 에서 swfA.swf로 접근하여 스크립팅 하는 것을 말합니다. 두개의 SWF파일이 같은 도메인에 있으면 따로 보안 설정을 안해줘도 되지만, 다른 도메인에 있으면 설정을 해 줘야 한다
siteA.com 에 있는 swfA.swf가 siteB.com 에 있는 swfB.swf를 로드 하여 크로스 스크립팅 하는 경우 swfB.swf 에서 Security.allowDomain("siteA.com") 를 호출해야만 swfA.swf에서 swfB.swf로의 접근이 가능하다. allowDomain으로 설정된 보안은 비대칭적이기 때문에 swfB.swf 에서는 swfA.swf 로 크로스 스크립팅을 할 수 없다. swfA.swf 에서도 위와 마찬가지로 Security.allowDomain("siteB.com") 이라 해줘야 쌍방향으로 크로스 스크립팅이 가능하다. 더 자세한 내용은 Adobe Actionscript3.0 Document - Security 에서 확인 할 수 있다.
이 문서에서는 Flash player의 보안중 극히 일부분만을 다루었다. 그 만큼 방대한 보안 설정이 존재 하고 때에 따라 보안 규약을 맞춰서 작업해야 발생할 가능성이 있는 보안 취약점들은 미리 파악하여 대처 할 수 있다. 지금 까지 나온 다양한 이슈들에 대해 Adobe Flash Developer Center - Security 에서 다루고 있으니 참고하라.
웹 서버의 데이터를 다른 도메인의 SWF 파일에서 사용할 수 있도록 하기 위해 사용자 서버에 정책 파일을 작성할 수 있습니다. 정책 파일은 사용자 서버의 특정 위치에 배치되는 XML 파일입니다.
정책 파일은 다음을 포함하여 많은 에셋에 대한 액세스에 영향을 줍니다.
비트맵, 사운드 및 비디오 데이터
XML 및 텍스트 파일 로드
다른 보안 도메인의 SWF 파일을 로드하는 SWF 파일의 보안 도메인으로 가져오기
소켓 및 XML 소켓 연결에 대한 액세스
ActionScript 객체는 문서 기반 서버 연결 및 소켓 연결의 서로 다른 두 종류의 서버 연결을 인스턴스화합니다. Loader, Sound, URLLoader 및 URLStream과 같은 ActionScript 객체는 문서 기반 연결을 인스턴스화하며 이러한 객체는 URL에서 파일을 로드합니다. ActionScript Socket 및 XMLSocket 객체는 소켓 연결을 만들어 로드된 문서가 아니라 스트리밍 데이터로 작업합니다.
Flash Player에서는 두 종류의 서버 연결을 지원하기 때문에 URL 정책 파일과 소켓 정책 파일의 두 가지 정책 파일 유형이 있습니다.
문서 기반 연결에는 URL 정책 파일이 필요합니다. 이러한 파일을 통해 서버는 특정 도메인이나 모든 도메인에서 제공된 SWF 파일에 해당 데이터와 문서를 사용할 수 있음을 나타낼 수 있습니다.
소켓 연결에는 Socket 및 XMLSocket 클래스를 사용하여 하위 TCP 소켓 수준에서 직접 네트워킹을 가능하게 하는 소켓 정책 파일이 필요합니다.
Flash Player에서는 정책 파일을 전송할 때 연결 시도에서 사용하려는 프로토콜과 동일한 프로토콜을 사용해야 합니다. 예를 들어, 정책 파일이 HTTP 서버에 있는 경우 다른 도메인의 SWF 파일은 HTTP 서버로 데이터를 로드할 수 있습니다. 하지만 동일한 서버에 소켓 파일을 제공하지 않으면 다른 도메인의 SWF 파일에서 소켓 수준의 서버에 연결할 수 없게 됩니다. 즉, 정책 파일을 가져올 때는 연결할 때와 같은 방법을 사용해야 합니다.
정책 파일 사용 및 구문은 Flash Player 10용으로 제작된 SWF 파일에 적용되기 때문에 이 단원의 나머지 부분에서 간략하게 설명합니다. 연속 릴리스에서 Flash Player 보안이 강화되었으므로 정책 파일 구현은 이전 버전의 Flash Player와 약간 다릅니다. 정책 파일에 대한 자세한 내용은 www.adobe.com/go/devnet_security_kr에서 Flash Player 개발자 센터 항목 "Flash Player 9의 정책 파일 변경 내용"을 참조하십시오.
마스터 정책 파일
기본적으로 Flash Player와 AIR 응용 프로그램 샌드박스에 있지 않은 AIR 내용은 먼저 서버의 루트 디렉토리에서
crossdomain.xml
이라는 URL 정책 파일을 찾고 포트 843에서 소켓 정책 파일을 찾습니다. 이러한 위치 중 하나에 있는 파일을 마스터 정책 파일이라고 합니다. 소켓 연결의 경우 Flash Player는 기본 연결과 동일한 포트에서 소켓 정책 파일을 찾습니다. 그러나 해당 포트에 있는 정책 파일은 마스터 정책 파일로 간주되지 않습니다.
액세스 권한을 지정하는 것 외에도 마스터 정책 파일에는 메타 정책 문이 포함될 수 있습니다. 메타 정책은 정책 파일이 포함될 수 있는 위치를 지정합니다. URL 정책 파일에 대한 기본 메타 정책은 "master-only"이므로 서버에서 허용되는 정책 파일은 /crossdomain.xml뿐입니다. 소켓 정책 파일에 대한 기본 메타 정책은 "all"이므로 호스트의 모든 소켓에서 소켓 정책 파일을 제공할 수 있습니다.
참고: Flash Player 9 이전 버전에서 URL 정책 파일에 대한 기본 메타 정책은 "all"이었으므로 모든 디렉토리에 정책 파일이 포함될 수 있습니다. 기본 /crossdomain.xml 파일이 아닌 위치에서 정책 파일을 로드하는 응용 프로그램을 배포했으며 해당 응용 프로그램이 현재 Flash Player 10에서 실행 중일 수 있는 경우 사용자(또는 서버 관리자)가 추가 정책 파일을 허용하도록 마스터 정책 파일을 수정해야 합니다. 다른 메타 정책을 지정하는 방법에 대한 자세한 내용은www.adobe.com/go/devnet_security_kr에서 Flash Player 개발자 센터 항목 "Flash Player 9의 정책 파일 변경 내용"을 참조하십시오.
SWF 파일에서
Security.loadPolicyFile()
메서드를 호출하여 다른 정책 파일 이름이나 다른 디렉토리 위치를 확인할 수 있습니다. 그러나 대상 위치에서 정책 파일을 제공할 수 있도록 마스터 정책 파일에 지정되어 있지 않으면 해당 위치에 정책 파일이 있는 경우에도
loadPolicyFile()
호출 시 아무 영향도 주지 않습니다. 정책 파일이 필요한 네트워크 작업을 시도하기 전에
loadPolicyFile()
을 호출합니다. Flash Player는 자동으로 네트워킹 요청을 해당 정책 파일 시도 뒤에 대기열에 보관합니다. 따라서 예를 들어 네트워킹 작업을 시작하기 직전에
Security.loadPolicyFile()
을 호출할 수 있습니다.
마스터 정책 파일을 확인할 때 Flash Player는 3초 동안 서버 응답을 기다립니다. 응답이 수신되지 않으면 Flash Player는 마스터 정책 파일이 없다고 가정합니다. 그러나
loadPolicyFile()
호출에 대한 기본 제한 시간 값은 없습니다. Flash Player는 호출되는 파일이 있다고 가정하고 파일을 로드하는 데 필요한 시간 동안 기다립니다. 따라서 마스터 정책 파일이 로드되도록 하려면
loadPolicyFile()
을 사용하여 명시적으로 파일을 호출합니다.
메서드에
Security.loadPolicyFile()
이란 이름이 지정된 경우에도 정책 파일이 필요한 네트워크 호출을 실행해야 정책 파일이 로드됩니다.
loadPolicyFile()
호출은 단순히 정책 파일이 필요할 때 찾을 위치를 Flash Player에 알리는 기능만 합니다.
정책 파일 요청이 시작 또는 완료된 시기에 대한 알림은 받을 수 없으며 알림을 받을 이유도 없습니다. Flash Player는 비동기적으로 정책을 확인하며, 정책 파일 확인이 성공한 후 자동으로 연결을 시작합니다.
다음 단원에는 URL 정책 파일에만 적용되는 정보가 포함되어 있습니다. 소켓 정책 파일에 대한 자세한 내용은 소켓 연결을 참조하십시오.
URL 정책 파일 범위
URL 정책 파일은 정책 파일이 로드되어 있는 디렉토리와 해당 하위 디렉토리에만 적용됩니다. 루트 디렉토리에 있는 정책 파일은 전체 서버에 적용되고, 임의의 하위 디렉토리에서 로드된 정책 파일은 해당 디렉토리와 하위 디렉토리에만 적용됩니다.
정책 파일은 해당 파일이 상주하는 특정 서버에 대한 액세스에만 영향을 줍니다. 예를 들어, https://www.adobe.com:8080/crossdomain.xml에 있는 정책 파일은 HTTPS를 통해 www.adobe.com의 8080 포트에 대한 데이터 로드 호출에만 적용됩니다.
URL 정책 파일에 액세스 권한 지정
정책 파일에는 하나의 <cross-domain-policy> 태그가 있습니다. 그리고 이 태그에는 0개 이상의 <allow-access-from> 태그가 포함됩니다. 각 <allow-access-from> 태그에는 domain이라는 속성이 있습니다. 이 속성은 정확한 IP 주소, 정확한 도메인 또는 와일드카드 도메인(임의의 도메인)을 지정합니다. 와일드카드 도메인은 다음 두 가지 방법 중 하나로 표시됩니다.
모든 도메인과 IP 주소를 나타내는 경우 단일 별표(*)
특정 접미어로 끝나는 도메인을 나타내는 경우 접미어가 뒤에 붙은 별표
접미어는 점으로 시작해야 합니다. 그러나, 접미어를 가진 별표 문자는 앞의 점을 제외한 접미어만으로 구성되는 도메인과 일치할 수 있습니다. 예를 들어, xyz.com은 *.xyz.com에 속하는 것으로 간주됩니다. IP 도메인 형식에는 와일드카드를 사용할 수 없습니다.
다음 예제에서는 *.example.com, www.friendOfExample.com 및 192.0.34.166에서 시작되는 SWF 파일에 대한 액세스를 허용하는 URL 정책 파일을 보여 줍니다.
IP 주소를 지정하면 IP 구문(예: http://65.57.83.12/flashmovie.swf)을 사용하여 해당 IP 주소에서 로드된 SWF에만 액세스 권한이 부여됩니다. 도메인 이름 구문을 사용하여 로드된 SWF에는 액세스 권한이 부여되지 않습니다. Flash Player는 DSN 이름 확인을 수행하지 않습니다.
입니다. 정책 파일이 HTTPS 서버에 있을 경우 HTTPS가 아닌 서버의 SWF 파일이 HTTPS 서버에서 데이터를 로드할 수 있도록 허용하려면 이 속성을
false
로 설정합니다.
secure
속성을
false
로 설정하면 HTTPS에서 제공하는 보안 기능이 손상될 수 있습니다. 특히 이 속성을
false
로 설정하면 보안 내용이 열려서 스누핑(snooping) 및 스푸핑(spoofing) 공격에 취약해집니다. 따라서
secure
속성을
false
로 설정하지 않아야 합니다.
로드할 데이터가 HTTPS 서버에 있고, 해당 데이터를 로드하는 SWF 파일이 HTTP 서버에 있는 경우에는 로드하는 SWF 파일을 HTTPS 서버로 이동하여 HTTPS의 보호를 받아 보안 데이터의 모든 복사본을 보관하는 것이 좋습니다. 그러나 로드하는 SWF 파일을 HTTP 서버에 두기로 결정한 경우에는 다음 코드에 표시된 대로
액세스를 허용하는 데 사용할 수 있는 다른 요소는 allow-http-request-headers-from 태그입니다. 이 요소는 다른 권한 도메인의 내용을 호스팅하는 클라이언트가 사용자 정의 머리글을 사용자 도메인으로 보낼 수 있도록 허용합니다. <allow-access-from> 태그는 사용자 도메인에서 데이터를 가져오는 권한을 다른 도메인에 부여하는 반면, allow-http-request-headers-from 태그는 사용자 도메인에 머리글 형태로 데이터를 밀어넣는 권한을 다른 도메인에 부여합니다. 다음 예제에서는 모든 도메인이 현재 도메인에 SOAPAction 머리글을 보낼 수 있습니다.
문이 마스터 정책 파일에 있으면 호스트에 있는 모든 디렉토리에 적용됩니다. 그렇지 않으면 해당 문이 포함된 정책 파일의 디렉토리와 하위 디렉토리에만 적용됩니다.
정책 파일 미리 로드
서버에서 데이터를 로드하거나 소켓에 연결하는 작업은 비동기 작업입니다. Flash Player는 기본 작업을 시작하기 전에 정책 파일의 다운로드가 완료될 때까지 기다립니다. 그러나 이미지에서 픽셀 데이터를 추출하거나 사운드에서 샘플 데이터를 추출하는 작업은 동기 작업입니다. 데이터를 추출하려면 먼저 정책 파일이 로드되어야 합니다. 미디어를 로드하는 경우에는 다음과 같이 미디어에서 정책 파일을 확인하도록 지정합니다.
웹 서버의 데이터를 다른 도메인의 SWF 파일에서 사용할 수 있도록 하기 위해 사용자 서버에 정책 파일을 작성할 수 있습니다. 정책 파일은 사용자 서버의 특정 위치에 배치되는 XML 파일입니다.
정책 파일은 다음을 포함하여 많은 에셋에 대한 액세스에 영향을 줍니다.
비트맵, 사운드 및 비디오 데이터
XML 및 텍스트 파일 로드
다른 보안 도메인의 SWF 파일을 로드하는 SWF 파일의 보안 도메인으로 가져오기
소켓 및 XML 소켓 연결에 대한 액세스
ActionScript 객체는 문서 기반 서버 연결 및 소켓 연결의 서로 다른 두 종류의 서버 연결을 인스턴스화합니다. Loader, Sound, URLLoader 및 URLStream과 같은 ActionScript 객체는 문서 기반 연결을 인스턴스화하며 이러한 객체는 URL에서 파일을 로드합니다. ActionScript Socket 및 XMLSocket 객체는 소켓 연결을 만들어 로드된 문서가 아니라 스트리밍 데이터로 작업합니다.
Flash Player에서는 두 종류의 서버 연결을 지원하기 때문에 URL 정책 파일과 소켓 정책 파일의 두 가지 정책 파일 유형이 있습니다.
문서 기반 연결에는 URL 정책 파일이 필요합니다. 이러한 파일을 통해 서버는 특정 도메인이나 모든 도메인에서 제공된 SWF 파일에 해당 데이터와 문서를 사용할 수 있음을 나타낼 수 있습니다.
소켓 연결에는 Socket 및 XMLSocket 클래스를 사용하여 하위 TCP 소켓 수준에서 직접 네트워킹을 가능하게 하는 소켓 정책 파일이 필요합니다.
Flash Player에서는 정책 파일을 전송할 때 연결 시도에서 사용하려는 프로토콜과 동일한 프로토콜을 사용해야 합니다. 예를 들어, 정책 파일이 HTTP 서버에 있는 경우 다른 도메인의 SWF 파일은 HTTP 서버로 데이터를 로드할 수 있습니다. 하지만 동일한 서버에 소켓 파일을 제공하지 않으면 다른 도메인의 SWF 파일에서 소켓 수준의 서버에 연결할 수 없게 됩니다. 즉, 정책 파일을 가져올 때는 연결할 때와 같은 방법을 사용해야 합니다.
정책 파일 사용 및 구문은 Flash Player 10용으로 제작된 SWF 파일에 적용되기 때문에 이 단원의 나머지 부분에서 간략하게 설명합니다. 연속 릴리스에서 Flash Player 보안이 강화되었으므로 정책 파일 구현은 이전 버전의 Flash Player와 약간 다릅니다. 정책 파일에 대한 자세한 내용은 www.adobe.com/go/devnet_security_kr에서 Flash Player 개발자 센터 항목 "Flash Player 9의 정책 파일 변경 내용"을 참조하십시오.
마스터 정책 파일
기본적으로 Flash Player와 AIR 응용 프로그램 샌드박스에 있지 않은 AIR 내용은 먼저 서버의 루트 디렉토리에서
crossdomain.xml
이라는 URL 정책 파일을 찾고 포트 843에서 소켓 정책 파일을 찾습니다. 이러한 위치 중 하나에 있는 파일을 마스터 정책 파일이라고 합니다. 소켓 연결의 경우 Flash Player는 기본 연결과 동일한 포트에서 소켓 정책 파일을 찾습니다. 그러나 해당 포트에 있는 정책 파일은 마스터 정책 파일로 간주되지 않습니다.
액세스 권한을 지정하는 것 외에도 마스터 정책 파일에는 메타 정책 문이 포함될 수 있습니다. 메타 정책은 정책 파일이 포함될 수 있는 위치를 지정합니다. URL 정책 파일에 대한 기본 메타 정책은 "master-only"이므로 서버에서 허용되는 정책 파일은 /crossdomain.xml뿐입니다. 소켓 정책 파일에 대한 기본 메타 정책은 "all"이므로 호스트의 모든 소켓에서 소켓 정책 파일을 제공할 수 있습니다.
참고: Flash Player 9 이전 버전에서 URL 정책 파일에 대한 기본 메타 정책은 "all"이었으므로 모든 디렉토리에 정책 파일이 포함될 수 있습니다. 기본 /crossdomain.xml 파일이 아닌 위치에서 정책 파일을 로드하는 응용 프로그램을 배포했으며 해당 응용 프로그램이 현재 Flash Player 10에서 실행 중일 수 있는 경우 사용자(또는 서버 관리자)가 추가 정책 파일을 허용하도록 마스터 정책 파일을 수정해야 합니다. 다른 메타 정책을 지정하는 방법에 대한 자세한 내용은www.adobe.com/go/devnet_security_kr에서 Flash Player 개발자 센터 항목 "Flash Player 9의 정책 파일 변경 내용"을 참조하십시오.
SWF 파일에서
Security.loadPolicyFile()
메서드를 호출하여 다른 정책 파일 이름이나 다른 디렉토리 위치를 확인할 수 있습니다. 그러나 대상 위치에서 정책 파일을 제공할 수 있도록 마스터 정책 파일에 지정되어 있지 않으면 해당 위치에 정책 파일이 있는 경우에도
loadPolicyFile()
호출 시 아무 영향도 주지 않습니다. 정책 파일이 필요한 네트워크 작업을 시도하기 전에
loadPolicyFile()
을 호출합니다. Flash Player는 자동으로 네트워킹 요청을 해당 정책 파일 시도 뒤에 대기열에 보관합니다. 따라서 예를 들어 네트워킹 작업을 시작하기 직전에
Security.loadPolicyFile()
을 호출할 수 있습니다.
마스터 정책 파일을 확인할 때 Flash Player는 3초 동안 서버 응답을 기다립니다. 응답이 수신되지 않으면 Flash Player는 마스터 정책 파일이 없다고 가정합니다. 그러나
loadPolicyFile()
호출에 대한 기본 제한 시간 값은 없습니다. Flash Player는 호출되는 파일이 있다고 가정하고 파일을 로드하는 데 필요한 시간 동안 기다립니다. 따라서 마스터 정책 파일이 로드되도록 하려면
loadPolicyFile()
을 사용하여 명시적으로 파일을 호출합니다.
메서드에
Security.loadPolicyFile()
이란 이름이 지정된 경우에도 정책 파일이 필요한 네트워크 호출을 실행해야 정책 파일이 로드됩니다.
loadPolicyFile()
호출은 단순히 정책 파일이 필요할 때 찾을 위치를 Flash Player에 알리는 기능만 합니다.
정책 파일 요청이 시작 또는 완료된 시기에 대한 알림은 받을 수 없으며 알림을 받을 이유도 없습니다. Flash Player는 비동기적으로 정책을 확인하며, 정책 파일 확인이 성공한 후 자동으로 연결을 시작합니다.
다음 단원에는 URL 정책 파일에만 적용되는 정보가 포함되어 있습니다. 소켓 정책 파일에 대한 자세한 내용은 소켓 연결을 참조하십시오.
URL 정책 파일 범위
URL 정책 파일은 정책 파일이 로드되어 있는 디렉토리와 해당 하위 디렉토리에만 적용됩니다. 루트 디렉토리에 있는 정책 파일은 전체 서버에 적용되고, 임의의 하위 디렉토리에서 로드된 정책 파일은 해당 디렉토리와 하위 디렉토리에만 적용됩니다.
정책 파일은 해당 파일이 상주하는 특정 서버에 대한 액세스에만 영향을 줍니다. 예를 들어, https://www.adobe.com:8080/crossdomain.xml에 있는 정책 파일은 HTTPS를 통해 www.adobe.com의 8080 포트에 대한 데이터 로드 호출에만 적용됩니다.
URL 정책 파일에 액세스 권한 지정
정책 파일에는 하나의 <cross-domain-policy> 태그가 있습니다. 그리고 이 태그에는 0개 이상의 <allow-access-from> 태그가 포함됩니다. 각 <allow-access-from> 태그에는 domain이라는 속성이 있습니다. 이 속성은 정확한 IP 주소, 정확한 도메인 또는 와일드카드 도메인(임의의 도메인)을 지정합니다. 와일드카드 도메인은 다음 두 가지 방법 중 하나로 표시됩니다.
모든 도메인과 IP 주소를 나타내는 경우 단일 별표(*)
특정 접미어로 끝나는 도메인을 나타내는 경우 접미어가 뒤에 붙은 별표
접미어는 점으로 시작해야 합니다. 그러나, 접미어를 가진 별표 문자는 앞의 점을 제외한 접미어만으로 구성되는 도메인과 일치할 수 있습니다. 예를 들어, xyz.com은 *.xyz.com에 속하는 것으로 간주됩니다. IP 도메인 형식에는 와일드카드를 사용할 수 없습니다.
다음 예제에서는 *.example.com, www.friendOfExample.com 및 192.0.34.166에서 시작되는 SWF 파일에 대한 액세스를 허용하는 URL 정책 파일을 보여 줍니다.
IP 주소를 지정하면 IP 구문(예: http://65.57.83.12/flashmovie.swf)을 사용하여 해당 IP 주소에서 로드된 SWF에만 액세스 권한이 부여됩니다. 도메인 이름 구문을 사용하여 로드된 SWF에는 액세스 권한이 부여되지 않습니다. Flash Player는 DSN 이름 확인을 수행하지 않습니다.
입니다. 정책 파일이 HTTPS 서버에 있을 경우 HTTPS가 아닌 서버의 SWF 파일이 HTTPS 서버에서 데이터를 로드할 수 있도록 허용하려면 이 속성을
false
로 설정합니다.
secure
속성을
false
로 설정하면 HTTPS에서 제공하는 보안 기능이 손상될 수 있습니다. 특히 이 속성을
false
로 설정하면 보안 내용이 열려서 스누핑(snooping) 및 스푸핑(spoofing) 공격에 취약해집니다. 따라서
secure
속성을
false
로 설정하지 않아야 합니다.
로드할 데이터가 HTTPS 서버에 있고, 해당 데이터를 로드하는 SWF 파일이 HTTP 서버에 있는 경우에는 로드하는 SWF 파일을 HTTPS 서버로 이동하여 HTTPS의 보호를 받아 보안 데이터의 모든 복사본을 보관하는 것이 좋습니다. 그러나 로드하는 SWF 파일을 HTTP 서버에 두기로 결정한 경우에는 다음 코드에 표시된 대로
액세스를 허용하는 데 사용할 수 있는 다른 요소는 allow-http-request-headers-from 태그입니다. 이 요소는 다른 권한 도메인의 내용을 호스팅하는 클라이언트가 사용자 정의 머리글을 사용자 도메인으로 보낼 수 있도록 허용합니다. <allow-access-from> 태그는 사용자 도메인에서 데이터를 가져오는 권한을 다른 도메인에 부여하는 반면, allow-http-request-headers-from 태그는 사용자 도메인에 머리글 형태로 데이터를 밀어넣는 권한을 다른 도메인에 부여합니다. 다음 예제에서는 모든 도메인이 현재 도메인에 SOAPAction 머리글을 보낼 수 있습니다.
문이 마스터 정책 파일에 있으면 호스트에 있는 모든 디렉토리에 적용됩니다. 그렇지 않으면 해당 문이 포함된 정책 파일의 디렉토리와 하위 디렉토리에만 적용됩니다.
정책 파일 미리 로드
서버에서 데이터를 로드하거나 소켓에 연결하는 작업은 비동기 작업입니다. Flash Player는 기본 작업을 시작하기 전에 정책 파일의 다운로드가 완료될 때까지 기다립니다. 그러나 이미지에서 픽셀 데이터를 추출하거나 사운드에서 샘플 데이터를 추출하는 작업은 동기 작업입니다. 데이터를 추출하려면 먼저 정책 파일이 로드되어야 합니다. 미디어를 로드하는 경우에는 다음과 같이 미디어에서 정책 파일을 확인하도록 지정합니다.
플래시 프로그래머
