2 Results for 'Network'

  1. 2008.06.29 [MSDN] 네트워크 보안 접근 제약 (1)
  2. 2008.03.07 [Silverlight/MSDN] URL Access Policy

※ 이 문서는 MSDN의 Network Security Access Restrictions in Silverlight 2를 번역한 것으로 실버라이트 2 베타 2를 기준으로 합니다. 추후 정책이 변경될 경우 새로 포스팅하겠지만 기본적으로는 위의 문서를 참고하세요.

※ 번역 실력이 일천하여 흐름에 크게 중요하지 않은 부분은 생략을 했습니다.

실버라이트 버전 2 런타임은 원격 호스트에 접속하는 네트워킹 애플리케이션을 위한 두 개의 중요한 수단을 지원합니다.

  • System.Net 네임스페이스에 있는 WebClient와 Http 클래스들 - 이 클래스들은 네트워크 통신을 위해 HTTP 또는 HTTPS 프로토콜을 사용합니다.
  • System.Net.Sockets 네임스페이스에 있는 Soket 클래스들 - 이 클래스들은 더욱 범용적인 네트워크 통신을 위해 사용할 수 있는 저수준의 소켓을 제공합니다.

양쪽 모두 보안과 인증되지 않은 접속을 초기화에 대한 보호를 제공할 필요가 있습니다. 다음과 같은 잠재적인 네트워킹 위협은 억제되어야 합니다.

  • 서비스 거부(DoS ; Denial of Service) 공격 - 다수의 원격 호스트가 타겟 사이트를 공격하여 타겟은 정상적인 요청에 대한 서비스를 수행할 수 없게 됩니다.
  • DNS Rebinding 공격 - DNS를 강제로 원격 호스트를 피해자의 IP 주소로 위장하여 신뢰된 호스트(원 사이트site of origin) 이름으로 재 바인딩하여 원래 사이트가 아닌 곳에 있는 호스트가 접근할 수 있도록 사용합니다.
  • 역 터널(Reverse tunnel) 공격 - 원격 클라이언트의 원격지로 나가는 접속을 클라이언트의 내부 네트워크로 들어가는 백 터널로 사용합니다.

실버라이트에 통합된 보안 정책 시스템은 이러한 네트워킹 위협을 막기 위해 디자인 되었습니다. In addition, the policy system also aims to give administrators more control over which resources a remote client is allowed to connect to.(※GG)

과거의 네트워크가능한 플러그인을 위한 디자인은 호스트나 원 사이트(site of origin)로의 접근성을 제한 하였습니다. 이것은 웹 애플리케이션은 오직 그것이 배포된 서버로의 통신만이 가능했다는 것을 의미합니다. 이 보안 모델은 실버라이트 2 베타 1의 소켓 접속에 적용되었고 네트워크 애플리케이션은 그것이 다운로드된 호스트로만 접속할 수 있었습니다.

실버라이트 2 베타 2는 애플리케이션이 원 사이트가 아닌 위치에 있는 리소스를 접근할 수 있도록 크로스-도메인 접속을 위한 지원을 포함합니다. 이것은 실버라이 애플리케이션이 웹에 이미 존재하는 다른 서비스를 사용하기 위한 중요한 기능입니다. 실버라이트 2 런타임의 보안 정책 시스템은 이제 네트워크 접속을 허용하고 리소스에 접근하기 전에 그 네트워크에서 다운로드 된 정책 파일을 필요로 합니다. 이 보안 정책 시스템은 System.Net 네임스페이스에 있는WebClient와 HTTP 클래스의 크로스-도메인 네트워크 접근에도 적용됩니다. 그러나 WebClient와 HTTP 클래스들의 원 사이트 혹은 호스트로의 네트워크 접속은 보안 정책을 필요로하지 않습니다.

소켓의 경우 실버라이트 2 베타 2의 보안 정책 시스템은 원 사이트(site of origin)과 크로스-도메인 네트워크 접근 모두에 다 적용됩니다. 보안 정책은 이제 소켓을 통한 어떠한 접속에도, 심지어 원 사이트로 다시 접속하는 경우라도 필요합니다.

이 섹션에서는 실버라이트 2에서 보안 정책 시스템을 어떻게 사용하는지에 대한 자세한 정보를 제공하고 지원되는 정책 파일 포맷에 대해 설명합니다.

보안 정책 시스템의 기본

