Security changes in Flash Player 9

참고: 본 기술문서에서 의미하는 Flash Player는 Flash Player 9 Update 3 9,0,115,0 입니다.

2003년 Flash Player 7 소프트웨어는 당시 웹에서는 생소한 개념이었던 정책 파일의 승인을 통한 직접적인 크로스 도메인 데이터 로딩이라는 클라이언트-서버 통신 채널을 처음으로 도입했습니다. 정책 파일이 도입되기 전까지 웹 컨텐츠는 런타임 구성이나 페이지를 다시 로드하지 않고 트랜잭션을 수행하는 등 전용 서버와 양방향 통신만이 가능했지만, 정책 파일이 도입된 후부터는 서버에서 다른 도메인의 클라이언트 컨텐츠에 선별적으로 또는 모든 도메인의 컨텐츠에 일반적으로 자체 데이터를 공개할 수 있도록 허용되었습니다. 따라서 도메인 경계는 리치 인터넷 애플리케이션 저작자에게 더 이상 큰 골칫거리로 남는 일이 없어졌습니다.

대부분의 신기술이 그렇듯이 정책 파일도 처음 도입되었을 때는 완벽함과는 거리가 멀었습니다. 4년이 지난 현재 인터넷 보안 커뮤니티는 정책 파일 사용 시 원하지 않는 두 가지 상황이 발생한다는 사실을 발견하게 되었습니다. 이에 대해서는 본 기술문서 후반부에서 자세히 다루도록 하겠습니다. 정책 파일 사용은 해당 정책 파일이 유효하고 Flash 6 이후부터 그랬듯이 Flash 개발자가 정책 파일을 계속 사용할 수 있다는 기본적인 가정 아래 비로소 가능해집니다. Adobe는 이러한 새로운 우려를 불식시키기 위해 정책 파일 사용 시 보다 엄격한 규칙을 적용하고 있습니다. 또한 정책 파일을 보다 유용하고 간편하게 사용할 수 있도록 여러 가지 향상된 기능도 제공하고 있습니다. 본 기술문서에서는 이러한 변경 사항의 배경을 명확하고 간단하게 설명하고자 합니다.

본 기술문서는 사용자가 정책 파일에 대해 어느 정도의 지식을 보유하고 있다는 가정 하에 기술되었습니다. 정책 파일에 대한 자세한 내용은 Adobe LiveDocs에 있는 ActionScript 3.0 프로그래밍의 Flash Player 보안 장과 Flash Player를 위한 크로스 도메인 정책 파일 사용 권장 사항을 참조하십시오.

웹 사이트의 응답 방식

엄격한 규칙을 준수하기 위해 정책 파일을 제공하는 웹 사이트에는 몇 가지 사소한 변경 사항을 적용해야 합니다. 기본적으로 정책 파일에 관한 새로운 보안 모범 사례인 이러한 변경은 주로 사이트 자체를 보호하기 위한 목적이었습니다.

대부분의 사이트의 경우 이러한 변경 사항은 적용이 그리 까다롭지 않을 것이라 예상되지만, Adobe는 영향을 받는 사이트가 헤아릴 수 없이 많다는 점을 감안하여 두 단계에 걸쳐 Flash Player에 보다 엄격한 요구 사항을 구현하고 있습니다. Flash Player 9,0,115,0 버전부터는 1단계에서 소수의 엄격한 규칙이 즉시 적용되지만, 이 엄격한 규칙을 위반하는 경우에는 Flash Player의 디버그 버전에 경고 메시지만 표시됩니다. 한편, Flash Player의 이후 버전부터는 2단계에서 1단계에서 표시되었던 경고 메시지는 오류 메시지로 대체되고 보다 엄격한 규칙으로 전환됩니다.

따라서 웹 사이트 관리자는 다음 단계를 따를 것을 권장합니다.

1. 즉시: 엄격한 규칙의 즉각 적용 섹션을 읽은 다음 즉각적인 문제 진단 및 수정을 위한 워크플로우 단계를 수행합니다. 이 단계는 Flash Player 호환 컨텐츠 SWF 파일 를 제공하는 사이트에만 적용됩니다.
2. 시간적 여유가 있는 경우: 메타 정책 섹션을 읽은 다음 메타 정책 선택 및 구성을 위한 워크플로우 단계를 수행합니다. 이 단계는 정책 파일을 이미 제공하는 사이트에 주로 적용되지만, 정책 파일이나 SWF 파일을 제공하지 않는 사이트에 대비한 유용한 방어책이 될 수 있습니다.
3. 시간적 여유가 있는 경우: 소켓 정책 파일 섹션을 읽은 다음 소켓 정책 파일 구성을 위한 워크플로우 단계를 수행합니다. 이 단계는 소켓 정책 파일을 이미 제공하고 있는 사이트에 주로 적용되지만, 정책 파일이나 SWF 파일을 제공하지 않는 사이트에 대비한 유용한 방어책이 될 수 있습니다.

문제점 해결

엄격한 정책 파일 규칙을 적용하여 다음 두 가지 문제점이 해결되었습니다.

정책 파일 제어: 서버에서 정책 파일이 아닌 파일이 정책 파일로 사용될 수 있는 가능성이 있습니다. 예를 들어 서버에서 사용자가 파일을 업로드할 수 있도록 허용하지만 크로스 도메인 액세스를 위한 데이터는 열지 않을 경우, 사용자가 정책 파일을 의도적으로 구성하여 일반 텍스트 파일, XML 또는 HTML 파일과 같은 다른 유형의 파일이나 PNG 또는 JPEG 이미지 파일과 같은 바이너리 유형의 파일인 것처럼 가장할 수 있습니다. 이렇게 가장된 정책 파일을 업로드하는데 성공한 사용자는 이 가장된 정책 파일을 이용하는 SWF 파일을 작성하여 서버 도메인 밖에서 데이터를 로드할 수 있습니다. 마찬가지로 제한적인 권한을 가진 사이트 유지 관리자는 관리자의 바람과 달리 이 사이트에 정책 파일을 추가하거나 의도하지 않았던 정책 파일을 실수로 만들 수 있습니다. 이러한 문제는 어떤 정책 파일을 서버에 상주하도록 허용할 것인가를 결정하는 제어력과 관련된 문제입니다. 서버 관리자는 정책 파일에 대한 서버 차원의 정책 메타 정책이라고 함 을 설정할 뿐만 아니라, 서버에 상주하는 모든 정책 파일을 간편하게 검색하여 서버에 상주하는 모든 크로스 도메인 권한에 대한 감사를 수행할 수 있어야 합니다. Flash Player에서 보다 엄격해진 정책 파일 규칙은 서버 관리자가 메타 정책을 선언할 수 있도록 허용하고, 정책 파일에 대한 온전성 검사 sanity check 를 효과적으로 수행하여 정책 파일의 서식이 제대로 지정되도록 합니다.

DNS 하드닝: DNS 리바인딩으로 알려진 크로스 사이트 스크립팅 공격의 일종인 DNS 하드닝은 Flash Player뿐만 아니라 브라우저, 가상 시스템 및 기타 사용자 에이전트 프로그램을 대상으로 할 수 있습니다. DNS 리바인딩 공격은 해당 인터넷 도메인의 컨텐츠가 명확한 권한 없이 고유 도메인에 다른 리소스를 로드하거나 이와 통신하도록 허용하는 사용자 에이전트의 동일 출처 정책 same-origin policy 을 악용합니다. 고유 도메인을 제어하고 고유 DNS 서버를 실행하는 공격자는 고유 DNS 서버를 동적으로 재구성할 수 있어, 해당 도메인 이름을 공격자가 제어하는 IP 주소 악성 SWF 파일 또는 기타 컨텐츠를 제공하는 데 사용할 수도 있음 로 변경한 다음 공격자가 제어하지 않는 다른 IP 주소로 다시 변경할 수 있습니다. 사용자 에이전트 프로그램이 IP 주소가 변경된 사실을 감지하지 못하는 경우, 동일 출처 정책은 공격자의 컨텐츠가 두 번째 호스트의 승인 없이도 두 번째 IP 주소에 액세스할 수 있도록 허용하게 됩니다. Flash Player는 브라우저를 사용하여 HTTP 네트워킹을 제공하므로, HTTP에만 해당되는 모든 리바인딩 취약점은 브라우저에서 해결됩니다. 그러나 Flash Player는 ActionScript Socket 및 XMLSocket 클래스를 통한 소켓 수준의 네트워킹을 제공하고, Flash Player 9,0,115,0의 엄격한 정책 파일 규칙은 소켓과 관련된 DNS 리바인딩 취약점을 최소화시켜 줍니다. 특히 엄격한 규칙 하에서는 소켓 서버가 SWF 파일의 본래 도메인을 연결하는 서버와 동일한 경우에도 소켓 정책 파일의 승인이 있어야만 소켓을 연결할 수 있습니다. 또한 9,0,115,0 버전부터 Flash Player는 소켓 연결이 도메인 이름뿐만 아니라 IP 주소 기반의 해당 소켓 정책 파일과 일치하는지 확인합니다.

기타 향상된 기능

Adobe는 상기 문제점을 해결하는 것 외에도 정책 파일을 보다 유용하고 간편하게 사용할 수 있도록 몇 가지 새로운 기능을 추가했습니다.

• Flash Player 디버그 버전의 정책 파일 이벤트에 대한 자세한 로깅: 이러한 정책 파일을 이용하는 작업의 성패뿐만 아니라, 정책 파일 로드 및 처리에 대한 모든 성패 결과가 보고됩니다. 이러한 보고는 엄격한 규칙으로의 전환뿐만 아니라 정책 파일 배포 시 발생하는 문제점을 식별하고 해결하는 데도 도움이 됩니다.
• 고정 소켓 마스터 정책 파일 포트인 TCP 포트 843: 기본적으로 소켓 정책 파일에서 참조하는 이 포트는 이전에 사용되었던 "모든 포트 선택" 시스템이 아니라 소켓 정책 파일을 제공하는 표준 방식입니다.
• 로컬 소켓을 위한 강력한 클라이언트 인증이 필요한 옵션: localhost 소켓에서 제공된 소켓 정책 파일은 이전 HTTPS 정책 파일 전용으로 사용되었던 secure="true" 선언을 사용하여 해당 도메인의 HTTPS SWF 파일만을 연결하도록 지정할 수 있습니다. 이 방식은 온라인 Flash 컨텐츠와 기본 로컬 애플리케이션을 함께 사용하는 하이브리드 애플리케이션을 안전하게 사용하는 데 도움이 됩니다.

Flash Player 9,0,115,0의 보안 변경 사항은 대부분 개발자에게 경고 메시지의 형태로 제공되지만, 이 중 일부는 SWF 애플리케이션이 이전처럼 작동하지 않도록 하는 기능 측면의 변화로 바로 나타납니다. Adobe는 합법적 컨텐츠에서는 거의 발생하지 않을 것이라고 판단되는 비헤이비어 패턴에만 이러한 변경 사항을 적용하려고 했지만, 이러한 노력에도 불구하고 합법적 컨텐츠 중 일부가 이러한 변경 사항에 영향을 받고 있다는 점을 인지하게 되었습니다.

엄격한 규칙의 즉각 적용으로 인해 발생하는 문제점을 식별하고 수정할 수 있는 신속한 단계별 가이드는 즉각적인 문제 해결을 위한 워크플로우를 참조하십시오. 그러나 영향을 받을 수 있는 사용자(SWF 컨텐츠 책임자)는 소개 섹션을 먼저 읽어보시기 바랍니다.

잘못된 형식의 정책 파일

본 기술문서에서 설명한 기타 모든 변경 사항과 달리, Flash Player에서 잘못된 형식의 정책 파일에 적용하는 제한 사항은 9,0,47,0 버전부터 계속 적용되어 온 것으로 9,0,115,0 버전에서 새롭게 적용된 것이 아닙니다. 그러나 9,0,115,0 버전부터는 새로운 로깅 메커니즘 덕분에 이러한 제한 사항으로 인해 발생하는 문제를 한결 수월하게 식별할 수 있게 되었습니다.

현재 Flash Player는 제대로 서식이 지정되지 않은 컨텐츠가 포함된 모든 정책 파일을 거부합니다. 잘못된 서식 지정은 다음 원인에서 기인할 수 있습니다.

• 여는 <cross-domain-policy> 태그 앞 또는 닫는 </cross-domain-policy> 태그 뒤에 오는 XML 주석 및 선언 외에 선행하거나 후행하는 불필요한 컨텐츠: 이러한 유형의 불필요한 컨텐츠는 실제로 파일을 잘못된 XML 문서로 만듭니다.
• <cross-domain-policy>가 아닌 최상위 XML 태그
• 주석 외에 태그에 포함된 텍스트

Flash Player는 향상된 정책 파일 제어 기능의 일부로 잘못된 형식의 파일을 거부합니다. 정책 파일의 형식이 잘못되면 웹 사이트 관리자가 의도하지 않은 파일을 Flash Player에서 정책 파일로 사용할 수 있다고 인식할 수도 있습니다.

Adobe는 정책 파일 태그와 서식 지정을 검증하는 데 사용할 수 있는 XML 스키마 문서를 제공하고 있습니다. (이 단계는 선택 사항이므로, XML 스키마 문서에 익숙하지 않은 경우 건너뛰어도 좋습니다.) 스키마는 다음과 같이 표시됩니다.

• http://www.adobe.com/xml/schemas/PolicyFile.xsd
• http://www.adobe.com/xml/schemas/PolicyFileFtp.xsd
• http://www.adobe.com/xml/schemas/PolicyFileHttp.xsd
• http://www.adobe.com/xml/schemas/PolicyFileHttps.xsd
• http://www.adobe.com/xml/schemas/PolicyFileSocket.xsd

PolicyFile.xsd는 모든 정책 파일에 대한 일반적인 스키마이고 나머지 4개는 다양한 프로토콜에 사용되는 정책 파일 구문을 제한하는 스키마입니다.

엄격한 규칙의 즉각 적용으로 인해 발생하는 모든 문제에 대해서는 즉각적인 문제 해결을 위한 워크플로우를 수행하여 SWF 컨텐츠가 잘못된 형식의 정책 파일에 영향을 받는지 여부를 확인하십시오. 로그에 잘못된 형식의 정책 파일에 관한 보고서가 있을 경우, 해당 정책 파일을 제어하는 사람은 불필요한 컨텐츠를 삭제하거나 맞춤법 오류를 수정하는 등 해당 정책 파일을 편집해야 합니다.

도메인 내 리디렉션

정책 파일이 도입된 후 Flash Player는 정책 파일 요청 시 HTTP 서버가 다른 도메인으로의 리디렉션을 반환할 때마다 정책 파일을 무시해 왔습니다. 그러나 도메인 내 리디렉션 기능이 도입된 후부터는 정책 파일 요청이 동일한 서버의 다른 위치로 리디렉션되어도 Flash Player는 정책 파일의 유효한 위치가 정책 파일을 처음으로 요청한 URL이라고 인식하게 되었습니다. 정책 파일의 유효한 위치는 정책 파일의 범위(정책 파일이 액세스를 허용하는 일련의 리소스)를 제어한다는 점에서 매우 중요합니다. 예를 들어, http://example.com/directory1/crossdomain.xml 에 위치한 정책 파일은 http://example.com/directory1/ 에 위치한 리소스에 대한 액세스를 허용하지만 http://example.com/elsewhere/와 같이 동일한 서버의 다른 위치에 있는 리소스에 대해서는 액세스를 허용하지 않습니다. 일반적으로 Adobe는 사이트에서 효과적인 권한을 예측하는 것이 더욱 어려워지기 때문에 정책 파일에 대한 리디렉션 사용을 권장하지 않고 있습니다.

9,0,115,0 버전부터 Flash Player는 도메인 내의 리디렉션을 통해 제공되는 정책 파일을 인정하고 있지만, 리디렉션된 정책 파일의 유효한 위치로는 초기 URL이 아니라 최종 URL이 사용됩니다. 예를 들어, http://example.com/forks/crossdomain.xml 이 http://example.com/spoons/crossdomain.xml로 리디렉션된 경우 결과로 표시되는 정책 파일은 http://example.com/spoons/ 에 대한 액세스를 허용하지만 http://example.com/forks/에 대해서는 액세스를 허용하지 않습니다.

