Pertimbangan keamanan XAML

Artikel ini menjelaskan praktik terbaik untuk keamanan dalam aplikasi saat Anda menggunakan XAML dan .NET XAML Services API.

XAML tidak tepercaya dalam Aplikasi

Dalam arti yang paling umum, XAML yang tidak tepercaya adalah sumber XAML apa pun yang tidak secara khusus disertakan atau dikeluarkan oleh aplikasi Anda.

XAML yang dikompilasi ke dalam atau disimpan sebagai resxsumber daya -type dalam rakitan tepercaya dan ditandatangani tidak secara inheren tidak tepercaya. Anda dapat mempercayai XAML sebanyak yang Anda percayai perakitan secara keseluruhan. Dalam kebanyakan kasus, Anda hanya peduli dengan aspek kepercayaan XAML longgar, yang merupakan sumber XAML yang Anda muat dari aliran atau I/O lainnya. XAML longgar bukan komponen atau fitur tertentu dari model aplikasi dengan infrastruktur penyebaran dan pengemasan. Namun, perakitan mungkin menerapkan perilaku yang melibatkan pemuatan XAML yang longgar.

Untuk XAML yang tidak tepercaya, Anda harus memperlakukannya secara umum sama seperti jika kode tidak tepercaya. Gunakan sandboxing atau metafora lain untuk mencegah kemungkinan XAML yang tidak tepercaya mengakses kode tepercaya Anda.

Sifat kemampuan XAML memberi XAML hak untuk membangun objek dan mengatur propertinya. Kemampuan ini juga termasuk mengakses pengonversi jenis, pemetaan dan akses rakitan di domain aplikasi, menggunakan ekstensi markup, x:Code blok, dan sebagainya.

Selain kemampuan tingkat bahasanya, XAML digunakan untuk definisi UI dalam banyak teknologi. Memuat XAML yang tidak tepercaya mungkin berarti memuat UI spoofing berbahaya.

Berbagi Konteks Antara Pembaca dan Penulis

Arsitektur Layanan XAML .NET untuk pembaca XAML dan penulis XAML sering kali mengharuskan berbagi pembaca XAML ke penulis XAML, atau konteks skema XAML bersama. Berbagi objek atau konteks mungkin diperlukan jika Anda menulis logika perulangan simpul XAML, atau menyediakan jalur penyimpanan kustom. Jangan bagikan instans pembaca XAML, konteks skema XAML nondefault, atau pengaturan untuk kelas pembaca/penulis XAML antara kode tepercaya dan tidak tepercaya.

Sebagian besar skenario dan operasi yang melibatkan penulisan objek XAML untuk backing jenis berbasis CLR hanya dapat menggunakan konteks skema XAML default. Konteks skema XAML default tidak secara eksplisit menyertakan pengaturan yang dapat membahayakan kepercayaan penuh. Dengan demikian aman untuk berbagi konteks antara komponen pembaca/penulis XAML tepercaya dan tidak tepercaya. Namun, jika Anda melakukan ini, ini masih merupakan praktik terbaik untuk menjaga pembaca dan penulis tersebut dalam cakupan terpisah AppDomain , dengan salah satunya secara khusus dimaksudkan/dikotakpasir untuk kepercayaan parsial.

Namespace Layanan XAML dan Kepercayaan Rakitan

Sintaks dan definisi dasar yang tidak memenuhi syarat tentang bagaimana XAML menginterpretasikan pemetaan namespace XAML kustom ke rakitan tidak membedakan antara rakitan tepercaya dan tidak tepercaya seperti yang dimuat ke dalam domain aplikasi. Dengan demikian, secara teknis dimungkinkan bagi rakitan yang tidak tepercaya untuk memalsukan pemetaan namespace XAML yang dimaksudkan rakitan tepercaya dan menangkap informasi objek dan properti sumber XAML yang dinyatakan. Jika Anda memiliki persyaratan keamanan untuk menghindari situasi ini, pemetaan namespace XAML yang Anda maksudkan harus dibuat menggunakan salah satu teknik berikut:

• Gunakan nama rakitan yang sepenuhnya memenuhi syarat dengan nama yang kuat dalam pemetaan namespace XAML apa pun yang dibuat oleh XAML aplikasi Anda.

• Batasi pemetaan perakitan ke sekumpulan rakitan referensi tetap, dengan membuat khusus XamlSchemaContext untuk pembaca XAML dan penulis objek XAML Anda. Lihat XamlSchemaContext(IEnumerable<Assembly>).

Pemetaan Jenis XAML dan Akses Sistem Jenis

XAML mendukung sistem jenisnya sendiri, yang dalam banyak hal adalah serekan tentang bagaimana CLR mengimplementasikan sistem jenis CLR dasar. Namun, untuk aspek tertentu dari jenis kesadaran di mana Anda membuat keputusan kepercayaan tentang jenis berdasarkan informasi jenisnya, Anda harus menunda informasi jenis dalam jenis dukungan CLR. Ini karena beberapa kemampuan pelaporan spesifik dari sistem jenis XAML dibiarkan terbuka sebagai metode virtual dan oleh karena itu, tidak sepenuhnya berada di bawah kendali implementasi Layanan .NET XAML asli. Titik ekstensibilitas ini ada karena sistem jenis XAML dapat diperluas, untuk mencocokkan ekstensibilitas XAML itu sendiri dan kemungkinan strategi pemetaan jenis alternatif versus implementasi default yang didukung CLR dan konteks skema XAML default. Untuk informasi selengkapnya, lihat catatan tertentu tentang beberapa properti XamlType dan XamlMember.

Baca juga

• XamlAccessLevel