실버라이트는 두 종류의 보안 정책 파일을 지원합니다.

  • 플래시 정책 파일 - Adobe 플래시에서 사용하는 crossdomain.xml 정책 파일. 이 정책 파일은 오직 WebClient와 HTTP 클래스에서만 사용 가능합니다. 플래시 정책 파일은 반드시 모든 도메인에 대한 접근을 허용해야 합니다.
  • 실버라이트 정책 파일 - 실버라이트 정책 파일은 WebClient와 HTTP 클래스 및 소켓 클래스에서도 사용할 수 있습니다. 이 정책 파일은 플래시 정책 파일과는 포맷이 다릅니다.

네트워크 리소스에 접속을 허용하기 전에 실버라이트 2 런타임은 네트워크 리소스로부터 보안 정책 파일의 다운로드를 시도할 것입니다. WebClient와 HTTP 클래스에 의한 접속 요청 또는 소켓의 접속에 해당하는 보안 정책을 다운로드 하는 데에는 두 가지 다른 방법이 사용됩니다.

만약 접속 요청이 크로스-도메인 사이트에 대한 WebClient나 HTTP 클래스에서 나왔다면 실버라이트 2 런타임은 HTTP 프로토콜을 사용하여 보안 정책 파일 다운로드를 시도합니다. 실버라이트 2 런타임은 먼저 HTTP 프로토콜을 사용하여 요청된 타겟 도메인의 최상위에 있는 "clientaccesspolicy.xml"이란 이름의 실버라이트 보안 정책 파일의 다운로드를 시도합니다. 만약 실버라이트 정책 파일이 반환되면(심지어 파일의 파싱에 에러가 있더라도) 이것은 실버라이트 애플리케이션의 세션 동안 해당 서버로의 크로스-도메인 요청과  다른 모든 요청을 위한 정책 파일로 사용됩니다. 만약 실버라이트 정책 파일이 발견되지 않으면 실버라이트 2 런타임은 HTTP 프로토콜을 사용하여 요청된 타겟 도메인의 최상위에 있는 "crossdomain.xml"이란 이름의 플래시 정책 파일의 다운로드를 시도합니다. 플래시 정책 파일은 반드시 모든 도메인에 대한 접속을 허용해야 합니다.

만약 접속 요청이 사이트(크로스-도메인이건 다른 사이트이건)에 대한 소켓에서 나왔다면 실버라이트 2 런타임은 TCP를 사용하여 잘 알려진well-known 포트(943번 포트)를 사용하여 대상 사이트로의 접속을 시도합니다. 만약 TCP 접속이 가능하다면 실버라이트 2 런타임은 <policy-file-request/>라는 지정된 문자열을 서버에 보내 실버라이트 정책 파일을 요청합니다. 실버라이트 2 런타임은 이 때 실버라이트 정책 파일을 포함하는 타겟 사이트의 응답의 수신을 대기합니다. 만약 이 실버라이트 정책 파일이 반환되면(심지어 파일 파싱에 에러가 있더라도) 이것은 실버라이트 애플리케이션의 세션 동안 해당 서버로의 소켓 요청과 다른 모든 요청을 위한 정책파일로 사용됩니다.

소켓 클래스를 사용하는데 하나의 추가적인 제약은 네트워크 애플리케이션이 허용된 접속은 반드시 4502-4534 범위의 포트를 사용해야 한다는 것입니다. 소켓을 사용한 실버라이트 애플리케이션의 접속은 오직 이 대상 포트들만 허용됩니다. 만약 대상 포트가 이 포트 범위에 있지 않으면 접속 시도는 실패할 것입니다.

WebClient와 HTTP 클래스에서 사용되는 보안 정책 파일을 배포하려면 시스템 관리자는 정책 파일 정의를 제공하고 실버라이트나 플래시 정책 파일을 HTTP를 통해 전송하기 위해 각 IP 주소별로 웹 서버 설정이 필요합니다.

소켓의 경우 서버에 있는 보안 정책 파일을 배포하기 위해 보안 정책 파일 정의를 제공하기 위하여 각 IP 주소별로 포트 943에 독립된 인증 서비스의 설정이 필요합니다.

실버라이트 정책 파일 포맷