Flash Player는 향상된 정책 파일 제어 기능의 일부로 최종 리디렉션된 URL을 사용합니다. 관리자는 서버에서 일련의 정책 파일 권한을 손쉽게 결정할 수 있어야 합니다. 리디렉션된 초기 URL을 유효한 위치로 사용하는 경우, 리디렉션을 생성하면 정책 파일의 위치를 사이트 어디에서나 시뮬레이트할 수 있습니다. 그러나 Flash Player에서는 최종 URL만을 유효한 위치로 사용하므로 명확하면서도 의도된 정책 파일만을 사용할 수 있습니다. 이제 리디렉션을 사용하면 사이트의 권한을 변경하는 것이 아니라 이미 만들어진 정책 파일만 로드할 수 있게 됩니다.

리디렉션된 정책 파일이 많지 않기를 바라지만, 엄격한 규칙의 즉각 적용으로 인해 발생하는 모든 문제에 대해서는 즉각적인 문제 해결을 위한 워크플로우를 수행하여 SWF 컨텐츠가 정책 파일 리디렉션에 의해 영향을 받는지 여부를 확인하십시오. 로그에 정책 파일 리디렉션에 관한 보고서가 있을 경우, 이는 컨텐츠가 의도한 대로 작동하지 않을 것이라는 것을 의미하지는 않지만, 이전에 허용되었던 작업이 이제 허용되지 않을 수 있다는 것을 의미할 수 있습니다.

특히 /crossdomain.xml에 있는 마스터 HTTP 정책 파일 위치에 대한 요청을 리디렉션하는 것이 문제가 됩니다. 이렇게 하면 결과로 나타나는 정책 파일의 마스터로서의 지위는 박탈됩니다. 그러면 해당 사이트에서 마스터 정책 파일을 가질 수 없게 되며, 이로써 메타 정책을 선언하는 것과 같은 일반적인 작업을 수행할 수 없게 됩니다.

Content-type 허용 목록

9,0,115,0 버전부터 Flash Player는 HTTP 정책 파일이 텍스트 파일임을 보장하는 Content-Type 값과 함께 전송되지 않는 모든 HTTP 정책 파일을 무시하게 됩니다. Flash Player에서는 정책 파일의 Content-Type 값이 다음 중 하나가 되어야 합니다.

