Aracılığıyla paylaş

Veriler için GüvenlikLe İlgili Dikkat Edilmesi Gerekenler

Windows Communication Foundation'daki (WCF) verilerle ilgilenirken, bir dizi tehdit kategorisini dikkate almanız gerekir. Aşağıdaki listede, veri işlemeyle ilgili en önemli tehdit sınıfları gösterilmektedir. WCF, bu tehditleri azaltmak için araçlar sağlar.

  • Hizmet reddi

    Güvenilmeyen verileri alırken, veriler alıcı tarafın uzun hesaplamalara neden olarak bellek, iş parçacıkları, kullanılabilir bağlantılar veya işlemci döngüleri gibi çeşitli kaynaklardan orantısız miktarda erişmesine neden olabilir. Sunucuya yönelik bir hizmet reddi saldırısı, sunucunun kilitlenmesine neden olabilir ve diğer, meşru istemcilerden gelen iletileri işleyemeyebilir.

  • Kötü amaçlı kod yürütme

    Gelen güvenilmeyen veriler, alıcı tarafın amaçlamadığı kodu çalıştırmasına neden olur.

  • Bilgilerin açığa çıkması

    Uzak saldırgan, alıcı tarafı isteklerine öyle bir şekilde yanıt vermeye zorlar ki, alıcı istemediği kadar fazla bilgi ifşa eder.

Kod ve Kod Erişim Güvenliği User-Provided

Windows Communication Foundation (WCF) altyapısında, kullanıcı tarafından sağlanan kodu çalıştıran çok sayıda yer bulunmaktadır. Örneğin, DataContractSerializer serileştirme altyapısı kullanıcı tarafından sağlanan özellik set erişimcilerini ve get erişimcilerini çağırabilir. WCF kanal altyapısı, kullanıcı tarafından sağlanan Message sınıfının türetilmiş sınıflarıyla da etkileşimde bulunabilir.

Güvenlik açığı olmadığından emin olmak kod yazarının sorumluluğundadır. Örneğin, tamsayı türünde bir veri üyesi özelliğiyle bir veri sözleşmesi türü oluşturursanız ve set erişimci uygulamasında özellik değerine göre bir dizi ayırırsanız, kötü amaçlı bir ileti bu veri üyesi için son derece büyük bir değer içeriyorsa hizmet reddi saldırısı olasılığını ortaya çıkarırsınız. Genel olarak, kullanıcı tarafından sağlanan kodda gelen verilere veya uzun işlemeye dayalı ayırmalardan kaçının (özellikle uzun işlemenin nedeni az miktarda gelen veriyse). Kullanıcı tarafından sağlanan kodun güvenlik analizini gerçekleştirirken tüm hata durumlarını (yani özel durumların oluştuğu tüm kod dallarını) da dikkate aldığınızdan emin olun.