실버라이트 정책 파일 포맷은 다음의 DTD로 설명됩니다.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- A DTD for the Silverlight Policy File -->
<!ELEMENT access-policy (cross-domain-access)>
<!ELEMENT cross-domain-access (policy+)>
<!ELEMENT policy (allow-from)>
<!ELEMENT policy (grant-to)>
<!ELEMENT allow-from (domain+)>
<!ATTLIST allow-from http-request-headers CDATA>
<!ELEMENT domain EMPTY >
<!ATTLIST domain uri CDATA #REQUIRED>
<!ELEMENT grant-to (resource+)>
<!ELEMENT grant-to (socket-resource+)>
<!ELEMENT grant-to EMPTY>
<!ATTLIST resource path CDATA #REQUIRED>
<!ATTLIST resource include-subpaths (true|false) "false">
<!ATTLIST socket-resource port CDATA #REQUIRED protocol #REQUIRED>
<!-- End of file. --><!-- End of file. -->

다음 표는 사용 가능한 ELEMENT 엔트리를 설명합니다.

엘리먼트
부모 필수 여부 여러 사용 가능 여부 설명
access-policy N/A (root) Yes No 실버라이트 정책 파일의 루트 엘리먼트.
cross-domain-access access-policy Yes No 사이트를 위한 모든 크로스 도메인 정책을 정의.
policy cross-domain-access Yes Yes 지정된 도메인 혹은 도메인의 세트에서의 요청을 위한 크로스 도메인 정책을 정의.
같은 파일 내에 여러 개의 정책이 정의 있음.
allow-from policy Yes No 정책에 의해 영향을 받는 모든 도메인을 정의.
allow-from
엘리먼트를 부분적인 정책으로 사용하여 암시적으로 원치 않는 모든 도메인의 접속을 거부할 있음.
allow-from
비어 있다면 정책 파일은 어떤 사이트에도 접속 권한을 주지 않음.
domain allow-from Yes Yes 정책에 의해 영향 받는 도메인(혹은 지정된 실버라이트 애플리케이션) 정의.
grant-to policy Yes No 정책에 의해 영향 받는 모든 서버의 리소스를 정의.
resource grant-to Yes (for WebClient and HTTP classes) Yes 정책에 의해 접근 가능한 리소스를 정의.
엘리먼트는 오직 WebClient HTTP 클래스를 사용한 접속 요청에만 적용됨.
socket-resource grant-to Yes (for sockets) Yes 정책에 의해 접근 가능한 리소스를 정의.
엘리먼트는 오직 소켓을 사용한 접속 요청에만 적용됨.

다음 표는 각 ELEMENT에서 사용 가능한 어트리뷰트를 설명합니다.

엘리먼트
어트리뷰트 필수 여부 기본값 설명
allow-from http-request-headers No 어떤 헤더도 허용되지 않음( 세트) - domain 어트리뷰트에서 지정된 도메인을 위한 대소문자 구분 없이 콤마(,) 구분된 허용할 헤더의 목록. 문자열은 RFC822 준한 유효한 문자열인 ASCII 33-41, 42-57 59-126. 이것은 콤마(헤더 이름의 끝을 지정) 애스터리스크(와일드카드에 사용되는) 제외한 출력이 가능한 모든 공백이 아닌 ASCII 문자열. 와일드카드는 모든 헤더를 지정하는 사용될 있고 또한 단일 헤더 이름에서 접미사로 사용되어 와일드카드 문자 앞의 문자열로 시작하는 모든 헤더를 허용.
-
일반적인 블랙리스트 헤더를 적용.
-
어트리뷰트가 없을 경우 어떤 헤더도 전송을 허용하지 않음.
domain uri Yes N/A 정책에서 허용된 경로에 접근할 있도록 허용된 도메인과 지정된 실버라이트 애플리케이션의 목록.
'*'
문자는 와일드 카드로 취급되고 모든 것을 허용하도록 처리.
URI
접속을 허용하는 스키마와 도메인을 지정.
resource path Yes (for WebClient and HTTP classes) N/A - 어트리뷰트는 도메인의 루트에 대한 URI. 이것은 서비스 혹은 파일을 나타내는 지정된 경로를 가리킴.
경로는 와일드카드 문자열이나 URI 의해 분석될 없는 캐릭터를 포함할 없음. URI 일반 문법은 http://ietf.org/rfc/rfc3986 참고.