• text/* (모든 text 유형)
• application/xml 또는 application/xhtml+xml

Content-Type 값은 HTTP 서버가 제공한 응답 헤더에 의해 결정됩니다. 서버는 파일 이름, 확장명, 위치, 컨텐츠 또는 파일을 생성하는 서버 스크립트의 명령을 바탕으로 Content-Type 값을 선택할 수 있습니다. 정책 파일과 연결된 Content-Type 값을 변경해야 하는 경우 파일 이름 확장명을 Content-Type 값에 매핑하는 레지스트리를 재구성하거나 일반적인 서버 구성 파일을 편집해야 할 수 있습니다. HTTP 서버에 대한 내용은 해당 설명서를 참조하십시오.

엄격한 규칙의 즉각 적용으로 인해 발생하는 모든 문제에 대해서는 즉각적인 문제 해결을 위한 워크플로우를 수행하여 SWF 컨텐츠가 비텍스트 형식의 Content-Type 값에 의해 영향을 받는지 여부와 많이 사용되는 여러 HTTP 서버 플랫폼에서 Content-Type 값을 변경하는 방법을 확인하십시오. Content-Type 문제를 해결해야 하는 경우 모든 정책 파일에 text/x-cross-domain-policy의 특수 Content-Type 값을 지정하는 것이 메타 정책을 선택하는 일반적인 방법이므로 메타 정책 섹션을 참조하십시오. 이로써 메타 정책을 설정하고 텍스트 형식의 Content-Type 값을 제공하는 등 두 가지 문제를 동시에 해결할 수 있습니다.

Flash Player는 향상된 정책 파일 제어 기능의 일부로 텍스트 형식의 Content-Type 값을 필요로 합니다. 정책 파일에 비텍스트 형식의 Content-Type 값이 포함되면 웹 사이트 관리자가 의도하지 않은 파일을 Flash Player에서는 정책 파일로 사용할 수 있다고 인식할 수도 있습니다.

Flash Player가 브라우저에서 실행될 때 Content-Type 허용 목록을 적용할지는 브라우저의 네트워킹 스택에서 HTTL 응답 헤더를 읽을 수 있는 기능이 Flash Player에 있는지 여부에 따라 달라집니다. 최신 브라우저에서는 이 기능을 사용할 수 있지만 일부 이전 버전의 브라우저에서는 사용할 수 없습니다. HTTP 응답 헤더를 지원하거나 지원하지 않는 브라우저 목록은 부록 A를 참조하십시오. Flash Player가 HTTP 응답 헤더를 읽지 못하면 정책 파일 로그에 경고 메시지가 생성되고, 정책 파일은 해당 Content-Type 값과 상관없이 채택되고 심지어 Content-Type 값이 없는 경우에도 채택됩니다.

엄격한 소켓 규칙의 즉각 적용

9,0,115,0 버전부터 Flash Player는 소켓 정책 파일에 대해 보다 엄격해진 규칙을 적용하고 있습니다. 소켓 정책 파일은 ActionScript 언어가 소켓 서버에 연결되도록 승인합니다. 엄격한 규칙에 대해서는 소켓 정책 파일 섹션에 자세히 설명되어 있지만, 간단히 말하면 ActionScript 소켓을 연결하기 위해서는 소켓 정책 파일의 권한이 항상 필요하다는 것입니다. 이전 규칙에서는 정책 파일 없이도 고유 도메인에서 높은 번호의 포트에 소켓이 연결되도록 SWF 파일을 허용했으며, HTTP 정책 파일만을 기반으로 높은 번호의 포트에 소켓이 연결되도록 모든 SWF 파일을 허용했습니다. 그러나 엄격한 소켓 규칙 하에서는 더 이상 허용되지 않습니다.

대부분의 소켓 서버의 경우 엄격한 규칙은 두 단계에 걸쳐 적용됩니다. 1단계에서는 호스트가 새로운 규칙을 적용하도록 선택하지 않으면 규칙 위반 시 경고 메시지만 생성됩니다. 그러나 다음과 같이 일부 특수한 유형의 소켓에는 1단계에서도 엄격한 규칙이 즉시 적용됩니다.

• Flash Player가 실행되고 있는 로컬 시스템의 소켓(ActionScript에서 localhost로 인식된 소켓은 제외): 이 소켓은 loopback 주소(IPv4의 127.0.0.1, IPv6의 ::1)와 로컬로 할당된 외향(outward-facing) 주소(예: 이더넷 어댑터에 할당된 주소)에 위치한 로컬 소켓입니다. 이 규칙은 Flash Player의 향상된 DNS 하드닝 기능에 포함되어 있습니다. 엄격한 소켓 규칙을 선택하는 시스템은 서버 호스트에는 적합하지만 대부분의 사용자가 서버로 취급하지 않는 로컬 시스템에는 적합하지 않습니다. 이 규칙은 악성 DNS 서버가 (SWF 파일을 전달하기 위해) 호스트 이름을 원격 주소로 변경한 다음 (로컬 서비스에 연결하기 위해) 로컬 주소로 변경하는 것을 방지합니다. 일반적으로 localhost를 변경하는 데 원격 DNS가 관련될 가능성은 없기 때문에 특수한 이름의 localhost는 이 규칙에서 제외됩니다.
• 링크 로컬 IP 주소에 위치한 소켓(ActionScript에서 *.local(.local로 끝나는 모든 이름)로 되어 있는 소켓은 제외): 링크 로컬 IP 주소는 단일 링크(지점간 연결 또는 네트워크 허브와 같은 한 개의 네트워크 세그먼트)에만 할당된 주소입니다. 링크 로컬 주소는 "제로 구성" P2P 네트워킹으로 사용되는 경우가 많습니다. 이 링크 로컬 주소는 IPv4에서는 169.254.*의 형태로, IPv6에서는 fe80:*의 형태로 표시됩니다. 이 경우는 상기 로컬 주소와 매우 유사합니다. .local 예외는 .local 주소를 변경하는 데 원격 DNS가 관련될 가능성이 없음을 나타냅니다.
• 번호가 1024 이상인 포트의 소켓으로 고유 소켓 정책 파일을 제공하고 정책 파일 컨텐츠에 고유 도메인을 나열하지 않는 소켓: 이는 실제 별도의 규칙이 아니라 시스템에서 엄격한 소켓 규칙을 선택한 결과로 탄생된 규칙입니다. 고유 소켓 정책 파일을 제공하는 모든 소켓은 자동으로 새로운 규칙을 선택하여 적용합니다. 이전 규칙에서는 SWF 파일이 고유 도메인의 소켓에 연결될 때 정책 파일이 필요하지 않지만, 엄격한 규칙 하에서는 소켓 정책 파일이 필요합니다. 소켓에서 제공하는 소켓 정책 파일이 고유 도메인을 나열하지 않으면 동일한 도메인의 SWF 파일은 연결되지 않을 수 있습니다.

엄격한 규칙의 즉각 적용으로 인해 발생하는 모든 문제에 대해서는 즉각적인 문제 해결을 위한 워크플로우를 수행하여 SWF 컨텐츠가 엄격한 소켓 규칙의 즉각 적용에 의해 영향을 받는지 여부와 발견된 모든 문제를 해결하는 방법을 확인하십시오.

Flash Player 9,0,115,0에서 향상된 정책 파일 제어 기능과 관련해 가장 두드러지는 변경 사항은 메타 정책이 도입되었다는 점입니다. 메타 정책은 서버에 상주하도록 허용할 정책 파일을 서버 관리자가 지정하는 "정책에 대한 정책"이라고 할 수 있습니다.

서버에 대한 메타 정책 선택 시 신속한 단계별 가이드는 메타 정책을 위한 워크플로우를 참조하십시오. 그러나 서버를 유지 관리하는 담당자는 소개 섹션을 먼저 읽어볼 것을 권장합니다. 여기에는 모든 Flash Player 호환 컨텐츠를 제공하지 않는 서버뿐만 아니라 정책 파일 기반의 공격에 취약한 서버도 포함됩니다.

메타 정책이 필요한 이유

향상된 정책 파일 제어 기능 섹션에서 설명한 바와 같이, 메타 정책은 정책 파일이 적합한 승인을 통해서만 생성될 수 있도록 하는 데 그 목적이 있습니다. 그러나 메타 정책을 선택하려면 정책 파일의 역할과 승인되지 않은 정책 파일이 미치는 영향에 대해 이해하는 것이 중요합니다(그림 1 참조).

이 다이어그램에서 b.com 사이트는 a.com 사이트에 대해 권한을 부여하는 정책 파일을 호스트합니다. 이는 a.com의 SWF 파일은 정책 파일의 위치에 따라 b.com 사이트의 일부 또는 전체에서 직접 데이터를 로드할 수 있음을 의미합니다.

정책 파일은 b.com에 액세스할 때 사용자의 인증서를 사용해 작동하도록 다른 도메인의 SWF 파일에 대한 권한을 부여하기 때문에 b.com의 관리자는 정책 파일을 지정할 때 각별히 주의해야 합니다. 위의 다이어그램에서 사용자가 a.com(1)에서 SWF 파일을 찾지만, a.com의 SWF 파일이 예를 들어 c.com(그림에 포함되지 않음)과 같이 다른 사이트에 임베드되어 있을 수 있습니다. a.com의 SWF 파일은 b.com(2)에 있는 정책 파일을 사용해 b.com에서 데이터를 로드할 수 있는 권한을 획득합니다. 그러면 이 SWF 파일은 사용자가 b.com에 액세스하는 데 사용하는 모든 인증서를 이용하여 b.com(3)에서 데이터를 로드할 수 있습니다. SWF 파일은 b.com에서 찾은 모든 데이터를 a.com(4)에 있는 고유 서버로 다시 업로드할 수 있습니다.

a.com 서버가 b.com에 직접 액세스했다면 보유했을 수 있는 액세스 인증서와 사용자가 b.com에 액세스하기 위해 보유하고 있는 액세스 인증서를 서로 비교해 보는 것이 중요합니다. 사용자가 네트워크 방화벽 내에 b.com과 함께 있기 때문에 b.com에 액세스할 수 있는 경우, 또는 사용자가 로그인를 제공하고 HTTP 쿠키를 수신했기 때문에 b.com에 액세스할 수 있는 경우, 이 사용자는 a.com 서버보다 훨씬 더 많은 권한을 보유하게 됩니다. 이 경우 a.com의 SWF 파일은 b.com 사이트나 사용자 또는 모두에게 비공개된 데이터를 공개하지 않도록 신뢰할 수 있어야 하므로 b.com에 정책 파일을 생성하는 것은 위험 부담이 뒤따를 수 있습니다.

정책 파일에서 이러한 유형의 데이터 취약점을 야기할 수 있다면, 서버 관리자가 정책 파일의 생성을 제한할 수 있도록 하여 취약점 발생을 방지하고 언제든지 서버에서 모든 정책 파일을 손쉽게 찾아볼 수 있도록 하여 현재 권한에 대한 감사를 수행하는 것이 중요합니다. 서버 중에는 관리 권한이 없는 사람이 컨텐츠를 작성할 수 있도록 허용하는 서버도 있고, 최종 사용자가 정의한 컨텐츠를 제공할 수 있도록 허용하는 서버도 있습니다. 이러한 유형의 컨텐츠 작성자가 정책 파일을 생성하도록 허용하는 것은 적절치 않습니다.

이때 메타 정책을 유용하게 사용할 수 있습니다. 적합한 메타 정책을 선택함으로써 관리자는 정책 파일 생성을 완전히 금지하거나 모든 위치에서 정책 파일 생성을 완전히 허용할 수 있으며, 경우에 따라 중간자적인 접근 방식을 취할 수 있어, 기준에 상관없이 일정한 정책 파일만을 허용할 수 있습니다.

메타 정책은 Flash Player 호환 컨텐츠를 제공하지 않는 서버의 경우에도 유용합니다. b.com이 방화벽 내에 있는 HTML 전용 서버이고 누군가가 b.com에서 정책 파일을 생성했다면, b.com에 대한 액세스 권한을 가진 사용자가 a.com의 SWF 파일을 볼 때 a.com 사이트의 SWF 파일은 b.com의 데이터를 검색할 수 있습니다. 이와 같은 로직은 b.com이 인터넷 서버이지만 로그인 인증서를 채택하는 경우에도 적용됩니다. 따라서 이 서버가 모든 Flash Player 호환 컨텐츠를 제공하지 않는다 해도 메타 정책을 선언하면 b.com은 많은 이점을 얻을 수 있습니다. (이러한 서버에 적용할 수 있는 메타 정책은 none으로, 어떤 정책 파일도 이 서버에 상주할 수 없도록 할 수 있습니다.)

메타 정책의 범위

다음 유형의 서버는 메타 정책을 선언할 수 있습니다.

• HTTP 및 HTTPS 서버: 각 서버는 고유 메타 정책을 선언할 수 있으며, 다른 서버에 영향을 주지 않습니다. 예를 들어 포트 80의 HTTP 서버의 메타 정책은 해당 서버에만 영향을 주고 동일한 호스트에 있는 포트 8080의 HTTP 서버에는 영향을 주지 않습니다. 마찬가지로 HTTP 서버의 메타 정책은 동일한 호스트에 있는 HTTS 서버에는 영향을 주지 않고 그 반대도 마찬가지입니다.
• FTP 서버: 다시 한번 강조하지만, 각 서버는 고유 메타 정책을 선언할 수 있습니다.
• 전체 호스트는 모든 포트의 호스트에 대한 낮은 수준의 소켓 연결을 제어하는 소켓 메타 정책을 선언할 수 있습니다. 낮은 수준의 소켓 연결은 ActionScript Socket 및 XMLSocket 클래스를 사용해 시도된 연결입니다. Socket 및 XMLSocket 외에 모든 ActionScript API를 사용하는 HTTP 및 FTP 서버에 대한 높은 수준의 연결은 소켓 메타 정책에 의해 영향을 받지 않으며, 관련된 특정 서버의 메타 정책에 의해서만 영향을 받습니다. HTTP, HTTPS 및 FTP 메타 정책은 URL 메타 정책이라고 하여 소켓 메타 정책과 구분됩니다. 소켓 메타 정책에 대한 자세한 내용은 소켓 정책 파일 섹션을 참조하십시오.

현재로서는 위에서 설명한 유형의 서버 외의 서버에서 메타 정책을 선언하거나 정책 파일을 생성하는 것은 필요하지도 유용하지도 않습니다. 기본 Flash Player 네트워킹은 소켓 수준에서 직접 HTTP, HTTPS 및 FTP 서버에 대한 연결만을 허용합니다. SWF 파일은 소켓 수준의 연결을 이용하여 다른 유형의 서버에 연결할 수 있지만, 이 경우 Flash Player는 더 높은 수준의 프로토콜을 인식하지 않으므로 소켓 수준에서 정책 파일 점검을 수행합니다. (Flash Player는 RTMP 프로토콜을 사용하여 Flash Media Server에 연결할 수 있지만, RTMP의 경우 보안은 Flash Player가 아니라 서버를 통해 다르게 작동하면서 보안 결정을 내립니다.)

메타 정책 옵션

다음의 메타 정책이 제공됩니다.

• all: 모든 정책 파일이 허용됩니다. 이 메타 정책은 공용 인터넷에 상주하며 로그인 인증서가 필요한 컨텐츠를 제공하지 않는 서버에만 적합합니다.
• by-content-type: Content-Type이 정확하게 text/x-cross-domain-policy인 모든 정책 파일이 허용됩니다. 이외의 다른 정책 파일은 허용되지 않습니다. 이 메타 정책은 HTTP 및 HTTPS 서버에만 사용할 수 있습니다. 대부분의 HTTP 서버는 Content-Type의 지정 방식을 유연하게 결정하므로, 일부 정책 파일을 허용해야 할 때 가장 유용한 옵션입니다. text/x-cross-domain-policy 유형을 지정하는 일반적인 전략에는 개별 위치에 지정하여 각 정책 파일에 대해 관리자의 승인이 필요한 전략이 있는가 하면, 이름이 crossdomain.xml인 파일에 text/x-cross-domain-policy를 지정하여 정책 파일이 어디에나 상주하도록 허용하지만 이러한 파일을 손쉽게 찾을 수 있도록 하여 업로드 또는 기타 컨텐츠 생성 프로세스 동안 파일 필터링을 간편하게 수행할 수 있는 전략이 있습니다.
• by-ftp-filename: 이름이 crossdomain.xml(예: URL이 /crossdomain.xml로 끝나는 정책 파일)인 모든 정책 파일이 허용됩니다. 이외의 다른 정책 파일은 허용되지 않습니다. 이 메타 정책은 FTP 서버에만 사용할 수 있습니다. 필수 파일 이름은 사용자 정의할 수 없습니다.
• master-only: /crossdomain.xml에 위치한 마스터 정책 파일만이 허용됩니다.
• none: 모든 정책 파일이 허용되지 않습니다. 이 메타 정책이 마스터 정책 파일에서 선언되면 이 마스터 정책 파일은 이 메타 정책을 선언하는 용도로만 상주할 수 있도록 허용되며, 이 메타 정책에 포함된 <allow-access-from> 지시문은 무시됩니다.
• none-this-response: 이 메타 정책은 HTTP 응답 헤더에서만 지정될 수 있는 특수 메타 정책입니다. 이를 사용하면 특정 HTTP 응답이 정책 파일로 인식되지 않도록 할 수 있습니다. 기타 모든 메타 정책과 달리 none-this-response는 전체 서버에 대한 전반적인 메타 정책을 선언하지 않고 단일 HTTP 응답에만 영향을 줍니다. 또한 기타 모든 메타 정책과 달리 none-this-response는 충돌 없이 다른 모든 메타 정책과 결합될 수 있습니다. none-this-response와 또 다른 메타 정책이 모두 존재하는 경우, 현재 HTTP 응답은 정책 파일로 허용되지 않지만 추가 메타 정책이 이 서버에 대한 전반적인 메타 정책으로 인식됩니다. none-this-response 메타 정책은 주로 서버에 정책 파일을 생성하도록 허용하지 않는 스크립트가 포함된 경우 유용합니다. 일반적으로 스크립트는 출력의 Content-Type을 선택하고 임의의 HTTP 응답 헤더를 생성할 수 있으므로, 해당 출력이 적법한 정책 파일임을 나타내는 스크립트 출력을 필터링하기가 어려울 수 있습니다. 대신 none-this-response 메타 정책 헤더를 스크립트 출력에 첨부하면 스크립트가 무엇을 생성하건 상관없이 유효한 정책 파일을 생성하지 못하게 할 수 있습니다. (또한 스크립트가 고유 메타 정책 HTTP 응답 헤더를 생성하는 경우, 가장 제한적인 메타 정책을 선택하여 메타 정책 충돌 문제를 해결하므로, 서버에서 이미 지정한 메타 정책 외에 보다 개방적인 메타 정책을 채택하지 못하게 할 수 있습니다.)

메타 정책 지정 방법

HTTP, HTTPS 또는 FTP 서버에서 메타 정책을 선언하는 방법에는 다음 두 가지가 있습니다. 소켓 정책 파일은 다르게 작동합니다.

• 해당 서버의 마스터 정책 파일( /crossdomain.xml에 위치한 정책 파일)에서 메타 정책을 선언합니다. <site-control>이라는 새로운 태그는 최상위 <cross-domain-policy> 태그에 포함되어 있고, permitted-cross-domain-policies라는 <site-control> 태그의 속성은 특정 메타 정책이 사용되도록 지정합니다. 다음은 by-content-type의 메타 정책을 선언하는 정책 파일의 예입니다.

• X-Permitted-Cross-Domain-Policies라는 HTTP 응답 헤더에서 메타 정책을 선언합니다. 이 옵션은 FTP 서버에는 사용할 수 없습니다. 안정적으로 정책 파일 요청인지 여부를 판단할 수 있는 방법이 없으므로, 이 헤더가 유효하기 위해서는 모든 HTTP 응답과 함께 이 헤더를 반환해야 합니다. 다음은 none의 메타 정책을 선언하는 HTTP 응답 헤더의 예입니다.

두 개의 메타 정책을 지정해야 하는 경우(이 중 하나가 none-this-response인 경우에만 합법적임), X-Permitted-Cross-Domain-Policies 헤더를 두번 제공하거나 메타 정책에 세미콜론으로 구분한 메타 정책 값을 한번 제공해야 합니다. 두 가지 방법 모두 HTTP 헤더의 표준 사례입니다.

메타 정책을 선언하려면 이 두 가지 방법 중 한 가지만 선택해야 합니다. 그러나 실수로 메타 정책을 두 개의 위치에서 선언했다면, HTTP 응답 헤더에서 선언된 메타 정책이 마스터 정책 파일에서 선언된 메타 정책보다 우선적으로 적용됩니다.

두 가지 방법은 각각 나름대로 이점이 있습니다. 다음 경우를 고려하여 두 가지 방법 중 한 가지를 선택하십시오.

마스터 정책 파일에서 메타 정책을 선언하는 경우

• 보통 새로운 HTTP 응답 헤더를 반환하는 것보다 마스터 정책 파일을 편집하는 것이 훨씬 간편합니다.
• 마스터 정책 파일 기법은 HTTP 및 FTP 모두에 사용할 수 있습니다.
• 이 기법을 사용하면 서버에서 모든 HTTP 응답마다 헤더를 추가하지 않아도 됩니다.

HTTP 응답 헤더에서 메타 정책을 선언하는 경우

• 항상 서버의 문서 루트 디렉토리에 마스터 정책 파일을 생성할 수 있는 것은 아닙니다.
• 메타 정책이 마스터 정책 파일에서 선언되었지만 마스터가 아닌 정책 파일이 요청된 경우, Flash Player는 마스터가 아닌 정책 파일을 채택하기 전에 마스터 정책 파일을 검색해야 합니다. 그러나 메타 정책이 HTTP 응답 헤더에서 선언된 경우 마스터 정책 파일에 대한 추가 요청은 필요하지 않습니다.
• HTTP 응답 헤더에서 메타 정책을 선언하는 데 필요한 서버 구성은 제공 가능한 문서 컨텐츠를 변경하지 않고도 단일 서버 구성 파일에서 관리할 수 있습니다.
• none-this-response의 메타 정책은 정책 파일을 생성하는 스크립트 기능을 제어하기 위해 제공할 수 있습니다.

HTTP 및 HTTPS 서버에서는 HTTP 응답 헤더 또는 마스터 정책 파일에서 메타 정책을 명시적으로 선언하지 않았지만 Content-Type이 text/x-cross-domain-policy인 모든 정책 파일을 반환하면 Flash Player에서 by-content-type의 메타 정책을 채택하도록 만드는 규칙이 있다는 것을 반드시 알아둬야 합니다. 이 규칙은 이러한 상황에 부딪히게 되면 참고해야 하지만, 메타 정책을 선언하는 좋은 방법은 아닙니다.

기본 메타 정책

서버에서 메타 정책을 선언하지 않은 경우 두 가지 결과를 얻을 수 있습니다.

• Flash Player 9,0,115,0 버전부터는 1단계의 기본 메타 정책은 all이 됩니다. 이는 호환성을 강조하는 것으로, 메타 정책이 명시적으로 선택될 때까지 사이트가 이에 영향을 받지 않고 계속 작동할 수 있습니다.
• Flash Player의 이후 버전부터는 2단계의 기본 메타 정책은 none이 됩니다. 이는 보안을 강조하는 것으로, 사이트에서 메타 정책을 명시적으로 선택해야 Flash Player의 최신 버전에서 모든 컨텐츠가 정책 파일로 인식될 수 있습니다.

Flash Player가 브라우저에서 실행될 때 Content-Type 허용 목록을 적용할지는 브라우저의 네트워킹 스택에서 HTTL 응답 헤더를 읽을 수 있는 기능이 Flash Player에 있는지 여부에 따라 달라집니다. 최신 브라우저에서는 이 기능을 사용할 수 있지만 일부 이전 버전의 브라우저에서는 사용할 수 없습니다. HTTP 응답 헤더를 지원하거나 지원하지 않는 브라우저 목록은 부록 A를 참조하십시오. Flash Player가 HTTP 응답 헤더를 읽지 못하면 정책 파일 로그에 경고 메시지가 생성되고 all의 메타 정책이 모든 도메인에 적용됩니다. 또한 HTTP 응답 헤더가 아니라 마스터 HTTP 정책 파일에 나타나는 메타 정책 선언을 비롯해 all의 메타 정책 선언은 무시됩니다.

메타 정책을 선언해야 하는 이유

서버에서 메타 정책을 선언해야 하는 데는 두 가지 이유가 있습니다.

• 서버에서 정책 파일을 제공하지만 관리자가 이러한 정책 파일을 허용하는 메타 정책을 선언하지 않은 경우, Flash Player의 2단계 버전을 설치한 사용자는 정책 파일을 사용할 수 없습니다. 이러한 버전은 아직 출시되지 않았지만 향후 출시될 예정입니다.
• 서버에서 정책 파일 또는 모든 Flash Player 호환 컨텐츠를 의도적으로 제공하는지 여부에 상관없이, 서버에 텍스트 파일을 생성할 수 있는 권한을 가진 사람이라면 누구나 정책 파일을 생성할 수 있습니다. 이 경우 이 정책 파일을 사용하면 서버나 사용자 또는 모두에게 비공개된 데이터를 공개할 수 있습니다. 메타 정책을 선언하면 all의 기본 메타 정책이 Flash Player의 1단계 버전 사용자에게 적용되지 않도록 할 수 있습니다.

메타 정책의 선택 및 적용 방법은 URL 메타 정책 선언을 위한 워크플로우를 참조하십시오.

ActionScript에서 대부분의 네트워킹은 HTTP, HTTPS 및 FTP를 사용한 URL 기반 네트워킹입니다. 그러나 ActionScript는 낮은 TCP 소켓 수준에서 직접 네트워킹을 구현하는 Socket 및 XMLSocket 클래스를 지원하기도 합니다. URL 네트워킹이 URL 정책 파일에 의해 승인되는 한편, ActionScript 소켓 수준의 연결은 소켓 정책 파일에 의해 승인됩니다.

Flash Player 9,0,115,0은 소켓 정책 파일의 작동 방식에 몇 가지 변화를 가져왔습니다. 이러한 변화는 DNS 하드닝의 목표를 지원하는 것으로, ActionScript가 승인을 받지 않은 소켓 연결을 시도하는 DNS 리바인딩 공격의 수단으로 악용되지 않도록 합니다.

호스트를 위한 유효한 소켓 정책 파일 구성을 구현하기 위한 신속한 단계별 가이드는 소켓 정책 파일을 위한 워크플로우를 참조하십시오. 그러나 서버를 유지 관리하는 담당자는 소개 섹션을 먼저 읽어볼 것을 권장합니다. 여기에는 모든 Flash Player 호환 컨텐츠를 제공하지 않는 호스트뿐만 아니라 소켓 기반의 DNS 리바인딩 공격에 취약한 호스트도 포함됩니다.

이 섹션은 메타 정책에 대한 이전 섹션의 연장이므로, 첫 번째 섹션을 먼저 읽으시기 바랍니다.

소켓 정책 파일 배경

배경에 대한 이 섹션에서는 Flash Player 7,0,19,0에 소켓 정책 파일을 도입한 이후 발생한 내용에 대해 살펴봅니다.

소켓 정책 파일과 URL 정책 파일은 클라이언트 컨텐츠의 연결을 승인한다는 점에서 그 목적은 동일하지만, URL 정책 파일은 고유 HTTP, HTTPS 또는 FTP 서버에서 데이터 로딩을 승인하는 반면 소켓 정책 파일은 고유 호스트에 대한 소켓 연결을 승인한다는 차이점이 있습니다.

참고: HTTP, HTTPS 및 FTP를 통한 네트워킹을 가리키는 용어로 "URL 정책 파일", "URL 메타 정책" 등을 사용합니다. 소켓 정책 파일 위치는 ActionScript에서 loadPolicyFile을 호출할 때 URL 예: xmlsocket: URL 을 사용하여 표현된다는 점에도 불구하고 이러한 용어를 사용합니다.

모든 정책 파일에는 필수적인 두 가지 속성이 있는데, 하나는 권한 연결이 승인된 도메인 목록 이며 또 다른 하나는 범위 액세스가 허용된 리소스 세트 입니다. 권한에 관한 한 소켓 정책 파일은 URL 정책 파일과 동일하게 작동하지만, 소켓 정책 파일의 범위는 URL 정책 파일 범위와 다르게 작동합니다.

URL 정책 파일의 범위는 파일의 위치에 의해 결정되지만, 소켓 정책 파일의 범위는 파일의 컨텐츠, 특히 소켓을 연결할 수 있는 TCP 포트를 지정하는 to-ports 속성에 의해 결정됩니다.

소켓 정책 파일은 호스트에 있는 모든 TCP 포트에서 제공될 수 있지만, 1024 이상의 포트에서 제공되는 소켓 정책 파일은 1024 포트 이상의 포트에 대한 연결만을 승인할 수 있습니다. 1024 이하의 포트에서 제공되는 소켓 정책 파일은 호스트의 모든 포트에 대한 연결을 승인할 수 있습니다.

소켓 정책 파일은 기본 연결 ActionScript에 의한 소켓 연결로 소켓 정책 파일에 의해 승인됨 과 동일한 포트 또는 기본 연결과 별도의 다른 포트에서 획득할 수 있습니다. 기본 연결과 동일한 포트를 통해 소켓 정책 파일을 제공하기로 선택한 경우 해당 포트에서 수신하는 서버는 소켓 정책 파일 요청을 파악하고 Flash Player에서 <policy-file-request/>의 전송에 의해 표시됨 정책 파일 요청 및 기본 연결 요청과 다른 방식으로 응답해야 합니다. 일반적으로 별도의 포트에서 소켓 정책 파일을 제공하는 것이 더 수월한데, 이는 한 곳에서 호스트에 대한 소켓 정책을 중앙 집중화하기도 하지만, 대부분의 서버가 고유 소켓 정책 파일을 제공할 준비가 되어 있지 않기 때문입니다.

소켓 마스터 정책 파일

정책 파일이 처음 도입된 후 Flash Player는 /crossdomain.xml 을 URP 정책 파일의 마스터 위치로 인식하고 있습니다. 그러나 9,0,115,0 버전 이전의 Flash Player는 소켓 정책 파일의 고정 마스터 위치를 인식하지 못했습니다. Flash Player 9,0,115,0에서 고정 TCP 포트 번호 843에서 제공하는 소켓 마스터 정책 파일의 개념이 처음으로 도입되었습니다.

소켓 마스터 정책 파일을 통해 다음과 같은 여러 가지 요구 사항을 충족할 수 있습니다.

• 고정 포트 번호는 호스트에서 소켓 정책을 제공하는 표준 방식입니다. 이전에는 각 호스트 관리자가 이러한 방식을 직접 결정해야 했습니다. 그러나 고정 포트 번호를 사용하면 독립형 소켓 정책 파일 서버는 기본적으로 포트 843에 연결되므로 관리자가 익숙하지 않은 시스템에서 소켓 정책을 찾는 것이 한결 수월해집니다.
• 마스터 위치는 소켓 메타 정책을 선언하는 방식입니다. 호스트에서 상주하도록 허용된 소켓 정책 파일을 제어한다는 점에서 소켓 메타 정책은 앞서 살펴본 URL 메타 정책과 유사합니다. 이에 대한 내용은 아래에 있는 소켓 메타 정책 섹션에서 자세히 다룰 것입니다.
• 포트 843에서 소켓 정책 파일을 제공하는 것은 호스트 관리자가 Flash Player의 1단계 버전에서도 새로운 소켓 규칙을 적용하겠다는 의사 표시입니다. 이에 대한 내용은 아래에 있는 엄격한 소켓 규칙 선택 섹션에서 자세히 다룰 것입니다.
• ActionScript에서 소켓 정책 파일의 위치를 Flash Player에 알리려고 loadPolicyFile을 호출하지 않고도 Flash Player는 고정 마스터 위치를 자동으로 확인할 수 있습니다.

참고: Adobe는 소켓 정책 파일 서버의 정보 페이지를 유지 관리할 예정입니다. 이 페이지에는 소켓 정책 파일을 제공하는 단순한 작업을 수행하는 서버를 생성하는 방법, 샘플 코드 등이 제공됩니다.

Adobe는 소켓 정책 파일을 제공하는 목적으로 TCP 포트 843을 사용하도록 IANA Internet Assigned Numbers Authority 를 적용하고 있습니다. 이 프로세스는 상당한 시간이 소요될 수 있지만 그 동안 Adobe는 포트 843의 사용 사례를 광범위하게 문서화하고 있습니다.

포트 번호 843은 1024 이하이므로 소켓 마스터 정책 파일은 호스트의 모든 포트에 대한 액세스를 승인할 수 있습니다. 1024 경계는 Unix 스타일의 호스트에서는 중요한데, 그 이유는 이러한 호스트는 1024 이하의 포트에 서버를 연결하려면 일반적으로 루트 액세스 예: 관리 권한 가 필요하기 때문입니다. 다시 말해 Unix 스타일의 호스트에서 소켓 마스터 정책 파일을 설정하려면 루트 액세스가 필요한데, 이는 이러한 호스트에 대한 훌륭한 보호책입니다.

방화벽을 통한 소켓 마스터 정책 파일을 제공하는 것에 대한 내용은 방화벽 통과성 섹션을 참조하십시오.

소켓 메타 정책

소켓 메타 정책은 URL 메타 정책과 유사하지만 다음과 같은 몇 가지 차이점이 있습니다.

• 소켓 메타 정책은 URL 정책 파일이 아니라 소켓 정책 파일에 영향을 줍니다. 소켓 메타 정책은 하나의 URL 서버가 아니라 전체 호스트에 영향을 줍니다.
• 소켓 메타 정책은 소켓 마스터 정책 파일에서만 선언할 수 있습니다. 구문은 <site-control> 태그를 사용하여 URL 마스터 정책 파일에서 메타 정책을 선언할 때와 같은 구문이 사용됩니다. 소켓 메타 정책은 HTTP와 관계가 없으므로 HTTP 응답 헤더에서 선언할 수 없습니다.
• 소켓 메타 정책에는 URL 메타 정책으로 사용할 수 있는 것과 다른 유형의 메타 정책이 사용되며, 기본 소켓 메타 정책은 기본 URL 메타 정책과 다릅니다.

사용 가능한 소켓 메타 정책은 다음과 같습니다.

• all: 소켓 정책 파일은 이 호스트의 모든 포트에서 허용됩니다. 이 메타 정책은 공용 인터넷에 상주하며 로그인 인증서가 필요한 컨텐츠를 제공하지 않는 호스트에만 적합합니다.
• master-only: 포트 843에서 제공된 소켓 마스터 정책 파일만이 이 호스트에서 허용됩니다.
• none: 이 호스트에서는 모든 소켓 정책 파일이 허용되지 않습니다. 이 메타 정책이 마스터 정책 파일에서 선언되면 이 마스터 정책 파일은 이 메타 정책을 선언하는 용도로만 상주할 수 있도록 허용되며, 이 메타 정책에 포함된 <allow-access-from> 지시문은 무시됩니다.

기본 소켓 메타 정책은 all입니다. Flash Player는 소켓 메타 정책을 선언하는 소켓 마스터 정책 파일을 제공하지 않는 모든 호스트에 대해 all의 메타 정책을 선택합니다. all의 기본값은 Flash Player의 1단계 및 2단계 구현에 모두 적용됩니다. 이는 2단계의 기본 URL 메타 정책이none인 URL 정책 파일의 일반적인 작동 방식과 다릅니다.

따라서 소켓 정책 파일에는 URL 정책 파일과 달리 더 허용되는 기본 메타 정책이 적용됩니다. 이는 소켓은 URL 서버보다 승인되지 않은 정책 파일의 위험 부담을 경험할 가능성이 훨씬 낮기 때문입니다. 예를 들어 HTTP 서버에서 사용자가 생성한 컨텐츠나 서버 관리자 이외의 사람이 생성한 컨텐츠를 제공하는 것은 드문 일이 아니므로, 2단계에서 기본 URL 메타 정책이 none인 것이 바람직하고, 따라서 다른 사람이 정책 파일을 생성하기 전에 관리자가 먼저 정책 파일을 구현할 수 있습니다. 그러나 호스트에서 승인되지 않은 사용자가 TCP 포트에서 수신하는 전체 서버를 설치하거나 변경하는 것을 허용하는 것은 일반적이지 않으므로, 기본 소켓 메타 정책이 all인 것이 바람직하고, 따라서 관리자가 구체적으로 금하지 않은 이상 호스트의 어디에서나 소켓 정책 파일을 생성할 수 있습니다.

엄격한 소켓 규칙

Flash Player 9,0,115,0에서 향상된 DNS 하드닝 기능과 관련해 가장 두드러지는 변경 사항은 엄격한 소켓 규칙이 도입되었다는 점입니다. 이러한 규칙은 다음과 같습니다.

• SWF 파일은 소켓 정책 파일 없이 소켓을 고유 도메인에 더 이상 연결할 수 없습니다. 9,0,115,0 이전 버전에서 SWF 파일은 정책 파일 없이 자체 도메인의 1024 이상 포트에 소켓을 연결할 수 있도록 허용되었습니다.
• HTTP 정책 파일도 소켓 연결 승인을 위해 더 이상 사용될 수 없습니다. 9,0,115,0 이전 버전에서는 포트 80의 /crossdomain.xml 의 마스터 위치에서 제공되는 HTTP 정책 파일은 동일한 호스트의 포트 1024 이상의 포트에 대한 소켓 연결을 승인하는 데 사용할 수 있었습니다.

엄격한 소켓 규칙에서는 모든 소켓 연결은 소켓 정책 파일의 허가가 필요하다라는 간단한 문장으로 이러한 두 가지 규칙을 요약할 수 있습니다.

Flash Player 9,0,115,0에서 정책 파일에 대한 대부분의 변경 사항과 마찬가지로 엄격한 소켓 규칙은 두 개의 단계에 걸쳐 배포되고 있습니다. Flash Player 9,0,115,0부터는 1단계에서 엄격한 정책 파일 규칙을 위반하는 경우 Flash Player의 디버그 버전을 사용하는 Flash 개발자가 볼 수 있도록 경고 메시지만 제공됩니다. 그러나 Flash Player 차기 버전부터는 2단계에서 이러한 경고 메시지는 오류 메시지로 변경되고, 이전 규칙에 따라 SWF 파일은 제 기능을 수행하지 못할 수 있습니다. 1단계 동안에도 호스트 관리자는 엄격한 규칙 적용을 선택할 수 있어, Flash Player의 1단계 버전 사용자를 위해 자신이 관리하는 사이트를 DNS 리바인딩 공격으로부터 보호할 수 있습니다.

엄격한 소켓 규칙 적용으로 인해 발생하는 문제점을 찾고 해결하는 방법에 대한 자세한 내용은 소켓 정책 파일을 위한 워크플로우를 참조하십시오. 간단히 말해 위에서 설명한 두 가지 상황 중 한 가지 상황에서 소켓 연결을 하는 모든 SWF 파일을 유지 관리하는 경우라면, 관리자는 현재 연결을 시도하고 있는 호스트에서 소켓 정책 파일을 제공하고 있는지 확인해야 합니다. 이러한 확인을 위해 일반적으로 사용되는 방법은 포트 843에서 소켓 마스트 정책 파일 서버를 설치하는 것이지만, 다른 옵션을 모색하고 있다면 해당 워크플로우 섹션을 참조하십시오.

엄격한 소켓 규칙 선택

Flash Player의 1단계에서도 다음 구성의 경우 호스트는 엄격한 소켓 규칙을 사용할 수 있습니다. 이와 같은 정보는 자체적인 보호를 위해 보다 안전한 규칙을 선택할 수 있는 호스트 관리자와 이러한 구성이 소켓을 연결하는 SWF 파일의 기능에 미치는 영향을 이해하고 있어야 하는 SWF 파일 유지 관리자 모두에게 중요합니다.

• 호스트가 포트 843을 통해 소켓 정책 파일 소켓 마스터 정책 파일 을 제공하는 경우 엄격한 소켓 규칙이 호스트 전체에 적용됩니다. 정책 파일의 컨텐츠와 상관없이 적용되는데, 소켓 마스터 정책 파일이 비어있거나 all의 메타 정책을 선언한 경우에도 호스트에는 엄격한 소켓 규칙이 적용됩니다. 이 호스트에 대한 모든 소켓 연결은 소켓 정책 파일의 허가가 필요한데, 이 소켓 정책 파일이란 엄격한 소켓 규칙으로의 전환을 실행하는 동일한 소켓 마스터 정책 파일입니다. 이는 호스트 관리자가 엄격한 소켓 규칙을 선택하기 위해 사용해야 하는 일반적인 방법입니다.
• 포트 80에 있는 HTTP 서버가 /crossdomain.xml에 위치한 마스터 정책 파일에서 URL 메타 정책을 선언한 경우, 해당 마스터 HTTP 정책 파일은 동일한 호스트에 대한 소켓 연결을 승인하지 않습니다. 이 구성에서는 호스트에 대한 두 가지 엄격한 소켓 규칙 중 자체 호스트에 대한 SWF 파일 연결이 영향을 받지 않은 규칙만이 활성화됩니다.
• 마스터가 아닌 소켓 포트가 소켓 정책 파일을 제공하는 경우 엄격한 소켓 규칙이 이 특정 포트에 적용됩니다. 이 포트에 대한 모든 소켓 연결은 소켓 정책 파일의 허가가 필요한데, 이 소켓 정책 파일이란 이 포트를 통해 제공되는 동일한 소켓 정책입니다. 경우에 따라 이 규칙은 의도하지 않은 결과를 낳기도 합니다. 이에 대한 내용은 즉시 적용되는 엄격한 소켓 규칙 섹션에 자세히 나와 있습니다. 다시 말해 1024 이상의 소켓 포트에서 고유 도메인을 나열하지 않은 소켓 정책 파일을 제공하는 경우, 이전에는 정책 파일 없이 연결이 허용되었던 해당 도메인의 SWF 파일은 더 이상 연결할 수 없게 됩니다.

안전한 도메인 목록

정책 파일이 도입된 후 Flash Player는 HTTP 서버에서 정책 파일의 <allow-access-from> 지시문에 있는 특별 속성인 secure="true"를 지원합니다. secure="true"가 지정될 때 이러한 SWF 파일이 HTTPS를 통해 검색되는 경우에만 데이터를 검색할 수 있도록 <allow-access-from> 지시문에 열거된 도메인의 SWF 파일이 허용됩니다. 이는 HTTPS 서버에서 데이터를 보호하며, 출처가 강력하게 인증되지 못한 SWF 파일로 유입되지 않도록 합니다. HTTPS를 통해 제공되는 SWF 파일은 HTTP를 통해 제공되는 SWF 파일보다 생성하기가 더욱 어려운데, 그 이유는 HTTPS에 내장된 도메인 인증 및 부정 변경 방지 tamper-resistant 기술 때문입니다. HTTPS 정책 파일의 기본 비헤이비어는 secure="true"입니다. 이를 덮어쓰려면 HTTPS 정책 파일은 명시적으로 secure="false"를 선언해야 하는데, 이는 Adobe에서 권장하고 있지 않습니다.

9,0,115,0 버전부터 Flash Player는 로컬 소켓 예: Flash Player가 설치되어 있는 컴퓨터에서 실행되는 소켓 서버 의 소켓 정책 파일이라는 새로운 상황에서 secure="true" 선언을 지원합니다. secure="true"가 로컬 소켓 정책 파일의 <allow-access-from> 지시문에서 선언되는 경우 <allow-access-from> 지시문에 나열된 도메인의 SWF 파일은 이러한 SWF 파일이 HTTPS를 통해 검색되는 경우에만 허용된 포트에 연결할 수 있습니다. 다음은 이 기능을 사용한 로컬 소켓 정책 파일의 예입니다.

이 정책 파일에 의해 부여된 유일한 권한은 포트 3050에 연결할 수 있도록 my.com에서 HTTPS를 통해 로드된 SWF 파일에 대한 권한입니다. my.com에서 HTTP를 통해 로드된 SWF 파일에는 이 특정 정책 파일에 의해 어떤 권한도 부여되지 않습니다.

secure="true" 선언으로 나열된 도메인을 안전한 도메인 목록이라고 합니다.

로컬 소켓 정책 파일에 있는 안전한 도메인 목록은 온라인/오프라인 하이브리드 애플리케이션의 경우 매우 유용합니다. 예를 들어 애플리케이션이 사용자 시스템에 기본 로컬 구성 요소를 설치하고, 웹 브라우저를 통해 온라인 SWF 인터페이스를 제공하고, 웹 SWF와 로컬 구성 요소 간의 통신을 위해 ActionScript 소켓 연결을 사용한다고 가정해 봅시다. 이러한 시나리오에서 애플리케이션 개발자는 특정 SWF 파일만이 로컬 구성 요소와 통신할 수 있도록 만들기를 원합니다. 그렇지 않으면 웹의 다른 SWF 파일이 로컬 구성 요소의 기본 기능을 제어할 수 있기 때문입니다. 이 애플리케이션의 개발자가 my.com에 있는 HTTPS 서버에 자신의 모든 SWF 파일을 게시했고 로컬 구성 요소에서 secure="true" 선언을 비롯하여 위에서 말한 소켓 정책 파일을 제공했다면, 애플리케이션 개발자의 고유 SWF 파일만이 로컬 구성 요소에 연결되게 됩니다.

로컬 애플리케이션 개발자가 안전한 도메인 목록을 활용하려면 사용자의 시스템에 최소한 9,0,115,0 버전의 Flash Player가 설치되어 있어야 합니다. 그렇지 않으면 secure="true" 지시문은 자동으로 무시됩니다.

Adobe는 로컬 소켓(예: Flash Player가 설치되어 있는 컴퓨터에서 실행되는 소켓 서버)에서 제공되지 않는 소켓 정책 파일에서 secure="true" 지시문의 사용을 권장하고 있지 않습니다. 출처가 로컬 호스트가 아닌 소켓 정책 파일에서 secure="true"가 발견되면 Flash Player는 정책 파일 로그에 경고 메시지를 표시합니다. 사실 Flash Player는 비로컬 소켓 정책 파일의 secure="true"를 인정하지만 Flash Player에서는 로컬 호스트에 소켓이 연결된 것인지 여부를 100% 감지할 수 없기 때문에 경고 메시지를 생성하게 됩니다.

출처가 로컬 호스트가 아닌 소켓 정책 파일에서 secure="true"를 선언하는 것이 왜 안전하지 않은지에 대해 이해하는 것은 중요합니다. 본 기술문서를 기술하고 있는 현재, Flash Player는 안전한 소켓 수준의 네트워킹을 제공하지 않고 있습니다. 아직 소켓 수준에서는 HTTPS에 버금가는 네트워킹(소켓 수준에서 SSL/TLS라고 함)이 없기 때문입니다. 다시 말해 소켓 정책 파일은 항상 SSL/TLS의 이점 없이 검색된다는 것입니다. 따라서 소켓 정책 파일은 클라이언트와 서버 간의 네트워크에서 제3자가 네트워크 통신의 컨텐츠를 변경할 수 있지만, 클라이언트나 서버에서는 이를 인식하지 못하는 위장(man-in-the-middle) 공격에 취약합니다. 그러므로 비로컬 소켓의 소켓 정책 파일이 secure="true"를 선언하면 위장 공격자는 secure="false"로 간단하게 변경할 수 있습니다. 비로컬 소켓 정책 파일에서 secure="true"를 선언하는 것은 Flash Player에서 안정적으로 실행할 수 없는 잘못된 보안을 제공할 수 있습니다. (secure="true"가 HTTPS 정책 파일에서는 허용되지만 HTTP 정책 파일에서는 허용되지 않는 이유가 바로 이 때문입니다.) 그러나 secure="true"가 로컬 소켓 정책 파일에서 선언된 경우 서버에서 Flash Player로 소켓 정책 파일을 전송할 수 있는 오프 호스트 네트워킹이 없습니다. 바로 이점이 secure="true"가 로컬 소켓 정책 파일에서 사용되는 이유입니다.

주소 기반 소켓 정책 파일 범위

Flash Player 9,0,115,0에서 소켓 정책 파일에 있어 가장 두드러지는 변경 사항은 ActionScript에는 표시되지 않고 컨텐츠에 어떤 변경도 필요하지 않다는 점입니다.

9,0,115,0 이전 버전의 Flash Player가 일부 도메인 a.com의 소켓 정책 파일을 발견했다면 이 정책 파일은 a.com에 대한 소켓 연결을 승인하는 데 사용할 수 있었습니다. 그러나 이는 DNS 리바인딩으로 인해 a.com이 정책 파일 검색 당시의 호스트가 아니라 소켓 연결 당시의 호스트를 참조하여 하나의 호스트에서 다른 호스트에 대한 권한을 지정할 수 있는 여지를 남겼습니다.

그러나 9,0,115,0 버전부터 Flash Player에서는 소켓 연결이 허용되기 전에 소켓 정책 파일이 연결된 호스트와 동일한 IP 주소에서 검색되었는지 항상 확인합니다.

서버 호스트에 노출된 소켓 정책 파일 비헤이비어

Flash Player 9,0,115,0에서는 익숙한 트래픽과 약간 다른 트래픽이 호스트에 발생하게 할 수 있는데, Flash Player에는 이러한 차이를 소화할 수 있는 기능이 포함되어 있습니다. 그 차이는 다음과 같습니다.

• SWF 파일이 고유 도메인을 포함하여 소켓 연결을 시도할 때 Flash Player는 먼저 포트 843에 연락하여 호스트가 소켓 마스터 정책 파일을 제공하는지 확인합니다.
• ActionScript 1.0 또는 ActionScript 2.0 SWF 파일이 XMLSocket 연결을 시도하고 이 연결에 대한 권한이 아직 소켓 마스터 정책 파일 또는 위치가 loadPolicyFile로 지정된 정책 파일에서 부여되지 않은 경우, Flash Player는 기본 연결 때와 동일한 도메인의 포트 80에서 HTTP 정책 파일을 찾는 이전 비헤이비어를 시도하기 전에 기본 연결 때와 동일한 포트에서 정책 파일을 검색하게 됩니다. (ActionScript 3.0 소켓 연결에 대한 기본 정책 파일 확인은 변경되지 않았습니다. 기본 연결에서 사용하는 것과 동일한 포트를 점검하는 작업은 ActionScript 3.0 소켓 연결 시 기본적으로 실행됩니다.)

Flash Player에서 자동으로 요청하는 모든 소켓 정책 파일의 경우 호스트가 3초 내에 이 연결 시도에 대해 응답하지 않거나 이를 거부하지 않으면, Flash Player는 연결 시도를 중단하고, 해당 위치에 정책 파일이 없다고 판단하여 정책 파일 로그에 경고 메시지를 표시한 후 소켓 정책 파일 승인의 다음 단계를 진행합니다. 이러한 시간 초과 비헤이비어는 결코 성공하지 않는 소켓 연결을 너무 오래 기다리는 것으로부터 Flash Player를 보호하지만 일시적인 네트워크 중단, 느린 연결, 로드량이 너무 많은 서버 등에 대처하는 Flash Player의 강점을 감소시키는 결과를 초래하기도 합니다. Flash Player가 자동으로 요청하는 특정 소켓 정책 파일이 제공되는 것을 알고 있는 경우에는 SWF 파일의 loadPolicyFile을 명시적으로 호출하여 해당 소켓 정책 파일의 URL을 제공함으로써 3초 시간 초과 비헤이비어가 발생하지 못하게 할 수 있습니다. 이렇게 하면 해당 정책 파일을 검색하려고 할 때 Flash Player는 인내심을 가질 수 있으므로, 2분의 TCP 시간 초과가 만료될 때까지 3초 시간 초과를 예방할 수 있습니다. 예를 들어 mysite.com의 포트 843에서 마스터 소켓 정책 파일이 제공되는 것을 알고 있고 Flash Player에서 이를 검색하는 동안 3초 시간 초과를 피하고자 하는 경우, ActionScript에서 loadPolicyFile("xmlsocket://mysite.com:843")을 호출할 수 있습니다.

방화벽 통과성 및 소켓 정책 파일

소켓 마스터 정책 파일의 한 가지 단점은 클라이언트가 있어야만 포트 843에 액세스할 수 있다는 점입니다. 제한적인 아웃바운드 방화벽 뒤에 위치한 일부 사용자는 이러한 기능을 가질 수 없습니다.

Adobe는 아웃바운드 방화벽에는 포트 843에 대한 액세스를 허용해야 하는 합당한 이유가 있다고 믿고 있습니다. 그렇게 하면 Flash Player가 호스트 관리자가 선언한 보안 정책을 실행하는 데 도움을 줄 수 있으며, 포트 843의 용도를 표준화하려는 노력을 통해 다른 유형의 서버가 이 포트에 연결되지 않도록 할 수 있기 때문입니다. 그러나 소켓 마스터 정책 파일은 새로운 개념으로, 일련의 방화벽 규칙이 포트 843에 대한 액세스를 적용하는 데에는 시간이 걸릴 것으로 예상됩니다. 또한 이는 포트 843에 대한 액세스를 허용하지 않기로 선택할 수 있는 방화벽 관리자의 개인 재량에 맡겨야 하는 문제이기도 합니다. 지금부터 이러한 조치로 인해 Flash Player 사용자나 서버 호스트에게 심각한 문제가 발생하지 않는다는 점을 설명하도록 하겠습니다.

포트 843에 액세스할 수 없는 경우 다음 결과가 뒤따릅니다.

1. 소켓 메타 정책이 적용되지 않습니다. 모든 소켓 정책 파일에서 액세스를 허용할 수 있습니다(제한적인 방화벽 뒤의 사용자에게만).
2. Flash Player의 1단계 버전의 경우 호스트가 소켓 마스터 정책 파일을 이용하여 새로운 규칙을 적용하도록 선택할 수 있음을 나타내면 이러한 선택은 Flash Player에는 표시되지 않습니다. 제한적인 방화벽 뒤의 사용자는 1024 이상의 소켓 포트를 대상으로 하는 DNS 리바인딩 공격을 촉진하는 매개체가 될 수 있습니다.
3. 호스트에서 소켓 마스터 정책 파일을 사용하여 소켓 연결을 승인하는 경우 제한적인 방화벽 뒤의 사용자는 이러한 연결을 설정할 수 없게 됩니다.

Adobe는 이러한 결과가 경우에 따라 사소한 문제를 일으킬 수는 있지만 큰 문제로 이어진다고는 생각하지 않습니다. 그 이유는 다음과 같습니다.

• 사용자가 제한적인 방화벽 뒤에 있고 포트 843을 볼 수 없는 경우, 대상 포트도 보지 못할 수 있습니다. 그렇게 되면 위에서 언급한 세 가지 단점이 모두 무마될 수 있습니다. HTTP의 포트 80과 같이 방화벽에서 거의 항상 허용하는 몇 가지 포트가 있기는 하지만, 1024 이상의 대부분의 포트를 비롯하여 대다수의 포트에 액세스할 수 없습니다. 이 마지막 논점은 문제 (2)가 자주 발생할 가능성이 매우 낮다는 점을 의미합니다.
• 방화벽 뒤의 서버를 대상으로 하는 DNS 리바인딩 공격의 경우 포트 843에 대한 액세스는 문제가 되지 않습니다. 그 이유는 방화벽 안에 있는 서버의 모든 포트에 대한 액세스를 차단하는 방화벽은 없기 때문입니다.
• 위의 문제 (1)의 경우 소켓 메타 정책(매우 이례적인 경우임)에 접근하려는 사람은 유일하게 사용할 수 있는 매개체가 제한적인 아웃바운드 방화벽 뒤에 있는 사용자라는 사실을 안다면 그리 반기지 않을 것입니다.

소켓 정책 파일을 제공해야 하는 이유

호스트에서 소켓 정책 파일(포트 843의 소켓 마스터 정책 파일)을 제공해야 하는 데는 두 가지 이유가 있습니다.

• 호스트에 소켓을 연결하는 SWF 파일을 유지 관리하고 있고 SWF 파일이 현재 소켓 정책 파일 없이 연결되는 경우(SWF 파일이 고유 도메인에 연결되어 있기 때문에 또는 HTTP 정책 파일을 사용하기 때문에), Flash Player의 2단계 버전을 설치하는 사용자를 위해 이러한 SWF 파일은 연결되지 않습니다. 이러한 버전은 아직 출시되지 않았지만 향후 출시될 예정입니다.
• 호스트가 의도적으로 소켓 정책 파일이나 Flash Player 호환 컨텐츠를 제공하는지 여부에 상관없이 이를 악용하는 공격자는 DNS 리바인딩 공격을 사용해 호스트에 대해 승인되지 않은 소켓 수준의 연결을 시도할 수 있습니다. 소켓 마스터 정책 파일을 제공하는 엄격한 소켓 규칙을 선택하게 되면 Flash Player의 1단계 버전 사용자는 이러한 공격을 악화시키는 매개체로 이용되지 않을 수 있습니다.

호스트에서 마스터 소켓 정책 파일을 제공하는 데 필요한 단계에 대한 자세한 내용은 소켓 정책 파일 구성을 위한 워크플로우를 참조하십시오.

다음 절차는 Flash Player 9,0,115,0의 정책 파일 변경 사항과 관련하여 발생할 수 있는 모든 문제를 신속하게 해결하는 데 도움을 줍니다. Adobe는 본 기술문서의 소개 섹션을 먼저 읽은 후 이 섹션들을 참조용으로 사용할 것을 권장합니다.

로깅 사용

Flash Player 9,0,115,0에서는 새로운 기능인 정책 파일 로깅이 새롭게 도입되었습니다. 정책 파일 로그는 정책 파일 검색 시도, 파일 처리 시 성패 여부, 파일에 좌우되는 요청의 결과 등 정책 파일과 관련한 각 이벤트에 대한 메시지를 보여줍니다. 정책 파일 로그에서 찾아볼 수 있는 메시지에 대한 전체 참조는 부록 B를 참조하십시오.

정책 파일 로그 사용 방법

1. Flash Player 9,0,115,0 이상의 디버그 버전을 설치합니다. ActiveX, 플러그인 및 독립형 중 원하는 유형의 Flash Player를 사용할 수 있습니다. Flash Player 디버그 버전은 Flash Player 지원 센터의 다운로드 페이지에서 다운로드할 수 있습니다.
2. mm.cfg 구성 파일의 위치를 찾습니다. 이 구성 파일은 시작 시 Flash Player의 디버그 버전이 읽게 되는 일반적인 디버깅 구성 파일입니다. mm.cfg는 "홈" 디렉토리에 있습니다. 여기서는 일반적인 예 중 몇 가지를 소개합니다.

   Windows: C:\Documents and Settings\username

   Windows Vista: C:\Users\username

   Macintosh 및 Linux: /home/username

3. 이 구성 파일이 존재하는 않는 경우 mm.cfg를 생성하고 다음 두 줄 중 하나나 두 개를 모두 이 구성 파일에 추가합니다.

PolicyFileLogAppend가 활성화되지 않은 경우 새로운 루트 수준의 SWF 파일은 로그 파일을 삭제합니다. PolicyFileLogAppend가 활성화되어 있는 경우 로그 파일의 이전 컨텐츠는 항상 유지되며 로그 파일의 크기는 마지막에 증가합니다.

수많은 다른 루트 수준의 SWF 파일이 테스트 도중 로드되면 PolicyFileLogAppend를 활성화하는 것이 좋습니다. 그러나 PolicyFileLogAppend를 활성화하면 로그 파일의 이름을 수동으로 변경하거나 삭제해야 하는 경우가 발생할 수 있습니다. 그렇지 않으면 엄청난 크기로 확대되어 이전 출력이 종료된 지점과 새로운 출력이 시작된 지점을 찾기가 어려워집니다.

4. 정책 파일 로그 파일인 policyfiles.txt가 작성될 위치를 찾습니다. 아직 존재하는 것은 아니지만 SWF 파일이 실행되면 Flash Player가 이 파일을 생성하게 됩니다. 다음 위치에서 policyfiles.txt를 찾을 수 있습니다.

   Windows: C:\Documents and Settings\username\Application Data\Macromedia\Flash Player\Logs

   Windows Vista: C:\Users\username\AppData\Roaming\Macromedia\Flash Player\Logs

   Macintosh: /Users/username/Library/Preferences/Macromedia/Flash Player/Logs 프로그램에서 로그 파일을 Preferences 디렉토리에 작성하는 것은 일반적이지 않지만 이 경우에는 Preferences 디렉토리에 작성합니다.

   Linux: /home/username/.macromedia/Flash_Player/Logs

5. Flash Player에서 SWF 파일을 실행한 다음 Flash Player를 종료합니다.
6. Logs 디렉토리에 policyfiles.txt가 표시됩니다. 이 파일에 최근 수정 시간이 기록되어 있는지 확인합니다. 이 파일을 열어 한 개 이상의 메시지가 표시되어 있는지 확인합니다 예: "Root-level SWF loaded" . 메시지가 표시되어 있다면 정책 파일 로깅이 제대로 작동하는 것입니다.
7. 테스트해야 하는 SWF 컨텐츠를 검토합니다. 모든 시나리오에서 컨텐츠를 실행해보면서 정책 파일과 충돌할 수 있는 상황을 테스트합니다. 모두 완료하면 Flash Player를 종료합니다.
8. policyfiles.txt를 읽고 테스트 실행 동안 정책 파일에 발생한 내용을 확인합니다. 명확하지 않는 메시지가 표시되어 있는 경우 부록 B를 참조하십시오.
9. policyfiles.txt에 향후 참조용으로 보관하려는 유용한 정보가 있다면 해당 로그 파일의 이름을 policyfiles.txt가 아닌 다른 이름으로 변경하거나 다른 디렉토리에 옮겨 다음에 Flash Player가 실행될 때 이 로그를 덮어쓰지 않도록 합니다.

즉각적인 문제 인식 및 해결

엄격한 규칙의 즉각 적용 섹션에서 설명한 바와 같이, Flash Player 9,0,115,0의 변경 사항 중 몇 가지는 SWF 컨텐츠에 즉시 영향을 미칠 수 있는 것으로, SWF 파일의 일부에 적합하지 않은 비헤이비어를 야기할 수 있습니다. SWF 컨텐츠를 유지 관리하는 경우라면 다음 조처를 가능한 신속하게 수행해야 합니다.

1. Flash Player 9,0,115,0 이상의 디버그 버전을 설치합니다. Flash Player의 브라우저 기반 버전을 사용하여 프로덕션 환경을 시뮬레이션합니다. ActiveX 플레이어 또는 플러그인 플레이어 중 하나를 사용할 수 있는데, 이 두 가지 모두 동일한 결과를 제공합니다. Flash Player 디버그 버전은 Flash Player 지원 센터의 다운로드 페이지에서 다운로드할 수 있습니다.
2. 테스트의 경우 Flash Player에 대해 HTTP 응답 헤더를 지원하는 최신 브라우저를 사용합니다. 이렇게 하면 즉각적인 문제에 대해 보다 완벽한 테스트를 수행할 수 있습니다. 이 요구 사항을 충족하는 브라우저에 대한 자세한 내용은 부록 A를 참조하십시오.
3. 위에서 설명한 바와 같이 정책 파일 로깅을 활성화합니다.
4. SWF 컨텐츠를 테스트합니다. 원하는 만큼 컨텐츠를 실험해 봅니다.
5. 컨텐츠에 대한 테스트를 모두 완료한 후에는 Flash Player를 종료하고 정책 파일 로그를 점검합니다. 정책 파일 로그에서 [strict] 레이블이 포함되어 있는 메시지를 찾습니다. 이 레이블은 잠재적으로 즉각적인 문제가 될 수 있음을 나타냅니다.
6. 예상과 달리 작동하지 않은 컨텐츠가 있다면 디버그해야 하는 문제가 있음을 의미하므로 해당 컨텐츠를 기록합니다. 이러한 경우를 정책 파일 로그의 컨텐츠와 상호 연관시켜 보고 이전 버전의 Flash Player에서 이러한 경우를 다시 테스트해보면서 Flash Player 9,0,115,0에서 다르게 작동하는지 확인해야 합니다. 이전 버전과 새로운 버전 간에 차이가 없는 경우는 정책 파일의 엄격한 규칙 적용과 관련한 문제가 되지 않습니다.

   이전 버전으로 다운그레이드하기 위해 Flash Player를 제거해야 하는 경우 Flash Player 제거 프로그램을 사용하십시오. ActiveX 컨트롤에는 보안 기능이 있으므로 다음과 같은 "/clean" 명령을 사용하는 제거 프로그램을 실행해야 합니다.

   uninstall_flash_player.exe /clean

   이전 버전의 Flash Player로 테스트하려면 테스트 용도로 사용 가능한 이전 Flash Player 기술노트를 참조하십시오.

7. 정책 파일 로그에 표시되는 모든 [strict] 메시지를 분류합니다. 이러한 메시지에는 다음이 포함될 수 있습니다.
   • Ignoring policy file at URL due to incorrect syntax. 잘못된 형식의 정책 파일은 무시되어 크로스 도메인 액세스가 거부됩니다. 자세한 내용은 이 로그 메시지 설명과 잘못된 형식의 정책 파일 섹션을 참조하십시오.
   • Policy file requested from URL redirected to URL ; will use final URL in determining scope. 정책 파일 리디렉션은 정책 파일의 범위를 변경할 수 있어 크로스 도메인 액세스가 거부됩니다. 자세한 내용은 이 로그 메시지 설명과 도메인 내 리디렉션 섹션을 참조하십시오.
   • Ignoring policy file at URL due to bad Content-Type ' content-type '. HTTP 정책 파일이 서버에서 선언한 필수 텍스트 형식의 Content-Type 값 없이 수신되었지만 무시되므로 크로스 도메인 액세스가 거부됩니다. 자세한 내용은 이 로그 메시지 설명과 Content-Type 허용 목록 섹션을 참조하십시오.
   • Ignoring policy file at URL due to missing Content-Type. HTTP 정책 파일이 서버에서 선언한 필수 텍스트 형식의 Content-Type 값 없이 수신되었지만 무시되므로 크로스 도메인 액세스가 거부됩니다. 자세한 내용은 이 로그 메시지 설명과 Content-Type 허용 목록 섹션을 참조하십시오.
   • Local socket connection forbidden to host host without a socket policy file. SWF 컨텐츠는 로컬 호스트에 있는 소켓에 연결을 시도했지만 이 호스트를 localhost로 참조하지 않았습니다. 엄격한 소켓 규칙은 즉시 적용되고 액세스가 거부됩니다. 자세한 내용은 이 로그 메시지 설명과 엄격한 소켓 규칙의 즉각 적용 섹션을 참조하십시오.

URL 메타 정책 구성

메타 정책 섹션에서 설명한 바와 같이, HTTP, HTTPS 또는 FTP 서버 중에서 하나를 선택하여 메타 정책을 선언해야 하는 데는 두 가지 이유가 있습니다.

• 서버에서 정책 파일을 제공하지만 관리자가 이러한 정책 파일을 허용하는 메타 정책을 선언하지 않은 경우, Flash Player의 2단계 버전을 설치한 사용자는 정책 파일을 사용할 수 없습니다. 메타 정책을 구성하면 서버의 정책 파일은 Flash Player의 2단계 사용자를 위해 원활하게 전환될 수 있습니다.
• 서버에서 정책 파일 또는 모든 Flash Player 호환 컨텐츠를 의도적으로 제공하는지 여부에 상관없이, 서버에 텍스트 파일을 생성할 수 있는 권한을 가진 사람이라면 누구나 정책 파일을 생성할 수 있습니다. 이 경우 이 정책 파일을 사용하면 서버나 사용자 또는 모두에게 비공개된 데이터를 공개할 수 있습니다. 메타 정책을 선언하면 all의 기본 메타 정책이 Flash Player의 1단계 버전의 사용자에게 적용되지 않도록 할 수 있습니다.

관리하지 않는 서버에서 사이트를 운영하고 있는 경우 호스트된 서비스의 사용자를 위한 고려 사항 섹션을 읽어보십시오.

제어하고 있는 서버에서 메타 정책 구성 방법

1. 메타 정책의 기본 사항을 숙지합니다.
2. 사용 가능한 메타 정책 목록을 읽어봅니다. 서버에 가장 적합한 메타 정책을 결정합니다. 다음은 HTTP 및 HTTPS 서버를 위한 몇 가지 지침입니다. FTP 서버도 유사하지만 자세히 들여다보면 약간 다릅니다.
   • 서버에서 정책 파일을 제공하지 않도록 하려면 none의 메타 정책을 선택합니다.
   • 서버에서 사용자 정의된 컨텐츠를 제공하는 경우 사용자가 정책 파일을 생성하지 못하게 하는 메타 정책 전략을 선택합니다. 이는 기본적으로 all을 선택하지 말라는 것을 의미하는 것이며, by-content-type을 선택하는 경우 사용자 정의된 컨텐츠가 text/x-cross-domain-policy의 Content-Type을 지정하는 기준을 충족할 수 없게 됩니다.
   • 서버에 대한 업로드 권한을 가진 사람이라면 누구나 정책 파일을 생성할 수 있도록 하려면 all의 메타 정책을 선택합니다.
   • 서버에 마스터 정책 파일을 하나만 두려면 master-only의 메타 정책을 선택합니다. 그러면 신뢰하는 사람만이 /crossdomain.xml에 있는 마스터 정책 파일의 컨텐츠를 변경할 수 있습니다.
   • 개별적으로 승인된 위치에서 마스터가 아닌 정책 파일을 허용하려면 by-content-type의 메타 정책을 선택하고 개별적으로 지정된 위치에 text/x-cross-domain-policy의 Content-Type을 지정합니다. 다음은 이를 위한 Apache 구성 코드 단편의 예입니다.

• 미리 결정된 위치에 마스터가 아닌 정책 파일 예: 이름이 crossdomain.xml인 모든 파일 을 허용하려면 by-content-type의 메타 정책을 선택하고 기준을 충족하는 모든 위치에 text/x-cross-domain-policy의 Content-Type을 지정합니다. 다음은 이를 위한 Apache 구성 코드 단편의 예입니다.

• 서버에서 정책 파일을 생성하기 위해 허용하고 싶지 않은 스크립트를 호스트하는 경우 none-this-response의 특수 메타 정책을 해당 스크립트의 출력에 추가합니다. 다음은 이를 위한 Apache 구성 코드 단편의 예입니다.

3. 메타 정책에서 마스터 정책 파일 또는 HTTP 응답 헤더를 사용하여 선언할 것인지 그 여부를 결정합니다. (FTP 서버는 마스터 정책 파일을 사용해야 합니다.) 각 방법의 장점과 단점에 대한 내용은 메타 정책 지정 방법 섹션을 참조하십시오.
   1. 마스터 정책 파일에서 메타 정책을 선언하는 경우 <site-control> 태그를 /crossdomain.xml에 있는 마스터 정책 파일에 작성합니다. 한 가지 예를 들어보겠습니다.

2. HTTP 응답 헤더에서 메타 정책을 선언하는 경우 서버에서 적합한 X-Permitted-Cross-Domain-Policies 헤더를 반환하도록 구성합니다. 다음은 이를 위한 Apache 구성 코드 단편의 예입니다.

호스트된 서비스의 사용자를 위한 특별 고려 사항

호스트된 서비스로 사이트를 운영하거나 제어 권한이 전혀 없는 서버를 운영하면서 정책 파일을 제공하는 경우 다음 사항을 고려하십시오.

• Flash Player 9,0,115,0에서 작동되지 않는 것이 있다면 즉각적인 문제 해결을 위한 워크플로우를 참조하십시오. 서버 관리자 없이도 대부분의 문제는 해결할 수 있어야 합니다.
• 장기적인 측면에서 메타 정책을 구축해야 해야 하는데, 그렇게 못하는 경우 정책 파일이 작동하지 않게 됩니다. 그러나 몇 개월의 시간이 있으므로 여유를 갖고 메타 정책을 구축하십시오. 서버 차원의 변경 사항을 적용하여 사용자나 기타 서비스 고객을 위해 문제를 해결하는 데 서버 관리자가 필요한 경우도 발생할 수 있습니다. 이러한 경우 서비스 제공업체에게 연락한 후 이 기술문서에서 설명한 변경 사항에 대한 내용을 전달하여 변경 사항을 고려할 수 있도록 하는 것도 도움이 될 수 있습니다.
• 예를 들어 악성 정책 파일로부터 사이트를 보호하기 위해 빠른 시일 안에 메타 정책을 구축하려는 경우 또는 Flash Player 2단계 버전이 곧 출시될 예정이고 서비스 제공업체가 서비스 차원의 문제 수정을 하지 않은 경우, 사이트의 루트 디렉토리에 대한 액세스 권한이 있다면 직접 문제를 해결할 수 있습니다. URL 메타 정책 구성을 위한 워크플로우를 수행하십시오. HTTP 응답 헤더에 영향을 줄 수 없으므로 선택할 수 있는 옵션은 제한적일 수 있습니다. 합리적인 옵션은 다음과 같습니다.

사이트에서 정책 파일을 한 개만 사용하려면 다음 옵션을 사용합니다.

사이트에 정책 파일에 대한 어떠한 제한 사항도 적용하지 않으려면 다음 옵션을 사용합니다.

소켓 정책 파일 구성

소켓 정책 파일 섹션에서 설명한 바와 같이, 호스트에 있는 포트 843에서 소켓 마스터 정책 파일을 제공하려고 하는 데는 두 가지 이유가 있습니다.

• 호스트에 소켓을 연결하는 SWF 파일을 유지 관리하고 있고 SWF 파일이 현재 소켓 정책 파일 없이 연결되는 경우(SWF 파일이 고유 도메인에 연결되어 있기 때문에 또는 HTTP 정책 파일을 사용하기 때문에), Flash Player의 2단계 버전을 설치하는 사용자를 위해 이러한 SWF 파일은 연결되지 않습니다. 소켓 마스터 정책 파일을 제공하면 호스트에 대한 소켓 연결이 Flash Player의 2단계 버전 사용자를 위해 원활하게 전환될 수 있습니다. (특정 SWF 컨텐츠가 소켓 정책 파일 없이 호스트에 소켓을 연결하는지 확실치 않은 경우 정책 파일 로그를 사용하면서 컨텐츠를 테스트해 보고 사용되지 않은 소켓 구성에 대한 경고 메시지가 표시되는지 확인합니다.)
• 호스트가 의도적으로 소켓 정책 파일이나 Flash Player 호환 컨텐츠를 제공하는지 여부에 상관없이 이를 악용하는 공격자는 DNS 리바인딩 공격을 사용해 호스트에 대해 승인되지 않은 소켓 수준의 연결을 시도할 수 있습니다. 소켓 마스터 정책 파일을 제공하는 엄격한 소켓 규칙을 선택하게 되면 Flash Player의 1단계 버전 사용자는 이러한 공격을 악화시키는 매개체로 이용되지 않을 수 있습니다.

소켓 마스터 정책 파일을 제공하는 것은 이러한 문제점을 해결할 수 있는 유일한 해결책일 뿐만 아니라 문제 해결을 위한 가장 간편하고 일관된 방법입니다. 포트 843에서 마스터 소켓 정책 파일을 제공하는 것이 실용적이지 않다고 판단되면 포트별로 이러한 문제를 해결하여 개별 포트에서 마스터가 아닌 소켓 정책 파일을 제공할 수 있습니다. 그러나 소켓 마스터 정책 파일은 한번에 전체 호스트의 문제를 해결해야 합니다.

소켓 마스터 정책 파일 제공 방법

1. 사용 가능한 소켓 메타 정책 목록을 검토한 다음 호스트에 적합한 소켓 메타 정책을 선택합니다.
2. 소켓 마스터 정책 파일을 작성하여 원하는 소켓 메타 정책과 부여하려는 모든 권한을 선언합니다. 한 가지 예를 들어보겠습니다.

3. 소켓 정책 파일 서버의 정보 페이지를 검토하여 소켓 정책 파일 서버 설치 방법을 결정합니다.
4. 호스트에서 소켓 정책 파일 서버를 실행하여 이 서버에 작성한 소켓 마스터 정책 파일을 제공합니다.

Flash Player 9,0,115,0에서 도입된 두 가지 보안 변경 사항은 Flash Player가 HTTP 응답 헤더에 액세스할 때에만 실행됩니다. Flash Player가 브라우저 내에서 실행되고 있는 경우 일부 브라우저에서는 Flash Player에 HTTP 응답 헤더를 제공하지 않으므로 항상 변경 사항이 실행되는 것은 아닙니다.

HTTP 응답 헤더 액세스를 필요로 하는 두 가지 기능은 다음과 같습니다.

• Content-Type 허용 목록: Flash Player가 HTTP 응답 헤더에 액세스할 때 Flash Player는 비텍스트 형식의 Content-Type 값을 가진 HTTP 정책 파일을 거부할 뿐만 아니라 Content-Type 값을 전혀 가지고 있지 않은 파일도 거부합니다. Flash Player가 HTTP 응답 헤더에 액세스하지 않을 때 Flash Player는 Content-Type 값에 상관없이 HTTP 정책 파일을 채택합니다.
• HTTP 메타 정책: Flash Player가 HTTP 응답 헤더에 액세스할 때 Flash Player는 마스터 HTTP 정책 파일에서 선언된 HTTP 메타 정책과 X-Permitted-Cross-Domain-Policies 응답 헤더를 채택합니다. Flash Player가 HTTP 응답 헤더에 액세스하지 않을 때 모든 HTTP 서버에는 all의 메타 정책이 적용됩니다.

표 1은 Adobe에서 HTTP 응답 헤더를 확인하기 위해 테스트한 브라우저 목록입니다.

이 섹션에서는 정책 파일 로그인 crossdomain.xml에서 볼 수 있는 메시지를 소개합니다. 로깅 섹션에서 설명한 바와 같이, 이러한 메시지 중 일부 메시지에는 앞에 [strict]가 표시되어, 해결되지 않은 2단계의 문제에 대한 경고 메시지가 아니라 1단계의 즉시 해결되어야 하는 문제를 의미합니다. 자세한 내용은 즉시 해결해야 하는 문제 섹션을 참조하십시오.

SWF 로드 메시지

해당 URL에서 최상위 SWF 파일이 로드되었습니다. 이는 로그의 첫 번째 메시지가 되며, append-mode logging을 활성화한 경우 1회 이상 이러한 메시지가 표시될 수 있습니다. 이 메시지는 로그를 생성한 Flash Player 세션을 시작한 SWF 파일을 알고 있으므로, 이후 메시지를 파악하는 데 도움이 됩니다.

정책 파일에 의한 요청 메시지

정책 파일의 권한이 필요한 작업을 SWF 파일에서 시도했고, 이 작업에 대한 권한을 부여한 정책 파일이 발견되었습니다. 이 메시지의 URL은 SWF 파일이 요청한 리소스, SWF 파일이 로드된 위치, 그리고 권한이 부여된 정책 파일에 대한 정보를 제공합니다. 여러 개의 정책 파일이 이 작업에 대한 권한을 부여했을 수도 있지만 이러한 유형의 로그 메시지에서는 한 개의 정책 파일만 언급됩니다.

SWF 파일은 소켓 연결을 시도했지만 현재 소켓 서버에 연결할 수 없습니다. 이 메시지의 URL은 SWF 파일이 연결을 시도한 서버와 포트, 그리고 SWF 파일이 로드된 위치에 대한 정보를 제공합니다. 보안상의 이유로 ActionScript에서 SWF 파일은 서버에 연결되는 것처럼 동일한 오류 메시지를 수신하게 되지만 이 작업의 경우 어떠한 권한도 부여되지 않았습니다. ActionScript 3.0에서는 이 메시지가 securityError 이벤트에 해당됩니다.

정책 파일의 권한이 필요한 작업을 SWF 파일이 시도했지만 이러한 작업을 허용한 유효한 정책 파일을 찾을 수 없습니다. 이 메시지의 URL은 SWF 파일을 요청한 리소스와 SWF 파일이 로드된 위치에 대한 정보를 제공합니다.

특정 문제가 발생한 것이 아니라 필수 단계가 수행되지 않았음을 나타내므로 이 메시지는 여러 가지 이유로 표시될 수 있습니다. 일부의 경우 이 메시지 앞에 보다 구체적인 다른 메시지가 표시되기도 하는데, 이러한 메시지는 이 최종 실패 메시지가 표시되기 전에 더 많은 정보를 제공합니다. 가능한 원인으로는 다음이 있습니다.

• 이러한 작업을 승인할 수 있는 적용 가능한 정책 파일이 없습니다. 리소스가 위치하고 있는 서버를 제어하는 경우 이 서버에 정책 파일을 추가해야 할 수도 있습니다. 그렇지 않으면 SWF 파일의 고유 서버를 통해 해당 작업을 대신해야 할 수 있습니다.
• 적용 가능한 정책 파일이 있지만 현재 정책 파일과 리소스가 위치한 서버에 연결이 되지 않습니다. 서버 호스트에 핑(ping)을 시도하여 연결할 수 있는지 확인합니다. SWF 파일이 allowDomain을 호출하여 적용 가능한 정책 파일을 로드했다면 이 메시지는 일반적으로 "Failed to load policy file from (URL)" 메시지 뒤에 오게 됩니다. 소켓 연결 시 이 경우("...because the server cannot be reached")가 아니라 이전에 목록으로 표시된 메시지를 확인해야 하지만 다른 요청을 받은 경우에는 이 메시지를 참조해야 합니다.
• 적용 가능한 정책 파일이 있지만 SWF 파일의 특정 도메인에 액세스할 수 있는 권한을 부여하지 않습니다. 기존 정책 파일에 표시된 SWF 파일의 도메인을 받아 SWF 파일을 기존 정책 파일에 의해 승인된 도메인으로 옮기고, 새로운 정책 파일을 추가하거나 SWF 파일의 고유 서버를 통해 해당 요청을 대신합니다.
• 적용 가능한 정책 파일이 있지만 기본 위치가 아닌 다른 위치에 있고, 이 작업을 시도 중인 SWF 파일은 정책 파일의 위치를 Flash Player에 알리기 위해 allowDomain을 호출하지 않았습니다. SWF 파일에서 allowDomain을 호출합니다.
• 적용 가능한 정책 파일이 있지만 유효하지 않습니다. 이 경우 이 메시지 앞에는 정책 파일 URL과 발견된 문제를 보여주는 보다 구체적인 메시지가 있어야 합니다. 자세한 내용은 정책 파일 로드 실패에 대한 메시지 섹션을 참조하십시오.

SWF 파일이 자체 도메인 외부에서 소켓 연결을 시도했으며, 이 연결을 승인하기 위해 검색된 유일한 정책 파일은 동일한 호스트의 HTTP 마스터 정책 파일이었습니다. 소켓 연결을 승인하는 HTTP 정책 파일의 구성은 1단계에서 사용되지 않습니다. 이 특정 HTTP 정책 파일은 메타 정책을 선언하는데, 이는 다시 말해 서버가 HTTP 정책 파일이 소켓 연결을 승인하지 않는 2단계 규칙을 적용하고 있음을 의미합니다. 자세한 내용은 엄격한 소켓 규칙 섹션을 참조하십시오. 연결이 시도되고 있는 호스트를 제어하는 경우 포트 843에 소켓 마스터 정책 파일 서버를 추가하거나 기본 연결 서버에서 소켓 정책 파일을 제공하도록 합니다. 두 가지 방법 중 아무것도 하지 못하는 경우 SWF 고유 서버를 통해 소켓 연결을 대신합니다.

SWF 파일이 Flash Player가 실행 중인 컴퓨터에 속하는 IP 주소에 소켓 연결을 시도했지만 이 작업을 승인할 수 있는 소켓 정책 파일이 없습니다. 엄격한 정책 파일 규칙은 소켓 정책 파일의 권한이 있어야만 소켓을 연결할 수 있습니다. 대부분의 소켓 연결의 경우 1단계에서 이 변경 사항이 적용되면 경고 메시지만 표시되지만, 로컬 IT 주소 연결의 경우에는 1단계서도 엄격한 규칙이 적용됩니다. 자세한 내용은 엄격한 소켓 규칙 선택 섹션을 참조하십시오. 이 문제를 해결하려면 로컬 시스템에 소켓 정책 파일 서버를 추가하거나, SWF 파일을 변경하여 ActionScript에서 소켓 연결 시 로컬 시스템을 다른 이름이 아닌 "localhost"로 명시적으로 지칭해야 합니다. "localhost" 사용은 2단계가 아니라 1단계에서만 작동하므로 가능한 로컬 소켓 정책 파일 서버를 마련해 두는 것이 좋습니다.

1단계에서 사용하지 않는 구성 메시지

이 메시지는 Flash Player가 메타 정책을 아직 지정하지 않은 HTTP, HTTPS 또는 FTP 서버에서 정책 파일을 획득할 때 표시되는 매우 일반적인 메시지입니다. Flash Player 9,0,115,0이 출시되기 전에는 메타 정책이 없었으므로 출시된 후부터는 거의 모든 서버에 이 메시지가 표시됩니다. 1단계에서 이 메시지는 이 서버가 2단계 버전의 Flash Player가 출시될 때 메타 정책을 선택해야 하거나 Flash 컨텐츠가 작동하지 않을 수 있음을 알려주는 경고 메시지에 불과합니다. 자세한 내용은 메타 정책 섹션을 참조하십시오.

SWF 파일이 고유 도메인에 소켓 연결을 시도했지만 이 작업을 승인하는 정책 파일이 없습니다. 엄격한 정책 파일 규칙은 소켓 연결이나 SWF 파일의 고유 도메인에 연결하기 위해 소켓 정책 파일의 권한이 필요합니다. 1단계에서 이 메시지는 이 서버가 2단계 버전의 Flash Player가 출시될 때 메타 정책을 선택해야 하거나 Flash 컨텐츠가 작동하지 않을 수 있음을 알려주는 경고 메시지에 불과합니다. 자세한 내용은 소켓 정책 파일 섹션을 참조하십시오. 권장된 방법은 포트 843에 소켓 마스터 정책 파일 서버를 추가하는 것입니다.

SWF 파일이 소켓 연결을 시도했으며, 이 작업 승인을 위해 검색된 유일한 정책 파일은 소켓 서버와 동일한 도메인에 있는 HTTP 정책 파일이었습니다. 엄격한 정책 파일 규칙은 소켓 정책 파일의 권한이 있어야만 소켓을 연결할 수 있습니다. 그러나 1단계에서 소켓 연결을 승인하는 HTTP 정책 파일의 이전 시스템은 다음 경고 메시지가 표시되어도 계속 사용할 수 있습니다. 2단계를 준비하기 위해 소켓 정책 파일 서버를 소켓 연결과 동일한 호스트 이름에서 사용할 수 있어야 합니다. 자세한 내용은 소켓 정책 파일 섹션을 참조하십시오. 권장된 방법은 포트 843에 소켓 마스터 정책 파일 서버를 추가하는 것입니다.

플랫폼 경고 메시지

Flash Player에서 HTTP 요청을 했지만 HTTP 응답 헤더가 없습니다. 메타 정책 섹션에서 설명한 바와 같이, 보다 엄격해진 새로운 정책 파일 규칙 중 일부 규칙에서는 서버의 Content-Type 및 X-Permitted-Cross-Domain-Policies 정보가 알려지도록 Flash Player에서 HTTP 응답 헤더에 액세스할 것을 요구합니다. 서버에서는 어떠한 메타 정책 정보도 제공되지 않습니다. 정확한 효과 목록과 이 비헤이비어를 일으키는 브라우저 구성 목록은 브라우저 의존성 부록을 참조하십시오. 이 경고 메시지는 이전에 작동하던 컨텐츠가 작동하지 않을 수 있음을 의미하는 것이 아니라, 보다 엄격해진 새로운 규칙을 실행할 수 없어 서버와 사용자의 보안 수준이 낮아질 수 있음을 의미합니다. 가장 많이 사용되는 브라우저의 최신 버전에서는 Flash Player에 HTTP 응답 헤더가 표시되므로 브라우저를 업그레이드하면 이 메시지가 제거됩니다.

성공적인 정책 파일 로드 메시지

해당 URL에서 정책 파일이 성공적으로 로드되어 모든 유효성 검사를 통과하여 Flash Player에 의해 채택되었습니다. 이제 정책 파일의 모든 <allow-access-from> 지시문이 적용됩니다. SWF 파일이 loadPolicyFile을 호출하여 정책 파일을 명시적으로 요청했기 때문에 이 정책 파일이 로드되었을 수도 있고, Flash Player의 기본 정책 파일 규칙에 의거하여 자동으로 정책 파일이 인식되었을 수 있습니다.

정책 파일 로드 시 경고 메시지

Flash Player는 HTTP 정책 파일을 요청했으며, 처음 요청은 동일한 도메인의 다른 위치로 리디렉션되었습니다. 리디렉션 섹션에서 설명한 바와 같이, 9,0,115,0 버전부터 Flash Player는 동일한 도메인 내에서 리디렉션되는 URL에서 획득한 HTTP 정책 파일의 해석을 변경합니다. 9,0,115,0 이전 버전의 Flash Player에서는 정책 파일이 처음으로 요청되었던 URL에서 발생된 것처럼 리디렉션된 정책 파일을 처리했지만, 9,0,115,0 버전부터는 정책 파일이 리디렉션된 후의 최종 URL에서 발생된 것처럼 리디렉션된 정책 파일을 처리합니다. 그 차이는 액세스를 허용하는 리소스 세트를 규정하는 정책 파일의 범위에 영향을 미칠 수 있다는 것입니다. 이러한 경고 메시지가 표시되면 로그를 쭉 살펴보면서 이 정책 파일을 사용하는 모든 요청이 계속 진행 중인지 확인하십시오. 진행되고 있지 않으면 처음으로 요청된 URL에 리디렉션되지 않은 정책 파일을 추가해야 할 수도 있습니다. 또한 SWF에서 loadPolicyFile 호출을 추가하거나 변경해야만 새로운 정책 파일 URL을 사용할 수 있는 다른 URL에 리디렉션되지 않은 정책 파일을 배치할 수도 있습니다. 어떠한 경우에라도 정책 파일 디버깅이 더 어려워지기 때문에 정책 파일 요청 리디렉션을 방지해야 합니다.

Flash Player는 해당 URL에서 HTTP 정책 파일을 검색하여 HTTP 헤더와 이 도메인의 마스터 정책 파일에서 메타 정책을 살펴보았지만 메타 정책을 찾지 못했습니다. 그러나 정책 파일이 text/x-cross-domain-policy의 Content-Type 값과 함께 반환되었습니다. 이는 이 서버의 관리자가 메타 정책을 지원하기 위해 의도적으로 변경 사항을 적용했음을 나타냅니다. HTTP 정책 파일에 대한 공식 Content-Type 값은 이 도메인에서 사용 중이므로 Flash Player는 이 도메인에 by-content-type의 메타 정책을 적용합니다. 자세한 내용은 메타 정책 지정 방법 섹션을 참조하십시오. 명확하게 하기 위해 이 서버에서 이 암시적인 메커니즘을 사용하지 않고 메타 정책을 명시적으로 선언할 것을 권장합니다. 마스터 정책 파일에 <site-control> 태그를 사용하거나 HTTP 응답 헤더 X-Permitted-Cross-Domain-Policies를 사용하여 메타 정책을 명시적으로 선언할 수 있습니다.

Flash Player는 기본적으로 (포트 843 또는 연결 시도와 동일한 포트에서) 소켓 정책 파일을 요청합니다. 이는 9,0,115,0 이전 버전에서는 불가능했던 작업입니다. 소켓 정책 파일을 요청하는 이유는 엄격한 규칙의 경우 소켓 연결을 승인하려면 항상 소켓 정책 파일을 사용하도록 마이그레이션해야 하기 때문입니다. 자세한 내용은 소켓 정책 파일 섹션을 참조하십시오. 이 경고 메시지는 그 자체로는 아무런 문제점을 나타내지 않지만 차후 경고 또는 오류가 발생하는 경우 그 해결책을 제시할 수 있습니다. 미미하지만 서버가 전혀 예상하지 않은 소켓 정책 파일 요청과 혼동될 우려가 있으므로 Flash Player는 이 소켓 정책 파일 요청에 대해 경고 메시지를 표시합니다.

Flash Player는 기본적으로 (포트 843 또는 연결 시도와 동일한 포트에서) 소켓 정책 파일을 요청했으나 소켓 정책 파일 요청은 성공하지도 않았고 실패하지도 않았습니다. Flash Player가 연락을 시도했지만 서버는 3초 내에 응답하지 않았습니다. 이 메시지는 서버에 정책 파일 요청이 수신되지 않을 것으로 예상되거나 클라이언트 및 서버 간의 네트워크 문제로 인해 표시될 수 있습니다. Flash Player에서 기본적으로 소켓 정책 파일을 요청할 때 서버 리소스 사용을 제한하거나 문제에 대한 클라이언트측 통보가 지연되지 않게 하려면 3초 내에 응답을 받아야 합니다. 자세한 내용은 소켓 정책 파일 섹션을 참조하십시오. 이 경고 메시지는 두 가지 의미를 내포합니다. 첫째는 기본적으로 Flash Player가 확인하는 첫 번째 위치가 되는 포트 843에 소켓 정책 파일 서버를 설치해야 한다는 것이고, 둘째는 ActionScript에서 소켓 정책 파일의 위치를 표시하기 위해 loadPolicyFile을 호출하여 Flash Player에 보다 명시적인 지침을 제공해야 한다는 것입니다. Flash Player가 기본적으로 위치를 확인하도록 허용하는 대신 loadPolicyFile을 호출하면 Flash Player는 3초 후에 종료되지 않고 필요한 만큼 오랫동안 소켓 정책 파일 서버의 응답을 기다리게 됩니다. 이러한 방법은 안정적이지 않은 네트워크 환경에서 애플리케이션의 안정성을 향상시키는 데 도움을 줄 수 있습니다. 따라서 기본 소켓 정책 파일 위치의 경우에도 Flash Player에서 소켓 정책 파일 서버가 응답할 때까지 인내심을 갖고 기다려줄 것을 요청하려면 loadPolicyFile을 호출하는 것이 도움이 될 수 있습니다.

정책 파일 로드 실패 메시지

Flash Player가 해당 URL에서 정책 파일 검색을 시도했지만 오류가 발생했습니다. 이러한 오류는 네트워크에 문제가 발생했거나, 서버가 이 위치에서 실행되지 않았거나, 또는 서버는 실행되고 있지만 요청한 위치를 인식하지 못한 경우(예: HTTP 404 오류) 발생할 수 있습니다. 이 메시지는 Flash Player가 기본적으로 요청한 소켓 정책 파일 위치에 대한 것이 아니라, Flash Player가 기본적으로 요청한 HTTP/HTTPS/FTP 위치에 대한 경고 메시지로서, loadPolicyFile에 전달된 위치에 대한 오류가 발생할 때 표시됩니다.

Flash Player가 해당 URL에서 정책 파일을 검색했지만 정책 파일에 잘못된 구문이 포함되어 있습니다. 이 정책 파일은 무시되었고 앞으로 어떠한 작업도 승인하지 않습니다. 적합한 구문이 실행되는 이유와 이러한 오류를 일으킬 수 있는 잘못된 구문의 일반적인 유형에 대한 내용은 잘못된 형식의 정책 파일 섹션을 참조하십시오. 이 정책 파일을 유지 관리하는 사람은 최대한 신속하게 잘못된 구문을 수정해야 합니다. 이 규칙은 Flash Player 버전 9,0,47,0의 1단계 버전이 출시되기 이전부터 적용된 것입니다.

Flash Player는 해당 URL에서 HTTP 정책 파일을 검색했지만 정책 파일의 HTTP Content-Type은 정상적인 정책 파일과 일치하지 않은 것으로 나타났습니다. 이 서버를 보호하기 위해 이 정책 파일은 무시되었고 앞으로 어떠한 작업도 승인하지 않습니다. 자세한 내용은 Content-Type 허용 목록 섹션을 참조하십시오. 이 정책 파일을 유지 관리하는 사람은 최대한 신속하게 적합하지 않는 Content-Type 값을 변경해야 합니다.

위에서 말한 오류와 유사하지만 Flash Player는 Content-Type을 전혀 발견하지 못했습니다.

Flash Player는 첫 번째 해당 URL에서 정책 파일 검색을 시도했지만 다른 도메인에 있는 두 번째 해당 URL로 리디렉션되었습니다. 이는 이전부터 계속 금지된 작업입니다. 이 정책 파일은 무시되었고 앞으로 어떠한 작업도 승인하지 않습니다.

Flash Player는 해당 URL에서 정책 파일을 검색했지만 마스터 정책 파일의 <site-control> 태그 또는 X-Permitted-Cross-Domain-Policies HTTP 헤더 중 한 곳에서 해당 정책 파일 서버에 대한 메타 정책을 발견했습니다. 이 표시된 메타 정책은 이 파일이 유효한 정책 파일이 되는 것을 명시적으로 금하고 있으므로, 이 정책 파일은 무시되었고 앞으로 어떠한 작업도 승인하지 않습니다. 이 메시지 자체가 문제가 되는 것은 아니지만 이 정책 파일을 유효한 정책 파일로 만들려면 정책 파일의 Content-Type 또는 FTP 파일 이름을 변경하거나 메타 정책을 변경해야 합니다.

Flash Player는 해당 URL에서 HTTP 정책 파일을 검색했지만 서버로부터 이 HTTP 응답이 정책 파일로 사용하도록 승인되지 않음을 나타내는 HTTP 응답 헤더 X-Permitted-Cross-Domain-Policies: none-this-response를 발견했습니다. 이 메시지는 서버 스크립트에서 정책 파일을 생성하는 것을 방지하기 위해 사용됩니다. 자세한 내용은 소켓 메타 정책 섹션을 참조하십시오. 이 정책 파일은 무시되었고 앞으로 어떠한 작업도 승인하지 않습니다. 이 서버를 제어하고 있고 작업을 승인하기 위해 이 정책 파일이 필요한 경우, 서버 구성을 변경하여 none-this-response 헤더가 생성되지 않도록 해야 합니다.

Flash Player는 표시된 위치에서 소켓 정책 파일 검색 프로세스를 시작했지만 너무 많은 데이터가 수신되었기 때문에 다운로드를 중단했습니다. 이 정책 파일은 무시되었고 앞으로 어떠한 작업도 승인하지 않습니다. 이 방법은 서버를 보호하기 위한 것입니다. Flash Player는 대용량 정책 파일을 예상하지 않기 때문에 대용량 정책 파일 다운로드를 중단하여 오류로 판단되는 경우에 서버를 로드하는 것을 방지합니다. 이 파일이 유효한 소켓 정책 파일인 경우 20K 미만이 되도록 파일 크기를 줄입니다.

메타 정책의 구성 오류 메시지

잘못된 메타 정책은 해당 URL의 X-Permitted-Cross-Domain-Policies HTTP 헤더에 지정되었습니다. 이 메타 정책은 무시되었습니다. 이는 구성 오류이므로, 서버에서 수정되어야 합니다. 자세한 내용은 메타 정책 섹션을 참조하십시오.

해당 URL에 있는 마스터 정책 파일의 <site-control> 태그에 잘못된 메타 정책이 지정되었습니다. 이 메타 정책은 무시되었지만, 정책 파일 자체가 무시된 것은 아닙니다(정책 파일 자체가 무시된 경우라면 오류 메시지가 표시되어야 합니다). 이 정책 파일의 컨텐츠를 제어하는 사람은 <site-control> 태그를 수정하여 유효한 메타 정책 이름이 포함되도록 해야 합니다. 자세한 내용은 메타 정책 섹션을 참조하십시오.

해당 URL에 있는 하나 이상의 X-Permitted-Cross-Domain-Policies HTTP 헤더에서 여러 개의 메타 정책이 서로 충돌했습니다. 서버에서 수신되는 대로 메타 정책의 전체 문자열이 표시됩니다. 여러 개의 X-Permitted-Cross-Domain-Policies 헤더가 제공된 경우 HTTP 헤더처럼 세미콜론으로 구분한 값을 사용해 단일 헤드로 통합되었습니다. Flash Player는 이 문자열에서 발견된 메타 정책 중에서 가장 제한적인 메타 정책을 적용했습니다. 이는 구성 오류이므로 서버에서 수정되어야 합니다. 일반적으로 HTTP 응답 헤더에서 여러 개의 메타 정책을 제공하는 것은 불법입니다. 유일하게 이 조항에서 제외되는 것은 none-this-response인데, 이는 다른 메타 정책과 결합될 수 있지만 메타 정책이 발견된 개별 HTTP 응답에만 영향을 줍니다. 자세한 내용은 메타 정책 섹션을 참조하십시오.

Flash Player는 해당 URL의 서버에서 일치하지 않는 메타 정책 선언을 발견했습니다. Flash Player는 이 서버에서 발견된 메타 정책 중에서 가장 제한적인 메타 정책을 적용했지만, 덜 제한적인 메타 정책이 처음으로 발견되었다면, 이 메타 정책이 차후 충돌이 발견될 때까지 당분간 실행될 수 있습니다. 이는 구성 오류이므로 서버에서 수정되어야 합니다. 자세한 내용은 메타 정책 섹션을 참조하십시오.

위의 오류와 비슷하지만 메타 정책 파일 충돌이 HTTP 헤더가 아니라 <site-control> 태그에서 발견되었습니다.

Flash Player는 마스터 정책 파일이 아니라 해당 URL에 있는 정책 파일에서 <site-control> 태그를 발견했습니다. <site-control> 태그는 무시되었지만 정책 파일 자체가 무시된 것은 아닙니다(정책 파일 자체가 무시된 경우라면 오류 메시지가 표시되어야 합니다). <site-control> 태그는 마스터 정책 파일에서만 적법합니다(HTTP/HTTPS/FTS 서버의/crossdomain.xml 또는 포트 843의 소켓 정책 파일). 이 서버 제어를 담당하고 있는 사람은 이 정책 파일에서 <site-control> 태그를 삭제하여 이 서버에서 다른 방법(마스터 정책 파일 또는 HTTP 응답 헤더)으로 유효한 메타 정책을 선언하도록 해야 합니다. 자세한 내용은 메타 정책 섹션을 참조하십시오.

Flash Player는 HTTP 또는 HTTPS 서버에서 발생하지 않은 정책 파일에 by-content-type의 메타 정책을 지정하여 해당 URL에 있는 마스터 정책 파일에서 <site-control> 태그를 발견했습니다. <site-control> 태그는 무시되었지만 정책 파일 자체가 무시된 것은 아닙니다(정책 파일 자체가 무시된 경우라면 오류 메시지가 표시되어야 합니다). by-content-type의 메타 정책은 FTP 서버나 소켓 서버에서 제공되지 않는 Content-Type 헤더를 사용하기 때문에 HTTP 및 HTTPS 서버의 경우에만 유효합니다. 이 서버를 제어하는 사람은 이 서버에 대해 유효한 메타 정책을 선택해야 합니다. 자세한 내용은 메타 정책 섹션을 참조하십시오.

Flash Player는 by-ftp-filename의 메타 정책을 지정하여 해당 URL에서 정책 파일을 검색하다가 X-Permitted-Cross-Domain-Policies HTTP 응답 헤더를 발견했습니다. X-Permitted-Cross-Domain-Policies 헤더는 무시되었지만 이 URL의 모든 정책 파일이 무시된 것은 아닙니다(정책 파일 자체가 무시된 경우라면 오류 메시지가 표시되어야 합니다). by-ftp-filename의 메타 정책은 FTP 서버에서만 유효합니다. 이 서버를 제어하는 사람은 이 서버에 대해 유효한 메타 정책을 선택해야 합니다. 자세한 내용은 메타 정책 섹션을 참조하십시오.

위의 오류와 비슷하지만 잘못된 메타 정책이 HTTP 헤더가 아니라 <site-control> 태그에서 발견되었습니다.

Flash Player는 정책 파일에서 none-this-response의 메타 정책을 지정하여 해당 URL에 있는 마스터 정책 파일에서 <site-control> 태그를 발견했습니다. <site-control> 태그는 무시되었지만 정책 파일 자체가 무시된 것은 아닙니다(정책 파일 자체가 무시된 경우라면 오류 메시지가 표시되어야 합니다). HTTP 서버는 서버 스크립트에서 정책 파일 생성을 방지할 수 있는 메커니즘으로만 사용되기 때문에 none-this-response의 메타 정책은 X-Permitted-Cross-Domain-Policies HTTP 응답 헤더에서만 유효합니다. 이 서버를 제어하는 사람은 이 서버에 대해 유효한 메타 정책을 선택해야 합니다. 자세한 내용은 메타 정책 섹션을 참조하십시오.

Flash Player는 none 메타 정책을 지정하여 해당 URL에 있는 마스터 정책 파일에서 <site-control> 태그를 발견했고, 동일한 정책 파일에서 <allow-access-from> 지시문도 발견했습니다. none으로 선언된 메타 정책은 이 서버에서 실행되어야 합니다. 다시 말해 이 서버에서는 마스터 정책 파일 자체를 비롯해 다른 정책 파일은 허용되지 않습니다. 마스터 정책 파일은 메타 정책을 선언하는 데만 사용됩니다. 마스터 정책 파일에 <allow-access-from> 지시문이 포함되어 있으므로 이 지시문은 무시됩니다. 이 서버를 제어하는 사람은 이 정책 파일에서 <allow-access-from> 지시문을 삭제해야 합니다. 자세한 내용은 메타 정책 섹션을 참조하십시오.

정책 파일의 구성 오류 메시지

Flash Player는 해당 URL에서 secure="true" 또는 secure="false" 속성을 지정한 한 개 이상의 <allow-access-from> 지시문이 포함된 정책 파일을 발견했지만, 이는 HTTPS 정책 파일도, 소켓 정책 파일도 아닙니다. secure 속성은 무시되었지만 <allow-access-from> 지시문은 무시된 것은 아닙니다(지시문이 무시된 경우라면 오류 메시지가 표시되어야 합니다). Flash Player에 <allow-access-from> 지시문에서 명명된 도메인의 강력한 인증(예: HTTPS URL 전용)을 요구할 것인지 여부를 지시하는 secure 속성은 HTTPS 정책 파일과 소켓 정책 파일에서만 합법적입니다. 이 규칙은 정책 파일이 처음 도입된 이후 계속 시행되고 있습니다. 이는 정책 파일 자체가 부정 변경 방지(tamper-resistent) 프로토콜을 통해 전송되지 않으므로 위장(man-in-the-middle) 공격자가 secure="true" 선언을 secure="false"로 변경하여 이 정책 파일에서 명시된 정책과 반대로 비 HTTPS SWF 파일이 이 도메인에서 데이터를 검색할 수 있도록 허용할 수 있기 때문입니다. 이 서버를 제어하는 사람은 이 정책 파일에서 secure 속성을 삭제해야 합니다.

Flash Player는 secure="true" 또는 secure="false" 속성을 지정한 한 개 이상의 <allow-access-from> 지시문이 포함된 소켓 정책 파일을 해당 URL에서 발견했지만, 이 소켓 정책 파일은 로컬 시스템에서 발생한 것이 아닙니다. secure 속성은 지정한 대로 실행되어야 하지만 이 소켓 정책 파일이 로컬 시스템이 아닌 다른 곳에서 발생한 경우 안전하지 않은 구성을 갖게 될 수 있습니다. Flash Player에 <allow-access-from> 지시문에서 명명된 도메인의 강력한 인증(예: HTTPS URL 전용)을 요구할 것인지 여부를 지시하는 secure 속성은 로컬 시스템에서 제공되는 소켓 정책 파일에서 유효합니다. 이는 위장(man-in-the-middle) 공격자가 다른 정책 파일을 대체할 수 있는 네트워크 전송이 없기 때문입니다. 그러나 소켓 정책 파일이 원격 호스트에서 제공되는 경우 소켓 정책 파일이 위장(man-in-the-middle) 공격에 취약한 방식으로 전송되기 때문에 secure="true"를 지정하면 잘못된 보안을 제공할 수 있습니다. Flash Player는 아직 안전한 채널을 통해 소켓 정책 파일을 검색할 수 있는 방법을 제공하고 있지 않습니다. 자세한 내용은 소켓 정책 파일 섹션을 참조하십시오.

정책 파일 구문 분석 오류 메시지

Flash Player는 해당 URL에서 <allow-access-from> 지시문의 domain 속성에 대한 값으로 해당 문자열을 포함하는 정책 파일을 발견했습니다. 이 문자열은 유효한 도메인으로 인식되지 않았습니다. 동일한 정책 파일의 다른 지시문이 유효하여 채택될 수 있음에도 불구하고 이러한 특정 <allow-access-from> 지시문은 무시됩니다. 이 정책 파일을 제어하는 사람은 잘못된 도메인을 수정해야 합니다.

Flash Player는 해당 URL에서 <allow-access-from> 지시문의 to-ports 속성에 대한 값으로 해당 문자열을 포함하고 있는 정책 파일을 발견했습니다. 이 문자열은 유효한 포트 범위로 인식되지 않았습니다. 포트 범위에는 와일드 카드(*), 개별 포트 번호, 대시로 구분된 포트 범위 또는 쉼표로 구분된 개별 번호 및/또는 범위 목록이 포함될 수 있습니다. 동일한 정책 파일의 다른 지시문이 유효하여 채택될 수 있음에도 불구하고 이러한 특정 <allow-access-from> 지시문은 무시됩니다. 이 정책 파일을 제어하는 사람은 잘못된 포트 범위를 수정해야 합니다.