XAML 보안 고려 사항XAML security considerations

이 문서에서는 XAML 및 .NET XAML 서비스 API를 사용 하는 경우 응용 프로그램의 보안에 대 한 모범 사례를 설명 합니다.This article describes best practices for security in applications when you use XAML and .NET XAML Services API.

응용 프로그램의 신뢰할 수 없는 XAMLUntrusted XAML in Applications

가장 일반적으로 신뢰할 수 없는 XAML은 응용 프로그램에서 특별히 포함 하거나 내보내지 않은 XAML 소스입니다.In the most general sense, untrusted XAML is any XAML source that your application did not specifically include or emit.

resx신뢰할 수 있는 어셈블리와 서명 된 어셈블리 내에서 형식 리소스로 컴파일되거나 저장 된 XAML은 본질적으로 신뢰할 수 없습니다.XAML that is compiled into or stored as a resx-type resource within a trusted and signed assembly is not inherently untrusted. 전체적으로 어셈블리를 신뢰 하는 만큼 XAML을 신뢰할 수 있습니다.You can trust the XAML as much as you trust the assembly as a whole. 대부분의 경우 stream 또는 기타 i/o에서 로드 하는 XAML 소스인 느슨한 XAML의 신뢰 측면에만 관심이 있습니다.In most cases, you are only concerned with the trust aspects of loose XAML, which is a XAML source that you load from a stream or other I/O. 느슨한 XAML은 배포 및 패키징 인프라를 사용 하는 응용 프로그램 모델의 특정 구성 요소나 기능이 아닙니다.Loose XAML is not a specific component or feature of an application model with a deployment and packaging infrastructure. 그러나 어셈블리는 느슨한 XAML 로드를 포함 하는 동작을 구현할 수 있습니다.However, an assembly might implement a behavior that involves loading loose XAML.

신뢰할 수 없는 XAML의 경우 일반적으로 신뢰할 수 없는 코드와 동일 하 게 처리 해야 합니다.For untrusted XAML, you should treat it generally the same as if it were untrusted code. 샌드 박싱 또는 기타 메타포를 사용 하 여 신뢰할 수 없는 XAML이 신뢰할 수 있는 코드에 액세스할 수 없도록 합니다.Use sandboxing or other metaphors to prevent possibly untrusted XAML from accessing your trusted code.

XAML 기능의 특성은 XAML에 개체를 생성 하 고 해당 속성을 설정할 수 있는 권한을 부여 합니다.The nature of XAML capabilities gives the XAML the right to construct objects and set their properties. 이러한 기능에는 형식 변환기 액세스, 응용 프로그램 도메인의 어셈블리 매핑 및 액세스, 태그 확장, 블록 등을 사용 하는 작업도 포함 됩니다 x:Code .These capabilities also include accessing type converters, mapping and accessing assemblies in the application domain, using markup extensions, x:Code blocks, and so on.

언어 수준 기능 외에도 XAML은 많은 기술의 UI 정의에 사용 됩니다.In addition to its language-level capabilities, XAML is used for UI definition in many technologies. 신뢰할 수 없는 XAML 로드는 악의적인 스푸핑 UI를 로드 하는 것을 의미할 수 있습니다.Loading untrusted XAML might mean loading a malicious spoofing UI.

판독기와 작성기 간의 컨텍스트 공유Sharing Context Between Readers and Writers

Xaml 판독기 및 XAML 작성기에 대 한 .NET XAML 서비스 아키텍처는 xaml 판독기를 XAML 작성기 또는 공유 XAML 스키마 컨텍스트와 공유 해야 하는 경우가 많습니다..NET XAML Services architecture for XAML readers and XAML writers often requires sharing a XAML reader to a XAML writer, or a shared XAML schema context. XAML 노드 루프 논리를 작성 하거나 사용자 지정 저장 경로를 제공 하는 경우 개체 또는 컨텍스트를 공유 해야 할 수 있습니다.Sharing objects or contexts might be required if you are writing XAML node loop logic, or providing a custom save path. 신뢰할 수 있는 코드와 신뢰할 수 없는 코드 간에 xaml 판독기 인스턴스, 기본이 아닌 XAML 스키마 컨텍스트 또는 XAML 판독기/작성기 클래스의 설정을 공유 하지 않습니다.Don't share XAML reader instances, nondefault XAML schema context, or settings for XAML reader/writer classes between trusted and untrusted code.