-
엘리먼트와 어트리뷰트는 WebClient HTTP 클래스에서의 요청을 위해서만 사용.
resource include-subpaths No FALSE - 관련 경로가 서브 경로를 포함하는지 여부를 지정.
-
(true) 경우 path 어트리뷰트에 의해 설정된 정확한 경로와 일치하는 경로이거나 일치하는 경로 부분 뒤에 텍스트를 추가하여 요청된 URI 경로를 허용.
-
거짓(false) 경우 오직 path 어트리뷰트에 의해 설정된 정확한 경로만을 허용.
-
엘리먼트와 어트리뷰트는 WebClient HTTP 클래스에서의 요청을 위해만 사용.
socket-resource port Yes N/A - 소켓을 사용하는 애플리케이션의 접속을 허용할 포트 번호 또는 포트 번호의 범위를 지정.
-
엘리먼트와 어트리뷰트는 소켓에서의 요청을 위해서만 사용.
socket-resource protocol Yes N/A - 소켓을 사용하는 애플리케이션의 접속을 허용할 프로토콜을 지정.
-
현재는 TCP 만을 지원.
-
엘리먼트와 어트리뷰트는 소켓에서의 요청을 위해서만 사용.

하나의 실버라이트 정책 파일이 WebClient와 HTTP 클래스에서의 접속 요청과 소켓에서의 접속 요청을 위한 정책들을 포함할 수 있습니다.

이 정책 파일에서 요청이 유효한지를 결정하는 과정은 다음과 같습니다.

- 요청된 URI의 스키마가 애플리케이션의 원 사이트와 같은가? 그렇지 않다면 요청은 접근을 할 수 없으며 전송되어서는 안됨.

- 요청된 URI의 포트가 애플리케이션의 원 사이트와 같은가? 그렇지 않다면 요청은 접근을 할 수 없으며 전송되어서는 안됨.

- 각 <policy> 엘리먼트에 대해

  • 애플리케이션의 원 사이트의 접근이 허용되었는가? 이것은 명시적인 <policy> allow-from domain 어트리뷰트 혹은 모든 접근의 허용을 말하는 와일드카드 uri 어트리뷰트를 포함한 domain 엘리먼트를 가진 allow-from 어트리뷰트 모두를 허용. 만약 allow-from이 생략되면 기본 동작은 아무도 접근할 수 없게 된다는 점에 주의.
  • policy가 요청된 URI에 대한 접근을 허용하는가?

- 다음 조건 중 하나라도 참이면 요청은 접근이 가능하고 전송되어야 함. 그렇지 않으면 다음 <policy>로 이동.

  • 요청된 URI가 <resource> 태그에 있는 도메인과 경로와 완전히 일치.
  • 요청된 URI가 <grant-to> 태그에 있는 도메인과 경로 아래에 위치해 있고 <grant-to> 태그의 include-subpaths 어트리뷰트가 참으로 설정됨.
  • 소켓 요청의 경우, 이 <policy>의 <grant-to> 섹션에 있는 <socket-resource> 태그에서 프로토콜과 포트를 TCP와 4502-4534 범위에 있는 허용된 퍼트 범위로 설정함.

WebClient와 HTTP 클래스를 위한 정책 파일 예제

다음은 WebClient와 HTTP 클래스를 사용한 크로스-도메인 접속을 위한 실버라이트 정책 파일 예제입니다. 이 정책 파일은 요청 헤더를 제한하고 하위 경로를 허용하지 않습니다.

more..

다음은 다른 WebClient와 HTTP 클래스를 사용한 크로스-도메인 접속을 위한 실버라이트 정책 파일 예제입니다. 이 정책 파일은 요청 헤더를 허용하고 하위 경로를 포함합니다.

more..


다음은 또 다른 WebClient와 HTTP 클래스를 사용한 크로스-도메인 접속을 위한 실버라이트 정책 파일 예제입니다. 이 정책 파일은 지정된 요청 헤더를 지정하고 있습니다.

more..


소켓을 위한 정책 파일 예제

다음은 소켓을 사용한 접속을 위한 실버라이트 정책 파일의 샘플입니다.

more..


소켓을 위한 정책 서버의 샘플 코드

다음은 매니지드 코드로 소켓을 위한 간단한 정책 서버를 구현하는 샘플입니다. 샘플 정책 서버는 서버가 시작되었을 때 인자로서 사용할 정책 파일의 이름을 요구 합니다.

more..


※ 이 문서에서는 언급하지 않았지만 소켓을 통한 정책 파일 교환은 위와 같이 서버측에 943번 포트에서 정책 파일을 전송할 서비스를 만들어야만 가능합니다. 자세한 것은 Mike SnowsTip of the Day #12 - Full Implementation of a Silverlight Policy Server.를 참고하세요.