Kullanıcı tarafından sağlanan kodun nihai örneği, her işlem için hizmet uygulamanızın içindeki koddur. Hizmet uygulamanızın güvenliği sizin sorumluluğunuzdadır. Hizmet reddi güvenlik açıklarına neden olabilecek, yanlışlıkla güvenli olmayan işlem uygulamaları oluşturmak kolaydır. Örneğin, bir dize alan ve adı bu dizeyle başlayan bir veritabanındaki müşterilerin listesini döndüren bir işlem. Büyük bir veritabanıyla çalışıyorsanız ve geçirilen dize yalnızca tek bir harfse, kodunuz tüm kullanılabilir bellekten daha büyük bir ileti oluşturmayı deneyerek hizmetin tamamının başarısız olmasına neden olabilir. (. OutOfMemoryException NET Framework'te kurtarılamaz ve her zaman uygulamanızın sonlandırılmasına neden olur.)

Çeşitli genişletilebilirlik noktalarına kötü amaçlı kod takılı olmadığından emin olmanız gerekir. Bu özellikle kısmi güven altında çalışırken, kısmen güvenilen derlemelerdeki türlerle ilgilenirken veya kısmen güvenilen kodla kullanılabilen bileşenler oluştururken geçerlidir. Daha fazla bilgi için sonraki bir bölümde yer alan "Kısmi Güven Tehditleri" bölümüne bakın.

Kısmi güven içinde çalışırken veri sözleşmesi serileştirme altyapısının veri sözleşmesi programlama modelinin yalnızca sınırlı bir alt kümesini desteklediğini unutmayın; örneğin, özel veri üyeleri veya özniteliğini kullanan SerializableAttribute türler desteklenmez. Daha fazla bilgi için bkz . Kısmi Güven.

Uyarı

Kod Erişim Güvenliği (CAS), .NET Framework ve .NET'in tüm sürümlerinde kullanım dışı bırakılmıştır. .NET'in son sürümleri CAS ek açıklamalarını dikkate almaz ve CAS ile ilgili API'ler kullanılırsa hata üretir. Geliştiriciler, güvenlik görevlerini yerine getirmek için alternatif yöntemler aramalıdır.

İstenmeyen Bilgilerin Açığa Çıkmasından Kaçınma

Güvenliği göz önünde bulundurarak serileştirilebilir türler tasarlarken, bilgilerin açığa çıkması olası bir sorundur.

Aşağıdaki noktaları göz önünde bulundurun:

  • Programlama modeli, DataContractSerializer serileştirme sırasında özel ve iç verilerin tür veya derleme dışında açığa çıkmalarını sağlar. Ayrıca, şema dışarı aktarma sırasında bir türün şekli gösterilebilir. Türünüzün serileştirme projeksiyonlarını anladığınızdan emin olun. Hiçbir şeyin açığa çıkmasını istemiyorsanız, serileştirmeyi devre dışı bırakın (örneğin, bir veri sözleşmesi durumunda DataMemberAttribute özniteliğini uygulamayarak).

  • Aynı türün kullanımdaki seri hale getiriciye bağlı olarak birden çok serileştirme projeksiyonu olabileceğini unutmayın. Aynı tür, DataContractSerializer ile kullanıldığında bir veri kümesini ve XmlSerializer ile kullanıldığında başka bir veri kümesini kullanıma sunabilir. Yanlışlıkla yanlış seri hale getiricinin kullanılması bilgilerin açığa çıkmasına neden olabilir.

  • XmlSerializer Eski uzak yordam çağrısında (RPC)/kodlanmış mod kullanıldığında, nesne grafiğinin şekli istemeden alıcı tarafa gönderiliyor olabilir.

Hizmet Reddi Saldırılarını Önleme

Kotalar

Alıcı tarafın önemli miktarda bellek ayırmasına neden olmak olası bir hizmet reddi saldırısıdır. Bu bölüm büyük iletilerden kaynaklanan bellek tüketimi sorunlarına odaklansa da, başka saldırılar oluşabilir. Örneğin, iletiler orantısız bir işlem süresi kullanabilir.

Hizmet reddi saldırıları genellikle kotalar kullanılarak azaltılır. Kota aşıldığında normalde bir QuotaExceededException özel durum oluşturulur. Kota olmadan, kötü amaçlı bir ileti tüm kullanılabilir belleğe erişilmesine neden olabilir ve bu, bir OutOfMemoryException istisnası ile sonuçlanabilir. Ayrıca, tüm kullanılabilir yığınlara erişilmesi, bir StackOverflowException ile sonuçlanabilir.

Kota aşıldı senaryosu kurtarılabilir; çalışan bir hizmette karşılaşılırsa, şu anda işlenen ileti atılır ve hizmet çalışmaya devam eder ve diğer iletileri işler. Ancak bellek yetersiz ve yığın taşma senaryoları .NET Framework'ün herhangi bir yerinde kurtarılamaz; bu tür özel durumlarla karşılaşırsa hizmet sonlandırılır.

WCF'deki kotalar önceden ayırma içermez. Örneğin, kota (çeşitli sınıflarda bulunur) 128 KB olarak ayarlandıysa MaxReceivedMessageSize , bu her ileti için otomatik olarak 128 KB ayrıldığı anlamına gelmez. Ayrılan gerçek tutar, gerçek gelen ileti boyutuna bağlıdır.

Aktarım katmanında birçok kota mevcuttur. Belirli aktarım kanalı (HTTP, TCP vb.) tarafından uygulanan kotalardır. Bu konu başlığında bu kotalardan bazıları ele alınsa da, bu kotalar Taşıma Kotaları bölümünde ayrıntılı olarak açıklanmıştır.

Hash Tablosu Güvenlik Açığı

Veri anlaşmaları karma tablo veya koleksiyon içerdiğinde bir güvenlik açığı oluşur. Bu sorun, çok sayıda değerin aynı karma değeri oluşturduğu bir karma tabloya çok sayıda değer eklendiğinde oluşur. Bu, DOS saldırısı olarak kullanılabilir. MaxReceivedMessageSize bağlama kotası ayarlanarak bu güvenlik açığı giderilebilir. Bu tür saldırıları önlemek için bu kota ayarlanırken dikkatli olunmalıdır. Bu kota, WCF iletisinin boyutuna bir üst sınır koyar. Ayrıca, veri sözleşmelerinizde karma tablo veya koleksiyon kullanmaktan kaçının.

Akış Olmadan Bellek Tüketimini Sınırlama

Büyük iletilerin güvenlik modeli, akışın kullanımda olup olmamasına bağlıdır. Temel, akış yapılmayan durumda iletiler bellekte saklanır. Bu durumda, büyük mesajlara karşı koruma sağlamak için sistem tarafından verilen bağlamları ya da MaxReceivedMessageSize üzerindeki kotayı kullanarak, erişebilmeniz için en büyük mesaj boyutunu sınırlayın. Bir hizmetin aynı anda birden çok iletiyi işliyor olabileceğini ve bu durumda bunların tümünün bellekte olduğunu unutmayın. Bu tehdidi azaltmak için kısıtlama özelliğini kullanın.

Ayrıca, ileti başına bellek tüketimine üst sınır yerleştirmediğini, ancak sabit bir faktör içinde sınırladığını unutmayın MaxReceivedMessageSize . Örneğin, eğer MaxReceivedMessageSize 1 MB ise ve 1 MB'lık bir ileti alınıp seri durumdan çıkarılırsa, seri durumdan çıkarılan nesne grafiğini içermek için ek bellek gerekir. Bu nedenle, toplam bellek tüketimi 1 MB'ın çok üzerinde olur. Bu nedenle, çok fazla gelen veri olmadan önemli miktarda bellek tüketimine neden olabilecek serileştirilebilir türler oluşturmaktan kaçının. Örneğin, 50 isteğe bağlı veri üyesi alanı ve ek 100 özel alan içeren "MyContract" veri sözleşmesinin örneği "<MyContract/>" XML yapısıyla oluşturulabilir. Bu XML, 150 alan için belleğe erişim sonuçlanır. Veri üyelerinin varsayılan olarak isteğe bağlı olduğunu unutmayın. Böyle bir tür bir dizinin parçası olduğunda sorun katlanır.

MaxReceivedMessageSize tek başına tüm hizmet reddi saldırılarını önlemek için yeterli değildir. Örneğin, bir çözücü, gelen bir mesajla derin iç içe geçmiş nesne grafiğini (bir nesnenin başka bir nesneyi, onun da başka bir nesneyi içermesi gibi) çözmek zorunda kalabilir. Hem DataContractSerializer hem de XmlSerializer çağrı yöntemleri bu tür grafikleri seri durumdan çıkarmak için iç içe yerleştirilmiş bir şekilde çağırılır. Yöntem çağrılarının derin iç içe yerleştirilmesi geri dönülemez bir hata ile sonuçlanabilir StackOverflowException. Bu tehdit, konunun devamında yer alan "XML'yi Güvenli Bir Şekilde Kullanma" bölümünde açıklandığı gibi, XML iç içe geçme düzeyini sınırlamak amacıyla MaxDepth kotası ayarlanarak azaltılır.

ek kotaların MaxReceivedMessageSize ayarlanması, ikili XML kodlaması kullanılırken özellikle önemlidir. İkili kodlamanın kullanılması sıkıştırmaya biraz eşdeğerdir: Gelen iletideki küçük bir bayt grubu çok fazla veriyi temsil edebilir. Bu nedenle, sınıra MaxReceivedMessageSize uyan bir ileti bile tamamen genişletilmiş biçimde çok daha fazla bellek alabilir. Bu tür XML'ye özgü tehditleri azaltmak için, bu konunun devamında yer alan "XML'yi Güvenli Bir Şekilde Kullanma" bölümünde açıklandığı gibi tüm XML okuyucu kotalarının doğru ayarlanması gerekir.

Akışla Bellek Tüketimini Sınırlama

Akış yaparken, hizmet reddi saldırılarına karşı korumak için küçük MaxReceivedMessageSize bir ayar kullanabilirsiniz. Ancak, akışla daha karmaşık senaryolar mümkündür. Örneğin, bir dosya karşıya yükleme hizmeti tüm kullanılabilir bellekten daha büyük dosyaları kabul eder. MaxReceivedMessageSize değerini son derece büyük bir değere ayarlayın, böylece bellekte neredeyse hiç veri arabelleğe alınmaz ve mesaj doğrudan diske akış olarak gönderilir. Kötü amaçlı bir ileti bir şekilde WCF'yi bu durumda verileri akışa almak yerine arabelleğe almak için zorlayabilirse, MaxReceivedMessageSize artık kullanılabilir tüm belleğe erişen iletiye karşı koruma sağlamaz.

Bu tehdidi azaltmak için, çeşitli WCF veri işleme bileşenlerinde arabelleğe almayı sınırlayan belirli kota ayarları bulunmaktadır. Bunlardan en önemlisi, çeşitli aktarım bağlama öğeleri ve standart bağlamalar üzerindeki özelliğidir MaxBufferSize . Akış yapılırken, ileti başına ayırmaya istekli olduğunuz en fazla bellek miktarı dikkate alınarak bu kota ayarlanmalıdır. ayarında MaxReceivedMessageSizeolduğu gibi, bellek tüketimine mutlak bir maksimum değer koymaz, ancak bunu yalnızca sabit bir faktörle sınırlar. Ayrıca, MaxReceivedMessageSize ile olduğu gibi, birden çok iletinin aynı anda işlenme olasılığının farkında olun.

MaxBufferSize Ayrıntıları

MaxBufferSize özelliği, WCF'nin yaptığı tüm toplu arabelleğe almaları sınırlar. Örneğin, WCF her zaman SOAP üst bilgilerini ve SOAP hatalarını, ayrıca İleti İletimi İyileştirme Mekanizması (MTOM) iletisinde doğal okuma sırasına uymadığı belirlenen MIME parçalarını arabelleğe alır. Bu ayar tüm bu durumlarda arabelleğe alma miktarını sınırlar.

WCF, MaxBufferSize değerini çeşitli arabelleğe alma bileşenlerine aktararak bunu gerçekleştirir. Örneğin, sınıfın CreateMessage bazı Message aşırı yüklemeleri bir maxSizeOfHeaders parametre alır. WCF, SOAP üst bilgi arabelleği miktarını sınırlamak için MaxBufferSize değerini bu parametreye geçirir. Bu sınıfı doğrudan kullanırken bu parametrenin Message ayarlanması önemlidir. Genel olarak, WCF'de kota parametrelerini alan bir bileşen kullanılırken, bu parametrelerin güvenlik etkilerini anlamak ve bunları doğru ayarlamak önemlidir.

MTOM ileti kodlayıcının da bir MaxBufferSize ayarı vardır. Standart bağlamalar kullanılırken, bu otomatik olarak aktarım düzeyi MaxBufferSize değerine ayarlanır. Ancak, özel bir bağlama oluşturulurken MTOM ileti kodlayıcı bağlama öğesi kullanılıyorsa, akış kullanıldığında MaxBufferSize özelliğini güvenli bir değere ayarlamak önemlidir.

XML-Based Akış Saldırıları

MaxBufferSize tek başına, akışın beklendiği durumlarda WCF'nin arabelleğe alınmaya zorlanmasını önlemek için yeterli değildir. Örneğin, WCF XML okuyucuları yeni bir öğeyi okumaya başlarken her zaman XML öğesi başlangıç etiketinin tamamını arabelleğe alır. Bu, ad alanlarının ve özniteliklerin düzgün bir şekilde işlenmesi için yapılır. Büyük olacak şekilde yapılandırılmışsa MaxReceivedMessageSize (örneğin, doğrudan diske büyük bir dosya akışı senaryosu etkinleştirmek için), ileti gövdesinin tamamının büyük bir XML öğesi başlangıç etiketi olduğu kötü amaçlı bir ileti oluşturulabilir. Okuma girişimi sonucunda bir OutOfMemoryException olur. Bu, bu konunun devamında yer alan "XML'yi Güvenli Bir Şekilde Kullanma" bölümünde açıklanan, XML okuyucu kotaları kullanılarak azaltılabilen birçok olası XML tabanlı hizmet reddi saldırılarından biridir. Akış yaparken, bu kotaların tümünü ayarlamak özellikle önemlidir.

Akış ve AraBelleğe Alma Programlama Modellerini Karıştırma

Birçok olası saldırı, akış ve akış dışı programlama modellerinin aynı hizmette karıştırılmasından kaynaklanabilecektir. İki işlemi olan bir hizmet sözleşmesi olduğunu varsayalım: biri bir Stream alır ve diğeri özel türde bir dizi alır. Ayrıca MaxReceivedMessageSize'ün büyük bir değere ayarlandığını ve ilk işlemin büyük veri akışlarını işlemesine olanak sağlamak için bunun kullanıldığını varsayalım. Ne yazık ki bu, büyük iletilerin artık ikinci işleme de gönderilebileceği anlamına gelir ve serileştirme aracı, işlem çağrılmadan önce verileri bellekte bir dizi olarak arabelleğe alır. Bu olası bir hizmet reddi saldırısıdır: MaxBufferSize Kota, seri durumdan çıkarıcının çalıştığı ileti gövdesinin boyutunu sınırlamaz.

Bu nedenle, akış tabanlı ve akışsız işlemleri aynı sözleşmede karıştırmaktan kaçının. İki programlama modelini kesinlikle karıştırmanız gerekiyorsa aşağıdaki önlemleri kullanın:

  • Özelliği kapatmak için IExtensibleDataObjectIgnoreExtensionDataObject özelliğini ServiceBehaviorAttribute olarak ayarlayın true. Bu, yalnızca sözleşmenin bir parçası olan üyelerin seri durumdan çıkarılmasını sağlar.

  • MaxItemsInObjectGraph özelliğini DataContractSerializer güvenli bir değere ayarlayın. Bu kota özniteliğinde ServiceBehaviorAttribute veya yapılandırma aracılığıyla da kullanılabilir. Bu kota, bir seri durumdan çıkarma işleminde seri durumdan çıkarılan nesne sayısını sınırlar. Normalde, bir ileti sözleşmesindeki her işlem parametresi veya ileti gövdesi bölümü bir bölümde seri durumdan çıkarılır. Dizileri seri durumdan çıkarırken, her dizi girdisi ayrı bir nesne olarak sayılır.

  • Tüm XML okuyucu kotalarını güvenli değerlere ayarlayın. MaxDepth'ya, MaxStringContentLength'e ve MaxArrayLength'ye dikkat edin ve akış dışı işlemlerde dizelerden kaçının.

  • Bilinen türlerin listesini gözden geçirin ve herhangi birinin herhangi bir zamanda örneklenebileceğini unutmayın (bu konunun devamında yer alan "İstenmeyen Türlerin Yüklenmesini Önleme" bölümüne bakın).

  • Çok fazla veri arabelleği kullanan IXmlSerializable arabirimini uygulayan herhangi bir türü kullanmayın. Bu tür türleri bilinen türler listesine eklemeyin.

  • XmlElement, XmlNode dizileri, Byte dizileri veya ISerializable'yi uygulayan türleri bir sözleşmede kullanmayın.

  • XmlElement dizileri, XmlNode dizileri, Byte dizileri veya ISerializable'yi uygulayan türleri bilinen türler listesinde kullanmayın.

Önceden belirtilen önlemler, akışsız işlemler için DataContractSerializer kullanıldığında uygulanır. XmlSerializer kullanıyorsanız, akış ve akış dışı programlama modellerini asla aynı hizmette karıştırmayın çünkü bu, kotanın MaxItemsInObjectGraph korumasına sahip değildir.

Yavaş Akış Saldırıları

Bellek tüketimini içermeyen bir tür akış hizmet reddi saldırısı vardır. Bunun yerine, saldırı yavaş gönderen veya veri alıcısı içerir. Verilerin gönderilmesi veya alınması beklenirken, iş parçacıkları ve kullanılabilir bağlantılar gibi kaynaklar yavaş yavaş tükenir. Bu durum kötü amaçlı bir saldırı sonucunda veya yavaş bir ağ bağlantısında meşru bir gönderenden/alıcıdan kaynaklanabilir.

Bu saldırıları azaltmak için aktarım zaman aşımlarını doğru ayarlayın. Daha fazla bilgi için Aktarım Kotaları'na bakınız. İkinci olarak, WCF'de akışlarla çalışırken hiçbir zaman uyumlu Read veya Write işlem kullanmayın.

XML'i Güvenli Bir Şekilde Kullanma

Uyarı

Bu bölüm XML ile ilgili olsa da, bilgiler JavaScript Nesne Gösterimi (JSON) belgeleri için de geçerlidir. Kotalar, JSON ve XML Arasında Eşleme kullanılarak benzer şekilde çalışır.

Güvenli XML Okuyucuları

XML Infoset, WCF'deki tüm ileti işleme işlemlerinin temelini oluşturur. Güvenilmeyen bir kaynaktan XML verilerini kabul ederken, hafifletilmesi gereken bir dizi hizmet reddi saldırısı olasılığı vardır. WCF özel, güvenli XML okuyucular sağlar. Bu okuyucular WCF'deki standart kodlamalardan biri (metin, ikili veya MTOM) kullanılırken otomatik olarak oluşturulur.

Bu okuyuculardaki bazı güvenlik özellikleri her zaman etkindir. Örneğin okuyucular, olası bir hizmet reddi saldırıları kaynağı olan ve hiçbir zaman meşru SOAP iletilerinde görünmemesi gereken belge türü tanımlarını (DTD) hiçbir zaman işlemez. Diğer güvenlik özellikleri, aşağıdaki bölümde açıklanan yapılandırılması gereken okuyucu kotalarını içerir.

Doğrudan XML okuyucularla çalışırken (örneğin, kendi özel kodlayıcınızı yazarken veya doğrudan sınıfla Message çalışırken), güvenilmeyen verilerle çalışma şansı olduğunda her zaman WCF güvenli okuyucularını kullanın. CreateTextReader sınıfındaki CreateBinaryReader, CreateMtomReader, veya XmlDictionaryReader statik fabrika yöntemi aşırı yüklemelerinden birini çağırarak güvenli okuyucuları oluşturun. Okuyucu oluştururken güvenli kota değerlerini geçirin. Create yöntemi aşırı yüklemelerini çağırmayın. Bunlar WCF okuyucusu oluşturmaz. Bunun yerine, bu bölümde açıklanan güvenlik özellikleri tarafından korunmayan bir okuyucu oluşturulur.

Okuyucu Kotaları

Güvenli XML okuyucuların beş yapılandırılabilir kotası vardır. Bunlar normalde kodlama bağlama öğelerinde veya standart bağlamalarda ReaderQuotas özelliği kullanılarak ya da okuyucu oluşturulurken geçirilen bir XmlDictionaryReaderQuotas nesnesi kullanılarak yapılandırılır.

OkumaBaşınaMaksimumBayt

Bu kota, öğe başlangıç etiketini ve özniteliklerini okurken tek Read bir işlemde okunan bayt sayısını sınırlar. (Akışsız durumlarda, öğe adının kendisi kotaya göre sayılmaz.) MaxBytesPerRead aşağıdaki nedenlerle önemlidir:

  • Öğe adı ve öznitelikleri okunurken her zaman bellekte tamponlanır. Bu nedenle, akış modundayken fazla tamponlamayı önlemek için kotayı doğru şekilde ayarlamak önemlidir. Gerçek arabelleğe alma miktarı hakkında bilgi için MaxDepth kota bölümüne bakın.

  • Öznitelik adlarının benzersiz olup olmadığı denetlenmesi gerektiğinden, çok fazla XML özniteliğine sahip olmak orantısız işlem süresini kullanabilir. MaxBytesPerRead bu tehdidi azaltır.

Maksimum Derinlik

Bu kota, XML öğelerinin iç içe yerleştirme derinliği üst sınırını sınırlar. Örneğin, "<A><B><C/></B></A>" belgesi üç katmanlı iç içe yerleştirmeye sahiptir. MaxDepth aşağıdaki nedenlerle önemlidir:

  • MaxDepth ile MaxBytesPerReadetkileşim kurar: Okuyucu, geçerli öğe ve tüm üst öğeleri için verileri her zaman bellekte tutar, bu nedenle okuyucunun en fazla bellek tüketimi bu iki ayarın çarpımıyla orantılıdır.

  • İç içe geçmiş bir nesne grafiği seri durumundan çıkarılırken, seri durumdan çıkartıcı tüm yığına erişmek ve kurtarılamaz bir StackOverflowException ortaya çıkarmak zorunda kalır. XML iç içe geçişi ve nesne iç içe geçişi arasında, gerek DataContractSerializer gerekse XmlSerializer için doğrudan bir bağıntı vardır. Bu tehdidi azaltmak için kullanın MaxDepth .

Maksimum İsim Tablosu Karakter Sayısı (MaxNameTableCharCount)

Bu kota, okuyucunun ad tablosu boyutunu sınırlar. Ad tablosu, xml belgesi işlenirken karşılaşılan belirli dizeleri (ad alanları ve ön ekler gibi) içerir. Bu dizeler bellekte arabelleğe alındığından, akış beklendiğinde aşırı arabelleğe almayı önlemek için bu kotayı ayarlayın.

MaksimumDizeİçeriğiUzunluğu

Bu kota, XML okuyucusunun döndürdüğü en büyük dize boyutunu sınırlar. Bu kota, XML okuyucunun kendisinde değil, okuyucuyu kullanan bileşende bellek tüketimini sınırlamaz. Örneğin, DataContractSerializer bir okuyucu, MaxStringContentLength ile güvence altına alındığında, bu kotadan daha büyük dizeleri seri hale getirmez. Doğrudan XmlDictionaryReader sınıfını kullanırken, tüm yöntemler bu kota kapsamında değildir, ancak yalnızca dizeleri okumak için özel olarak tasarlanmış yöntemler bu kotaya uyar, örneğin ReadContentAsString yöntemi. Value Okuyucudaki özellik bu kotadan etkilenmez ve bu nedenle bu kotanın sağladığı koruma gerektiğinde kullanılmamalıdır.

MaxArrayLength

Bu kota, bayt dizileri de dahil olmak üzere XML okuyucusunun döndürdüğü temel öğe dizisinin en büyük boyutunu sınırlar. Bu kota, XML okuyucunun kendisinde değil, okuyucuyu kullanan bileşende bellek tüketimini sınırlamaz. Örneğin, DataContractSerializerMaxArrayLength ile güvenli bir okuyucu kullandığında, bu kotadan daha büyük bayt dizilerini seri durumdan çıkarmaz. Akış ve arabelleğe alınan programlama modellerini tek bir sözleşmede karıştırmaya çalışırken bu kotanın ayarlanması önemlidir. sınıfını XmlDictionaryReader doğrudan kullanırken, yalnızca gibi ReadInt32Arraybelirli temel türlerin rastgele boyuttaki dizilerini okumak için özel olarak tasarlanmış yöntemlerin bu kotaya uygun olduğunu unutmayın.

İkili Kodlamaya Özgü Tehditler

WCF'nin desteklediği ikili XML kodlaması bir sözlük dizeleri özelliği içerir. Büyük bir dize yalnızca birkaç bayt kullanılarak kodlanabilir. Bu, önemli performans kazançları sağlar, ancak hafifletilmesi gereken yeni hizmet reddi tehditleri sağlar.

İki tür sözlük vardır: statik ve dinamik. Statik sözlük, ikili kodlamada kısa bir kod kullanılarak temsil edilebilen uzun dizelerin yerleşik bir listesidir. Okuyucu oluşturulduğunda bu dize listesi sabitlenir ve değiştirilemez. WCF'nin varsayılan olarak kullandığı statik sözlükteki dizelerin hiçbiri ciddi bir hizmet reddi tehdidi oluşturacak kadar büyük değildir, ancak yine de sözlük genişletme saldırısında kullanılabilirler. Kendi statik sözlüğünüzü sağladığınız gelişmiş senaryolarda, büyük sözlük dizelerini eklerken dikkatli olun.

Dinamik sözlükler özelliği, iletilerin kendi dizelerini tanımlamasına ve bunları kısa kodlarla ilişkilendirmesine olanak tanır. Bu dizeden koda eşlemeler, sonraki iletilerin dizeleri yeniden göndermesi gerekmeyecek ve önceden tanımlanmış kodları kullanabilecek şekilde iletişim oturumunun tamamında bellekte tutulur. Bu dizeler rastgele uzunlukta olabilir ve bu nedenle statik sözlüktekilerden daha ciddi bir tehdit oluşturur.

Azaltılması gereken ilk tehdit, dinamik sözlüğün (dizeden koda eşleme tablosu) çok büyük olma olasılığıdır. Bu sözlük birkaç ileti boyunca genişletilebilir ve bu nedenle MaxReceivedMessageSize kota yalnızca her ileti için ayrı ayrı geçerli olduğundan koruma sunmayabilir. Bu nedenle, MaxSessionSize üzerinde sözlüğün boyutunu sınırlayan ayrı bir özellik bulunmaktadır.

Diğer kotaların çoğundan farklı olarak, bu kota iletileri yazarken de geçerlidir. Mesaj okunurken bir sınır aşıldığında, QuotaExceededException her zamanki gibi fırlatılır. Mesaj yazılırken kota aşılırsa, kota aşımına neden olan tüm dizeler dinamik sözlükler özelliği kullanılmadan as-isolarak yazılır.

Sözlük Genişletme Tehditleri

İkiliye özgü saldırıların önemli bir sınıfı sözlük genişletmesinden kaynaklandı. İkili biçimdeki küçük bir ileti, dize sözlükleri özelliğinden kapsamlı bir şekilde yararlanıyorsa, tamamen genişletilmiş metin biçiminde çok büyük bir iletiye dönüşebilir. Dinamik sözlük dizeleri için genişletme faktörü kotayla MaxSessionSize sınırlıdır çünkü hiçbir dinamik sözlük dizesi tüm sözlüğün en büyük boyutunu aşmaz.

MaxNameTableCharCount, MaxStringContentLengthve MaxArrayLength özellikleri yalnızca bellek tüketimini sınırlar. Normalde, akışsız kullanımda tehditleri hafifletmeleri gerekmemektedir çünkü bellek kullanımı MaxReceivedMessageSize tarafından zaten sınırlıdır. Ancak, MaxReceivedMessageSize genişletme öncesi baytları sayar. İkili kodlama kullanımda olduğunda, bellek tüketimi, yalnızca bir MaxReceivedMessageSize faktörüyle sınırlı olarak, MaxSessionSize değerinin ötesine geçebilir. Bu nedenle, ikili kodlama kullanılırken her zaman tüm okuyucu kotalarını (özellikle MaxStringContentLength) ayarlamak önemlidir.

DataContractSerializer ile birlikte ikili kodlama kullanıldığında, IExtensibleDataObject arabirimi bir sözlük genişletme saldırısı yapmak için kötüye kullanılabilir. Bu arabirim temelde sözleşmenin bir parçası olmayan rastgele veriler için sınırsız depolama alanı sağlar. Eğer MaxSessionSize ile MaxReceivedMessageSize çarpıldığında sorun oluşturmaması için kotalar yeterince düşük ayarlanamıyorsa, ikili kodlamayı kullanırken IExtensibleDataObject özelliğini devre dışı bırakın. IgnoreExtensionDataObject özniteliğinde true özelliğini ServiceBehaviorAttribute değerine ayarlayın. Alternatif olarak IExtensibleDataObject arabirimini uygulamayın. Daha fazla bilgi için bkz. Forward-Compatible Veri Sözleşmeleri.

Kota Özeti

Aşağıdaki tabloda kotalarla ilgili yönergeler özetlemektedir.

Koşul Ayarlanacağı önemli kotalar
Akış yok veya küçük iletiler, metin veya MTOM kodlamasının akışı yok. MaxReceivedMessageSize, MaxBytesPerRead ve MaxDepth
Akış veya küçük mesajların akışı yok, ikili kodlama MaxReceivedMessageSize, MaxSessionSizeve tümü ReaderQuotas
Büyük iletileri, metinleri veya MTOM kodlamasını akışla aktarma MaxBufferSize ve tümü ReaderQuotas
Büyük iletilerin akışı, ikili kodlama MaxBufferSize, MaxSessionSizeve tümü ReaderQuotas

  • Taşımacılık seviyesindeki zaman aşımları her zaman ayarlanmalı ve akış kullanıldığında, büyük veya küçük iletilerin akışı fark etmeksizin, senkron okuma/yazma kullanılmamalıdır.

  • Kota konusunda şüpheye düştüğünüzde, kotayı açık bırakmak yerine güvenli bir değere ayarlayın.

Kötü Amaçlı Kod Yürütmeyi Engelleme

Aşağıdaki genel tehdit sınıfları kodu yürütebilir ve istenmeyen etkilere sahip olabilir:

  • Deserleştirici, kötü amaçlı, güvenli olmayan veya güvenliğe duyarlı bir tür yükler.

  • Gelen ileti, seri durumdan çıkarıcının normalde güvenli bir türün örneğini istenmeyen sonuçlar doğuracak şekilde oluşturmasına neden olur.

Aşağıdaki bölümlerde bu tehdit sınıfları daha ayrıntılı olarak açıklanmıştır.

DataContractSerializer

(XmlSerializer üzerindeki güvenlik bilgileri için ilgili belgelere bakın.) XmlSerializer için güvenlik modeli, DataContractSerializer ile benzer olup, çoğunlukla ayrıntılarda farklılık gösterir. Örneğin, tür ekleme için XmlIncludeAttribute özniteliği, KnownTypeAttribute özniteliği yerine kullanılır. Ancak, 'a XmlSerializer özgü bazı tehditler bu konunun ilerleyen bölümlerinde ele alınmıştır.

İstenmeyen Türlerin Yüklenmesini Engelleme

İstenmeyen türlerin yüklenmesi, türün kötü amaçlı olması veya yalnızca güvenlik açısından hassas yan etkileri olması fark etmeksizin önemli sonuçlara neden olabilir. Bir tür kötüye kullanılabilir güvenlik açığı içerebilir, oluşturucusunda veya sınıf oluşturucusunda güvenlik duyarlı eylemler gerçekleştirebilir, hizmet reddi saldırılarını kolaylaştıran geniş bir bellek kullanımına sahip olabilir veya kurtarılamayan hatalar oluşturabilir. Türler, tür yüklenir yüklenmez ve herhangi bir örnek oluşturulmadan önce çalışan sınıf oluşturucularına sahip olabilir. Bu nedenlerle, deseriyalize edicinin yükleyebileceği tür kümesini denetlemek önemlidir.

DataContractSerializer gevşek bir şekilde bağlı olarak serileştirmeyi kaldırır. Gelen verilerden ortak dil çalışma zamanı (CLR) türünü ve derleme adlarını hiçbir zaman okumaz. Bu, XmlSerializer davranışına benzer, ancak NetDataContractSerializer, BinaryFormatter ve SoapFormatter davranışlarından farklıdır. Gevşek bağlantı bir güvenlik derecesi sağlar, çünkü uzak saldırgan yalnızca iletideki bu türü adlandırarak yüklenecek rastgele bir tür belirtemez.

Her zaman DataContractSerializer sözleşmeye göre o anda beklenen bir türü yüklemesine izin verilir. Örneğin, bir veri sözleşmesinin Customer türünde bir veri üyesi varsa, bu veri üyesi seri durumdan çıkarıldığında DataContractSerializer türünün yüklenmesine Customer izin verilir.

Ayrıca, DataContractSerializer polimorfizmi destekler. Veri üyesi olarak Objectbildirilebilir, ancak gelen veriler bir Customer örnek içerebilir. Bu, yalnızca türün çözücüye şu mekanizmalardan biri aracılığıyla "tanıtıldığı" durumlarda mümkündür:

  • KnownTypeAttribute bir türe uygulanan öznitelik.

  • KnownTypeAttribute türü listesini döndüren bir yöntemi belirten öznitelik.

  • ServiceKnownTypeAttribute özniteliği.

  • Yapılandırma KnownTypes bölümü.

  • Seri hale getiriciyi doğrudan kullanıyorsanız, oluşturma sırasında DataContractSerializer öğesine açıkça geçirilen bilinen türlerin listesi.

Bu mekanizmaların her biri, seri halden çıkarıcının yükleyebileceği daha fazla tür ekleyerek yüzey alanını genişletir. Kötü amaçlı veya istenmeyen türlerin bilinen türler listesine eklenmediğinden emin olmak için bu mekanizmaların her birini kontrol edin.

Bilinen bir tür kapsam dahilinde olduğunda, herhangi bir zamanda yüklenebilir ve sözleşme onu gerçekten kullanmasını yasaklasa bile türün örnekleri oluşturulabilir. Örneğin, "MyDangerousType" türünün yukarıdaki mekanizmalardan biri kullanılarak bilinen türler listesine eklendiğini varsayalım. Bu, şu anlama gelir:

  • MyDangerousType yüklenir ve sınıf oluşturucu çalışır.

  • Bir veri sözleşmesini bir dize veri üyesiyle seri hale getirirken bile, kötü amaçlı bir ileti yine de bir MyDangerousType örneğinin oluşmasına neden olabilir. MyDangerousType içindeki kod, özellik ayarlayıcıları gibi, çalıştırılabilir. Bu yapıldıktan sonra, deseriyalize edici bu örneği dize veri üyesine atamaya çalışır ve özel durum ile başarısız olur.

Bilinen türlerin listesini döndüren bir yöntem yazarken veya listeyi doğrudan oluşturucuya DataContractSerializer geçirirken, listeyi hazırlayan kodun güvenli olduğundan ve yalnızca güvenilir verilerde çalıştığından emin olun.

Yapılandırmada bilinen türler belirtiliyorsa, yapılandırma dosyasının güvenli olduğundan emin olun. Yapılandırmada her zaman tanımlayıcı adlar kullanın (türün bulunduğu imzalı derlemenin ortak anahtarını belirterek), ancak yüklenecek türün sürümünü belirtmeyin. Tür yükleyicisi mümkünse otomatik olarak en son sürümü seçer. Yapılandırmada belirli bir sürüm belirtirseniz, şu riski çalıştırırsınız: Bir tür, gelecekteki bir sürümde düzeltilebilen bir güvenlik açığına sahip olabilir, ancak güvenlik açığı olan sürüm yapılandırmada açıkça belirtildiğinden yine de yüklenir.

Bilinen çok fazla türün başka bir sonucu vardır: DataContractSerializer, uygulama etki alanında serileştirme/seri durumdan çıkarma kodları için bir önbellek oluşturur ve her tür için serileştirmesi ve seri durumdan çıkarması gereken bir kayıt içerir. Uygulama etki alanı çalıştığı sürece bu önbellek hiçbir zaman temizlenmemiştir. Bu nedenle, bir uygulamanın bilinen birçok tür kullandığının farkında olan bir saldırgan, tüm bu türlerin seri durumdan çıkarılmasına neden olabilir ve bu da önbelleğin orantısız büyük miktarda bellek kullanmasına neden olabilir.

Türlerin İstenmeyen Durumda Olmasını Önleme

Bir tür, uygulanması gereken iç tutarlılık kısıtlamalarına sahip olabilir. Seri durumdan çıkarma sırasında bu kısıtlamaların ihlal edilmemesi için dikkatli olunmalıdır.

Aşağıdaki tür örneği, bir uzay aracındaki hava kilidi durumunu temsil eder ve hem iç hem de dış kapıların aynı anda açık olamayacağı kısıtlamasını uygular.

[DataContract]
public class SpaceStationAirlock
{
    [DataMember]
    private bool innerDoorOpenValue = false;
    [DataMember]
    private bool outerDoorOpenValue = false;

    public bool InnerDoorOpen
    {
        get { return innerDoorOpenValue; }
        set
        {
            if (value & outerDoorOpenValue)
                throw new Exception("Cannot open both doors!");
            else innerDoorOpenValue = value;
        }
    }
    public bool OuterDoorOpen
    {
        get { return outerDoorOpenValue; }
        set
        {
            if (value & innerDoorOpenValue)
                throw new Exception("Cannot open both doors!");
            else outerDoorOpenValue = value;
        }
    }
}

<DataContract()> _
Public Class SpaceStationAirlock
    <DataMember()> Private innerDoorOpenValue As Boolean = False
    <DataMember()> Private outerDoorOpenValue As Boolean = False

    Public Property InnerDoorOpen() As Boolean
        Get

            Return innerDoorOpenValue
        End Get
        Set(ByVal value As Boolean)
            If (value & outerDoorOpenValue) Then
                Throw New Exception("Cannot open both doors!")
            Else
                innerDoorOpenValue = value
            End If
        End Set
    End Property

    Public Property OuterDoorOpen() As Boolean
        Get
            Return outerDoorOpenValue
        End Get
        Set(ByVal value As Boolean)
            If (value & innerDoorOpenValue) Then
                Throw New Exception("Cannot open both doors!")
            Else
                outerDoorOpenValue = value
            End If
        End Set
    End Property
End Class

Saldırgan, kısıtlamaları aşarak ve nesneyi geçersiz bir duruma getirerek bunun gibi kötü amaçlı bir ileti gönderebilir ve bu da istenmeyen ve öngörülemeyen sonuçlara yol açabilir.

<SpaceStationAirlock>
    <innerDoorOpen>true</innerDoorOpen>
    <outerDoorOpen>true</outerDoorOpen>
</SpaceStationAirlock>

Bu durum, aşağıdaki noktaların farkında olarak önlenebilir:

  • Çoğu sınıfı seri durumdan DataContractSerializer çıkardığında oluşturucular çalışmaz. Bu nedenle, oluşturucuda yapılan herhangi bir durum yönetimine güvenmeyin.

  • Nesnenin geçerli bir durumda olduğundan emin olmak için geri çağırmaları kullanın. Özniteliği ile OnDeserializedAttribute işaretlenen geri çağırma, özellikle yararlıdır çünkü deseriyalizasyon tamamlandıktan sonra çalışır ve genel durumu inceleyip düzeltme fırsatı sunar. Daha fazla bilgi için bkz .Version-Tolerant Serileştirme Geri Çağırmaları.

  • Özellik ayarlayıcılarının çağrılacağı belirli bir sıraya bağlı olarak veri sözleşmesi türleri tasarlamayın.

  • özniteliğiyle SerializableAttribute işaretlenmiş eski türleri kullanmaya dikkat edin. Bunların çoğu sadece güvenilir verilerle kullanılmak üzere .NET Framework'un uzaktan iletişim işlevleriyle çalışacak şekilde tasarlanmıştır. Bu öznitelikle işaretlenen mevcut türler durum güvenliği göz önünde bulundurularak tasarlanmamış olabilir.

  • Özniteliğin IsRequired özelliğine güvenmeyin, çünkü durum güvenliği söz konusu olduğunda verilerin varlığını garanti edemez. Veriler her zaman null, zero veya invalid olabilir.

  • Önce doğrulamadan, güvenilmeyen bir veri kaynağından deserialize edilen nesne grafiğine asla güvenmeyin. Tek tek her bir nesne tutarlı bir durumda olabilir, ancak bir bütün olarak nesne grafiği bu durumda olmayabilir. Ayrıca, nesne grafı koruma modu devre dışı bırakılsa bile seri durumdan çıkarılmış grafiğin aynı nesneye birden çok başvurusu olabilir veya döngüsel başvuruları olabilir. Daha fazla bilgi için bkz . Serileştirme ve Seri Durumdan Çıkarma.

NetDataContractSerializer'ı Güvenli Bir Şekilde Kullanma

, NetDataContractSerializer türlere sıkı bağlama kullanan bir serileştirme altyapısıdır. Bu, BinaryFormatter ve SoapFormatter ile benzerdir. Başka bir ifadeyle, gelen verilerden .NET Framework derlemesini ve tür adını okuyarak hangi türün örneğini oluşturacaklarını belirler. WCF'nin bir parçası olmasına rağmen, bu serileştirme altyapısını takmanın sağlanan bir yolu yoktur; özel kod yazılmalıdır. NetDataContractSerializer esas olarak .NET Framework uzaktan iletişiminden WCF'ye geçişi kolaylaştırmak için sağlanır. Daha fazla bilgi için SeriLeştirme ve Seri Durumdan Çıkarma'nın ilgili bölümüne bakın.

İletinin kendisi herhangi bir türün yüklenebileceğini gösterebileceğinden, NetDataContractSerializer mekanizma doğal olarak güvenli değildir ve yalnızca güvenilir verilerle kullanılmalıdır. Daha fazla bilgi için bkz . BinaryFormatter güvenlik kılavuzu.

Güvenilir verilerle kullanıldığında bile, özellikle AssemblyFormat özelliği Simple olarak ayarlanmışsa, gelen veriler yüklenecek türü yetersiz bir şekilde belirtebilir. Uygulamanın dizinine veya genel bütünleştirilmiş kod önbelleğine erişimi olan herkes yüklenmesi gereken türün yerine kötü amaçlı bir tür kullanabilir. İzinleri doğru ayarlayarak her zaman uygulamanızın dizininin ve genel derleme önbelleğinin güvenliğini sağlayın.

Genel olarak, örneğiniz NetDataContractSerializer için kısmen güvenilen kod erişimine izin verirseniz veya vekil seçiciyi (ISurrogateSelector) veya seri hale getirme bağlayıcısını ()SerializationBinder başka bir şekilde denetlerseniz, kod serileştirme/seri durumdan çıkarma işlemi üzerinde çok fazla denetime sahip olabilir. Örneğin, rastgele türler enjekte edebilir, bilgi ifşasına yol açabilir, sonuçta elde edilen nesne grafiğiyle veya serileştirilmiş verilerle oynayabilir ya da serileştirilmiş akışın taşmasına neden olabilir.

ile NetDataContractSerializer ilgili bir diğer güvenlik sorunu da kötü amaçlı kod yürütme tehdidi değil hizmet reddidir. NetDataContractSerializer kullanırken, MaxItemsInObjectGraph kotasını her zaman güvenli bir değere ayarlayın. Boyutu yalnızca bu kotayla sınırlı olan bir nesne dizisi ayıran küçük bir kötü amaçlı ileti oluşturmak kolaydır.

XmlSerializer-Specific Tehditler

Güvenlik modeli XmlSerializer, DataContractSerializer modeline benzerdir. Bununla birlikte, birkaç tehdit XmlSerializer için benzersizdir.

XmlSerializer çalışma zamanında, kodu seri hale getiren ve seri durumdan çıkaran serileştirme derlemeleri oluşturur; bu derlemeler geçici dosyalar dizininde oluşturulur. Başka bir işlem veya kullanıcı bu dizine erişim haklarına sahipse, serileştirme/seri durumdan çıkarma kodunun üzerine rastgele kodla yazabilir. XmlSerializer daha sonra bu kodu serileştirme/seri durumdan çıkarma kodu yerine güvenlik bağlamını kullanarak çalıştırır. Bunun gerçekleşmesini önlemek için geçici dosyalar dizininde izinlerin doğru ayarlandığından emin olun.

Ayrıca XmlSerializer, çalışma zamanında serileştirme derlemelerini oluşturmak yerine önceden oluşturulmuş olanları kullandığı bir moda sahiptir. XmlSerializer uygun bir serileştirme derlemesi bulduğunda bu mod tetiklenir. serileştirme derlemesinin, serileştirilmekte olan türlerin bulunduğu derlemeyi imzalamak için kullanılan aynı anahtar tarafından imzalanıp imzalanmadığını kontrol eder. Bu, serileştirme derlemeleri olarak gizlenen kötü amaçlı derlemelere karşı koruma sağlar. Ancak, serileştirilebilir türlerinizi içeren derleme imzalı değilse, XmlSerializer bu denetimi gerçekleştiremez ve doğru ada sahip herhangi bir derleme kullanır. Bu, kötü amaçlı kod çalıştırmayı mümkün kılar. Her zaman seri hale getirilebilir türlerinizi içeren derlemeleri imzalayın veya kötü amaçlı derlemelerin kullanıma sunulmasını önlemek için uygulamanızın dizinine ve genel derleme önbelleğine erişimi sıkı bir şekilde denetleyin.

Bu XmlSerializer bir hizmet reddi saldırısına maruz kalabilir. XmlSerializer için kota yok MaxItemsInObjectGraph, ancak DataContractSerializer üzerinde mevcuttur. Bu nedenle, yalnızca ileti boyutuyla sınırlı olan rastgele bir nesne miktarını seri durumdan çıkartır.

Kısmi Güven Tehditleri

Kısmi güvenle çalışan kodla ilgili tehditlerle ilgili aşağıdaki endişelere dikkat edin. Bu tehditler, kötü amaçlı kısmen güvenilen kodun yanı sıra diğer saldırı senaryolarıyla birlikte kötü amaçlı kısmen güvenilen kodu (örneğin, belirli bir dizeyi oluşturan ve ardından seri durumdan çıkaran kısmen güvenilen kod) içerir.

  • Herhangi bir serileştirme bileşeni kullanırken, serileştirme senaryosunun tamamı onayınızın kapsamında olsa ve güvenilmeyen veri veya nesnelerle uğraşmasanız bile, bu tür kullanımdan önce hiçbir izin onaylamayın. Bu tür kullanımlar güvenlik açıklarına yol açabilir.

  • Kısmen güvenilen kodun genişletilebilirlik noktaları (vekiller), serileştirilen türler veya başka yollarla serileştirme işlemi üzerinde denetimi olduğu durumlarda, kısmen güvenilen kod, serileştiricinin serileştirilmiş akışa büyük miktarda veri çıkarmasına neden olabilir. Bu, bu akışı alan alıcıda Hizmet Engelleme (DoS) saldırısına yol açabilir. DoS tehditlerine duyarlı bir hedefe yönelik verileri serileştiriyorsanız, kısmen güvenilen türleri seri hale getirmeyin veya kısmen güvenilen kod denetimi serileştirmesine izin vermeyin.

  • Örneğiniz DataContractSerializer için kısmen güvenilen kod erişimine izin verirseniz veya Veri Sözleşmesi Vekillerini başka bir şekilde denetlerseniz, serileştirme/seri durumdan çıkarma işlemi üzerinde çok fazla denetime sahip olabilir. Örneğin, rastgele türler enjekte edebilir, bilgi ifşasına yol açabilir, sonuçta elde edilen nesne grafiğiyle veya serileştirilmiş verilerle oynayabilir ya da serileştirilmiş akışın taşmasına neden olabilir. Eşdeğer NetDataContractSerializer bir tehdit, "NetDataContractSerializer Güvenli Bir Şekilde Kullanma" bölümünde açıklanmıştır.

  • DataContractAttribute özniteliği bir türe uygulanırsa (veya SerializableAttribute olarak işaretlenmiş ancak ISerializable değilse), seri durumdan çıkarıcı, tüm oluşturucular genel değil veya belirli taleplerle korunsa bile bu türün bir örneğini oluşturabilir.

  • Seri durumdan çıkarılacak verilere güvenilmediği ve bilinen tüm türlerin güvendiğiniz türler olduğundan emin olmadığınız sürece seri durumdan çıkarmanın sonucuna asla güvenmeyin. Kısmi güven içinde çalışırken bilinen türlerin uygulama yapılandırma dosyasından yüklenmediğini (ancak bilgisayar yapılandırma dosyasından yüklendiğini) unutmayın.

  • Kısmi güvenlikli koda vekil nesne eklenmiş bir DataContractSerializer örneği iletirseniz, kod bu vekil nesnedeki değiştirilebilir ayarların tümünü değiştirebilir.

  • Seri durumdan çıkarılmış bir nesne için, XML okuyucusu (veya buradaki veriler) kısmen güvenilen koddan geliyorsa, sonuçta elde edilen seri durumdan çıkarılmış nesneyi güvenilmeyen veriler olarak değerlendirin.

  • Türün ExtensionDataObject genel üye içermemesi, içindeki verilerin güvenli olduğu anlamına gelmez. Örneğin, ayrıcalıklı bir veri kaynağından bazı verilerin bulunduğu bir nesneye seri durumdan çıkarırsanız, bu nesneyi kısmen güvenilir koda teslim ederseniz, kısmen güvenilir kod nesneyi seri hale getirerek ExtensionDataObject içindeki verileri okuyabilir. IgnoreExtensionDataObject'i, ayrıcalıklı bir veri kaynağından seri durumdan çıkarılan ve daha sonra kısmen güvenilen koda geçirilen bir nesneye true olarak ayarlamayı göz önünde bulundurun.

  • DataContractSerializer ve DataContractJsonSerializer tam güven altında özel, korumalı, dahili ve genel üyelerin seri hale getirilmesini destekler. Ancak kısmi güven düzeyinde, yalnızca genel üyeler seri hale getirilebilir. Bir uygulama, ortak olmayan bir üyeyi seri hale getirme girişiminde bulunduğunda SecurityException atılır.

    İç veya korumalı iç üyelerin kısmi güven içinde serileştirilmesine izin vermek için derleme özniteliğini InternalsVisibleToAttribute kullanın. Bu öznitelik, bir derlemenin iç üyelerinin başka bir derlemeye görünür olduğunu bildirmesine olanak tanır. Bu durumda, iç üyelerini serileştirilmiş hale getirmek isteyen bir derleme, iç üyelerinin System.Runtime.Serialization.dlliçin görünür olduğunu açıkça belirtir.

    Bu yaklaşımın avantajı, yükseltilmiş bir kod oluşturma yolu gerektirmemesidir.

    Aynı zamanda, iki önemli dezavantaj vardır.

    İlk dezavantaj, InternalsVisibleToAttribute özniteliğinin katılım özelliğinin tüm derleme genelinde olmasıdır. Başka bir ifadeyle, yalnızca belirli bir sınıfın iç üyelerinin seri hale getirilebileceğini belirtemezsiniz. Elbette, belirli bir iç üyeyi seri hale getirmemeyi tercih edebilirsiniz; bunun için tek yapmanız gereken o üyeye bir DataMemberAttribute özniteliği eklememektir. Benzer şekilde, bir geliştirici görünürlük sorunlarını biraz gözeterek bir üyeyi özel veya korumalı yerine dahili yapmayı seçebilir.

    İkinci dezavantaj, özel veya korumalı üyeleri hala desteklememesidir.

    Özniteliğin InternalsVisibleToAttribute kısmi güven içinde kullanımını göstermek için aşağıdaki programı göz önünde bulundurun:

        public class Program
    {
        public static void Main(string[] args)
        {
            try
            {
//              PermissionsHelper.InternetZone corresponds to the PermissionSet for partial trust.
//              PermissionsHelper.InternetZone.PermitOnly();
                MemoryStream memoryStream = new MemoryStream();
                new DataContractSerializer(typeof(DataNode)).
                    WriteObject(memoryStream, new DataNode());
            }
            finally
            {
                CodeAccessPermission.RevertPermitOnly();
            }
        }

        [DataContract]
        public class DataNode
        {
            [DataMember]
            internal string Value = "Default";
        }
    }

    Yukarıdaki örnekte, kısmi güven için PermissionsHelper.InternetZone'ye PermissionSet eşleşir. Artık özniteliği olmadan InternalsVisibleToAttribute uygulama başarısız olur ve genel olmayan üyelerin kısmi güvende serileştirilemeyeceğini belirten bir SecurityException oluşturur.

    Ancak, kaynak dosyaya aşağıdaki satırı eklersek, program başarıyla çalışır.

    [assembly:System.Runtime.CompilerServices.InternalsVisibleTo("System.Runtime.Serialization, PublicKey = 00000000000000000400000000000000")]

Diğer Durum Yönetimi Endişeleri

Nesne durumu yönetimiyle ilgili diğer birkaç endişeden bahsetmeye değer:

  • Akış tabanlı programlama modelini bir akış aktarımıyla kullanırken, ileti geldikçe iletinin işlenmesi gerçekleşir. Mesajı gönderen, akışın ortasında gönderme işlemini iptal edebilir ve bu durum daha fazla içerik bekleniyorsa kodunuzu tahmin edilemez bir hale getirebilir. Genel olarak, akışın tamamlandığına güvenmeyin ve akışın durdurulması durumunda geri alınamayan akış tabanlı bir işlemde herhangi bir çalışma gerçekleştirmeyin. Bu durum, akış gövdesinden sonra iletinin hatalı biçimlendirilmiş olabileceği durum için de geçerlidir (örneğin, SOAP zarfı için bir bitiş etiketi eksik olabilir veya ikinci bir ileti gövdesi olabilir).

  • Özelliğin IExtensibleDataObject kullanılması hassas verilerin yayılmalarına neden olabilir. Güvenilmeyen bir kaynaktan alınan verileri, iletilerin imzalandığı güvenli bir kanalda veri sözleşmelerine IExtensibleObjectData kabul ediyor ve daha sonra yeniden yayıyorsanız, büyük olasılıkla hakkında hiçbir şey bilmediğiniz verilere kefil olursunuz. Ayrıca, hem bilinen hem de bilinmeyen veri parçalarını hesaba katıyorsanız, gönderdiğiniz genel durum geçersiz olabilir. Uzantı veri özelliğini null seçmeli olarak ayarlayarak veya IExtensibleObjectData özelliği seçmeli olarak devre dışı bırakarak bu durumdan kaçının.

Şema İçeri Aktarma

Normalde, türleri oluşturmak için şemayı içeri aktarma işlemi yalnızca tasarım zamanında gerçekleşir; örneğin, bir istemci sınıfı oluşturmak için bir Web hizmetinde ServiceModel Meta Veri Yardımcı Programı Aracı (Svcutil.exe) kullanılır. Ancak daha gelişmiş senaryolarda şemayı çalışma zamanında işleyebilirsiniz. Bunu yapmanın sizi hizmet reddi risklerine maruz bırakabileceğini unutmayın. Bazı şemaların içeri aktarılması uzun sürebilir. Şemalar XmlSerializer güvenilmeyen bir kaynaktan geliyorsa, şema içeri aktarma bileşenini bu tür senaryolarda asla kullanmayın.

ASP.NET AJAX Tümleştirmesine Özgü Tehditler

Kullanıcı WebScriptEnablingBehavior veya WebHttpBehavior uyguladığında, WCF hem XML hem de JSON iletilerini kabul edebilen bir uç birim gösterir. Ancak, hem XML okuyucusu hem de JSON okuyucusu tarafından kullanılan tek bir okuyucu kotası kümesi vardır. Bazı kota ayarları bir okuyucu için uygun olabilir, ancak diğeri için çok büyük olabilir.

uygulamasını uygularken WebScriptEnablingBehavior, kullanıcının uç noktada bir JavaScript ara sunucusunu kullanıma sunma seçeneği vardır. Aşağıdaki güvenlik sorunları dikkate alınmalıdır:

  • Hizmet hakkındaki bilgiler (işlem adları, parametre adları vb.) JavaScript proxy'si incelenerek elde edilebilir.

  • JavaScript uç noktası kullanılırken, hassas ve özel bilgiler istemci Web tarayıcısı önbelleğinde tutulabilir.

Bileşenlerle ilgili Bir Not

WCF esnek ve özelleştirilebilir bir sistemdir. Bu konunun içeriğinin çoğu en yaygın WCF kullanım senaryolarına odaklanır. Ancak, WCF'nin birçok farklı şekilde sağladığı bileşenleri oluşturmak mümkündür. Her bileşeni kullanmanın güvenlik etkilerini anlamak önemlidir. Özellikle:

  • XML okuyucuları kullanmanız gerektiğinde, XmlDictionaryReader sınıfının sağladığı okuyucuları kullanın, diğer okuyucular yerine. Güvenli okuyucular, CreateTextReader, CreateBinaryReader veya CreateMtomReader yöntemleri kullanılarak oluşturulur. yöntemini kullanmayın Create . Okuyucuları her zaman güvenli kotalarla yapılandırın. WCF'deki serileştirme altyapıları yalnızca WCF'den güvenli XML okuyucularla kullanıldığında güvenlidir.

  • Potansiyel olarak güvenilir olmayabilecek verileri seri durumdan çıkarmak için DataContractSerializer kullanırken, her zaman MaxItemsInObjectGraph özelliğini ayarlayın.

  • Eğer maxSizeOfHeaders yeterli koruma sunmuyorsa, bir ileti oluştururken MaxReceivedMessageSize parametresini ayarlayın.

  • Kodlayıcı oluştururken, her zaman MaxSessionSize ve MaxBufferSize gibi ilgili kotaları yapılandırın.

  • XPath ileti filtresi kullanırken, filtreden geçen XML düğümlerinin miktarını sınırlamak için NodeQuota öğesini ayarlayın. Çok sayıda düğümü ziyaret etmeden işlem yapması uzun sürebilecek XPath ifadelerini kullanmayın.

  • Genel olarak, kota kabul eden herhangi bir bileşeni kullanırken, güvenlik etkilerini anlayın ve bunu güvenli bir değere ayarlayın.

Ayrıca bakınız

  • Last updated on