Flash는 다양한 보안모델을 가진다. 보안모델에 따라 동작하지 않는 경우에는 Flash Player는 여지없이 Security Error를 발생시킨다. 이러한 보안모델이 있으면 개발할 때는 난해하지만 사용자 입장 및 서버 관리자 입장에서 보안문제를 적절히 처리할 수 있기 때문에 안심하고 Flash 어플리케이션을 사용할 수 있는 것이다.

Flash Player 보안에 관련된 것은 다음 글을 보면 자세히 나온다.

Flash Player 보안


각설하고...
SWF파일과 그것을 감싸는 HTML이 동일한 도메인에 위치하는 경우에는 <object>및 <embed> 태그에 allowScriptAccess 매개변수값을 sameDomain이나 always를 지정하는 것만으로 SWF에 ExternalInterface.addCallback() 함수로 자신내부의 메소드를 호출할 수 있게끔 되어 있는 경우 보안상 아무 문제없이 HTML에서 SWF의 메소드를 호출할 수 있다. 다음글을 참고해 보자.

아웃바운드 URL 액세스 제어

하지만 SWF파일과 HTML이 동일한 도메인에 위치하지 않은 경우에는 Flash Player 보안이 더욱 강화된다. allowScriptAccess 매개변수를 기본적으로 allowScriptAccess="always"로 지정해야 하는 것 외에 다른 보안 설정이 필요하다. 그것은 SWF에 Security.allowDomain()  메소드가 가능하게 한다.

SWF가 domain1.com에 있고 HTML이 domain2.com에 있다고 할 때 HTML에서 SWF내에서 ExternalInterface.addCallback()으로 외부접근을 허락한 메소드를 접근하려면 SWF에  Security.allowDomain("domain2.com");을 지정해 주어야 한다. 이 말은 이 SWF는 domain2.com에 있는 HTML에서 접근하는 것을 허락한다는 것을 의미한다.

어떤 도메인에 있던지 SWF 내부의 메소드 접근을 항상 허용하려면 Security.allowDomain("*") 로 지정하면 된다. 하지만 이것은 보안상 좋지 않는 방법이다.

서로 다른 도메인에 있는 SWF와 HTML에 대해서 이런 보안이 있는 이유는 명료하다. 내가 배포한 SWF에 정의된 함수를 HTML에서 접근할 수 있도록 ExternalInterface.addCallback()을 정의했는데, 다른 사람이 다른 도메인에서 이것을 악용할 소지가 있을 수 있기 때문이다.

일반서비스인 domain.com과 파일서버인 file.domain.com을 보자. 두개다 domain.com을 사용하지만 domain.com은 file.domain.com의 슈퍼도메인이다.  이는 Flash Player 6 이전에는 같은 것으로 인식했으나 Flash Player 7이상으로 되면서 다른 도메인으로 인식하게 되었다. 이렇게 된 것은 보안상 문제로 보안정책의 변경이 필요했기 때문이다. file.domain.com에 어떤 사용자가 악성 스크립트를 심은 swf를 업로드 했다고 가정하자. 이때 domain.com과 file.domain.com을 동일하게 인식해버리면 이 swf는 domain.com에 마음대로 접근이 가능해진다. 그래서 flash player는 file.domain.com과 domain.com을 다르게 인식하는 것이다. 이것은 crossdomain정책과 같다.

더 자세한 내용은 다음 글을 참고한다.

Security.allowDomain()에 대해

아쉬운 것은 Security.allowDomain("*.domain.com") 식의 지정이 안된다는 것이다.  crossdomain.xml 설정시에는 와일드카드(*)를 *.domain.com 형태로 사용할 수 있지만 Security.allowDomain()에서 안되는 것은 이외다.

개인적으로 개발환경과 테스트환경, 배포환경이 모두 다르기 때문에 와일드카드 지원이 있으면 좀 편할텐데 하는 아쉬움이 남는다.

글쓴이 : 지돌스타(http://blog.jidolstar.com/675 )



+ Recent posts