참조

네트워킹과 통신
실버라이트 2의 URL 접근 제약 (번역 : http://gongdosoft.com/293)
소켓으로 작업하기

신고
Posted by gongdo

※ 이 문서는 실버라이트 2 Beta 1에만 해당하는 내용으로 Beta 2에서는 다음의 글로 대체 되었습니다. 이용에 착오 없으시길.

2008/06/28 - [프로그래밍/Silverlight] - [MSDN] URL 접근 제약

실버라이트 2에서 가장 크게 바뀐 점 중 하나는 URL 접근에 대한 정책이 기본적인 보안에 대해 안전하면서도 보다 구체적이고 융통성있도록 구성되었다는 점이죠. 특히 실버라이트를 테스트할 때에는 잘 되다가 게시했을 때 안되는 문제의 많은 부분이 바로 URL 접근과 관련하여 일어나는데요, MSDN에 명확하게 정리된 문서가 있어서 번역해봤어요.

원본 : http://msdn2.microsoft.com/en-us/library/cc189008(vs.95).aspx


보안 문제 때문에 마이크로소프트 실버라이트는 쿠키 전달이나 재전송redirection 허용과 같은 보안에 위협이 될만한 것들에 대한 크로스 존Cross-zone, 크로스 도메인, 크로스 스키마 URL 접근을 제한합니다. 예를 들어, 한 웹 도메인에 호스팅된 실버라이트 기반의 애플리케이션을 가지고 있고 WebClient 개체를 사용하여 다른 도메인에 저장되어 있는 파일에 접근을 시도한다면 그 요청은 실패할 것입니다. 다음 테이블에서 이러한 룰을 정리합니다.

Note:
실버라이트로 다른 도메인의 파일을 접근할 수도 있습니다. 그렇게 하기 위해서는 이 기능을 명시적으로 활성화할 필요가 있습니다. 보다 자세한 정보는 여기를 클릭하세요.

  WebClient object Media, images, ASX XAML files, Font files Streaming media
허용된 스키마 HTTP, HTTPS HTTP, HTTPS, FILE HTTP, HTTPS, FILE HTTP
크로스 스키마 접근 No No No HTTPS로부터는 안됨
크로스 웹 도메인 접근 No HTTPS가 아닐 경우 Yes No Yes
크로스 존 접근(Windows에서) No No No No
크로스 존 접근(Macintosh에서) No Yes No Yes
재전송 허용 같은 도메인에서 Yes 같은 도메인에서 No

Note:
이러한 접근 정책의 위반으로 인한 결과로 발생한 에러가 있을 때 그 에러는 아마도 정확한 이유를 가리키지 않을 것입니다.

앞에서 본 표에서 사용된 몇몇 용어의 정의는 다음과 같습니다.

  • 크로스 스키마Cross-scheme : 어떤 스키마(예를 들어 HTTP, HTTPS)에서 다른 스키마를 접근하는 것.
  • 크로스 웹 도메인Cross-Web domain : 어떤 웹 도메인과 다른 웹 도메인 사이의 접근(예를 들어 www.contoso.com에 호스팅된 애플리케이션이 www.fabrikam.com에 있는 콘텐트에 대한 접근을 시도).
  • 크로스 존Cross-zone : 보안 영역간의 접근. 예를 들어 인터넷 서버에서 인트라넷 리소스에 접근을 시도하는 것.

예를 들어, 애플리케이션을 호스트하고 이미지를 다른 서버에서 가져오고 싶다면 앞에서 본 표에 있는 "Media, images, ASX" 항목을 체크해볼 수 있습니다.

  • 만약 애플리케이션이 HTTP 사이트에 호스팅된다면 HTTPS 스키마를 사용한 사이트에서 이미지를 가져올 수 없습니다.
  • 그 도메인의 스키마가 HTTPS가 아닌 한 다른 도메인에서 이미지를 가져올 수 있습니다.
  • 만약 애플리케이션이 인터넷에 있고 사용자가 Mac을 사용하지 않는다면 이미지를 인트라넷에서 가져올 수 없습니다.
  • URL이 같은 도메인에 있는 한 다른 이미지 URL로 재전송할 수 있습니다.

참고

컨셉
미디어 포맷 및 프로토콜 지원(실버라이트 2)
코어 프리젠테이션 프레임워크 / UI

신고
Posted by gongdo


티스토리 툴바