CLR 기반 형식 지원에 대 한 XAML 개체 쓰기와 관련 된 대부분의 시나리오 및 작업에서는 기본 XAML 스키마 컨텍스트를 사용 하기만 하면 됩니다.Most scenarios and operations involving XAML object writing for a CLR-based type backing can just use default XAML schema context. 기본 XAML 스키마 컨텍스트는 완전 신뢰를 손상 시킬 수 있는 설정을 명시적으로 포함 하지 않습니다.The default XAML schema context does not explicitly include settings that could compromise full trust. 따라서 신뢰할 수 있고 신뢰할 수 없는 XAML 판독기/기록기 구성 요소 간에 컨텍스트를 공유 하는 것이 안전 합니다.It is thus safe to share context between trusted and untrusted XAML reader/writer components. 그러나이 작업을 수행 하는 경우에는 이러한 판독기와 작성기를 별도의 범위에 유지 하는 것이 좋습니다 AppDomain .However, if you do this, it is still a best practice to keep such readers and writers in separate AppDomain scopes, with one of them specifically intended/sandboxed for partial trust.

XAML 네임 스페이스 및 어셈블리 신뢰XAML Namespaces and Assembly Trust

XAML이 사용자 지정 XAML 네임 스페이스 매핑을 어셈블리로 해석 하는 방법에 대 한 기본 정규화 되지 않은 구문 및 정의는 응용 프로그램 도메인에 로드 되는 신뢰할 수 있는 어셈블리와 신뢰할 수 없는 어셈블리를 구분 하지 않습니다.The basic unqualified syntax and definition for how XAML interprets a custom XAML namespace mapping to an assembly does not distinguish between a trusted and untrusted assembly as loaded into the application domain. 따라서 신뢰할 수 없는 어셈블리는 신뢰할 수 있는 어셈블리의 의도 된 XAML 네임 스페이스 매핑을 스푸핑 하 고 XAML 소스의 선언 된 개체 및 속성 정보를 캡처할 수 있습니다.Thus, it is technically possible for an untrusted assembly to spoof a trusted assembly's intended XAML namespace mapping and capture a XAML source's declared object and property information. 이러한 상황을 방지 하기 위해 보안 요구 사항이 있는 경우 다음 방법 중 하나를 사용 하 여 의도 한 XAML 네임 스페이스 매핑을 만들어야 합니다.If you have security requirements to avoid this situation, your intended XAML namespace mapping should be made using one of the following techniques:

  • 응용 프로그램의 XAML에서 만든 XAML 네임 스페이스 매핑에서 강력한 이름의 정규화 된 어셈블리 이름을 사용 합니다.Use a fully qualified assembly name with strong name in any XAML namespace mapping made by your application's XAML.

  • XamlSchemaContextXaml 판독기 및 xaml 개체 작성기에 대해 특정을 생성 하 여 고정 된 참조 어셈블리 집합에 대 한 어셈블리 매핑을 제한 합니다.Restrict assembly mapping to a fixed set of reference assemblies, by constructing a specific XamlSchemaContext for your XAML readers and XAML object writers. XamlSchemaContext(IEnumerable<Assembly>)을 참조하세요.See XamlSchemaContext(IEnumerable<Assembly>).

XAML 형식 매핑 및 형식 시스템 액세스XAML Type Mapping and Type System Access

XAML은 자체 형식 시스템을 지원 합니다 .이 시스템은 CLR이 기본 CLR 형식 시스템을 구현 하는 방식에 대 한 피어입니다.XAML supports its own type system, which in many ways is a peer to how CLR implements the basic CLR type system. 그러나 형식 정보를 기반으로 하는 형식에 대 한 신뢰 결정을 내리는 형식 인식의 특정 측면에 대해서는 CLR 지원 형식에서 형식 정보를 결정 해야 합니다.However, for certain aspects of type awareness where you are making trust decisions about a type based on its type information, you should defer to the type information in the CLR backing types. 이는 XAML 형식 시스템의 특정 보고 기능이 가상 메서드로 열려 있기 때문에 원래 .NET XAML 서비스 구현에 대 한 제어에는 완전히 적용 되지 않기 때문입니다.This is because some of the specific reporting capabilities of the XAML type system are left open as virtual methods and are therefore, not fully under the control of the original .NET XAML Services implementations. 이러한 확장성 지점은 XAML 형식 시스템이 확장 가능 하 여 xaml 자체의 확장성과 가능한 대체 형식 매핑 전략과 기본 CLR 지원 구현 및 기본 XAML 스키마 컨텍스트와 일치 하기 때문에 존재 합니다.These extensibility points exist because the XAML type system is extensible, to match the extensibility of XAML itself and its possible alternative type-mapping strategies versus the default CLR-backed implementation and default XAML schema context. 자세한 내용은 및의 몇 가지 속성에 대 한 특정 메모를 참조 XamlType 하세요 XamlMember .For more information, see the specific notes on several of the properties of XamlType and XamlMember.

참고 항목See also