Veriler için Güvenlik Konuları

  • Makale

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 yanıt vermeye zorlar.

Kullanıcı Tarafından Sağlanan Kod ve Kod Erişim Güvenliği

Windows Communication Foundation (WCF) altyapısında kullanıcı tarafından sağlanan bir dizi yer çalıştırma kodu. Ö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ı, sınıfın kullanıcı tarafından sağlanan türetilmiş sınıflarını Message da çağırabilir.

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.

Not

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 noktalara bir göz atın:

  • 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 kullanıma sunılmasını istemiyorsanız, serileştirmeyi devre dışı bırakın (örneğin, bir veri sözleşmesi söz konusu olduğunda özniteliği uygulamayarak DataMemberAttribute ).

  • Aynı türün kullanımdaki seri hale getiriciye bağlı olarak birden çok serileştirme projeksiyonu olabileceğini unutmayın. Aynı tür ile kullanıldığında bir veri kümesini ve ile DataContractSerializer kullanıldığında XmlSerializerbaş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 bir OutOfMemoryException özel durumla veya tüm kullanılabilir yığınlara erişilmesine neden olur ve bu da bir StackOverflowExceptionile sonuçlanır.

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. Bunlar, kullanımda olan belirli aktarım kanalı (HTTP, TCP vb.) tarafından zorlanan 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.

Karma Tablo 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ışsız durumda iletiler belleğe arabelleğe alınır. Bu durumda, erişilmesi gereken MaxReceivedMessageSize en büyük ileti boyutunu sınırlayarak büyük iletilere karşı koruma sağlamak için sistem tarafından sağlanan bağlamalarda veya üzerindeki kotayı TransportBindingElement kullanı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 azaltma ö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, 1 MB ve 1 MB'lık bir ileti alınırsa ve seri durumdan çıkarılırsa MaxReceivedMessageSize , seri durumdan çıkarılmış nesne grafiğini içermek için ek bellek gerekir ve toplam bellek tüketimi 1 MB'ın ü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şilir. 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 birleştirilmiştir.

MaxReceivedMessageSize tek başına tüm hizmet reddi saldırılarını önlemek için yeterli değildir. Örneğin, seri durumdan çıkarıcı, derin iç içe nesne grafını (henüz başka bir nesne içeren başka bir nesneyi içeren bir nesne vb.) gelen bir iletiyle seri durumdan çıkarmak zorunda kalabilir. DataContractSerializer Hem hem de XmlSerializer çağrı yöntemleri, bu tür grafikleri seri durumdan çıkarmak için iç içe yerleştirilmiş bir şekilde. Yöntem çağrılarının derin iç içe yerleştirmesi kurtarılamaz bir ile sonuçlanabilir StackOverflowException. Bu tehdit, konunun devamında yer alan "XML Kasa ly kullanma" bölümünde açıklandığı gibi, xml iç içe yerleştirme düzeyini sınırlamak için kota ayarlanarak MaxDepth 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. Xml'e özgü bu tür tehditleri azaltmak için, bu konunun devamında yer alan "XML Kasa ly 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. Bu durumda, bellekte neredeyse hiç veri arabelleğe alınmaması ve iletinin doğrudan diske akışla gönderilmesini beklerken değerini son derece büyük bir değere ayarlayın MaxReceivedMessageSize . 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, arabelleğe almayı sınırlayan çeşitli WCF veri işleme bileşenlerinde belirli kota ayarları vardı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, ile MaxReceivedMessageSizeolduğu gibi, birden çok iletinin aynı anda işlenme olasılığının farkında olun.

MaxBufferSize Ayrıntıları

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

WCF, değeri arabelleğe alınabilecek çeşitli bileşenlere geçirerek MaxBufferSize bunu gerçekleştirir. Örneğin, sınıfın Message bazı CreateMessage aşırı yüklemeleri bir maxSizeOfHeaders parametre alır. WCF, SOAP üst bilgi arabelleği miktarını sınırlamak için değerini bu parametreye geçirir MaxBufferSize . Sınıfı doğrudan kullanılı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şturmak için MTOM ileti kodlayıcı bağlama öğesi kullanılırken, akış kullanılırken özelliğini güvenli bir değere ayarlamak MaxBufferSize önemlidir.

XML Tabanlı Akış Saldırıları

MaxBufferSize tek başına, akış beklendiğinde WCF'nin arabelleğe alınmaya zorlanamayacağından emin olmak 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 OutOfMemoryExceptionolur. Bu, bu konunun devamında yer alan "XML Kasa ly 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 ilk MaxReceivedMessageSize işlemin büyük akışları işlemesini sağlamak için bunun büyük bir değere ayarlandığı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 seri durumdan çıkarıcı, 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ğini olarak ayarlayarak IgnoreExtensionDataObject özelliği ServiceBehaviorAttributetruekapatınIExtensibleDataObject. 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 bölümünde 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. , MaxStringContentLengthve değerlerine MaxDepthdikkat edin ve MaxArrayLength 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 veriyi arabelleğe alan arabirimi uygulayan IXmlSerializable hiçbir tür kullanmayın. Bu tür türleri bilinen türler listesine eklemeyin.

  • Bir sözleşmede XmlElementuygulanan ISerializable , XmlNode dizileri, Byte dizileri veya türleri kullanmayın.

  • Bilinen türler listesinde uygulanan ISerializable , XmlNode dizileriByte, dizileri veya türleri kullanmayınXmlElement.

Önceki önlemler, akışsız işlem tarafından DataContractSerializerkullanıldığında uygulanır. kullanıyorsanız XmlSerializer, akış ve akış dışı programlama modellerini hiçbir zaman aynı hizmette karıştırmayın çünkü kotanın MaxItemsInObjectGraph korunmasına sahip değildir.

Yavaş Akış Saldırıları

Hizmet reddi saldırıları akışı sınıfı bellek tüketimini içermez. 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 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 bkz . Aktarım Kotaları. İkinci olarak, WCF'de akışlarla çalışırken hiçbir zaman uyumlu Read veya Write işlem kullanmayın.

XML Kasa kullanma

Not

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. , veya XmlDictionaryReaderCreateMtomReader sınıfında statik fabrika yöntemi aşırı yüklemelerinden birini çağırarak güvenli okuyucuları CreateTextReaderCreateBinaryReaderoluşturun. Okuyucu oluştururken güvenli kota değerlerini geçirin. Yöntem aşırı yüklemelerini çağırmayın Create . 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 özelliği kullanılarak ReaderQuotas ya da okuyucu oluşturulurken geçirilen bir XmlDictionaryReaderQuotas nesne kullanılarak yapılandırılır.

MaxBytesPerRead

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 arabelleğe alınır. Bu nedenle, akış beklendiğinde aşırı arabelleğe almayı önlemek için akış modunda bu kotayı doğru ayarlamak önemlidir. MaxDepth Gerçekleşen gerçek arabellek miktarı hakkında bilgi için 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.

MaxDepth

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 üç iç içe yerleştirme derinliğine 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 bir nesne grafiğinin seri durumdan çıkarılması sırasında seri durumdan çıkarıcı yığının tamamına erişmek ve kurtarılamaz StackOverflowExceptionbir oluşturmak zorunda kalır. HEM hem de için XML iç içe yerleştirme ve nesne iç içe yerleştirme arasında doğrudan bir bağıntı DataContractSerializerXmlSerializervardır. Bu tehdidi azaltmak için kullanın MaxDepth .

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.

MaxStringContentLength

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, ile MaxStringContentLengthgüvenliği sağlanan bir okuyucu kullandığındaDataContractSerializer, bu kotadan daha büyük dizeleri seri durumdan çıkarmaz. Sınıfı doğrudan kullanırken XmlDictionaryReader , tüm yöntemler bu kotaya değil, yalnızca yöntem gibi dizeleri okumak için özel olarak tasarlanmış yöntemlere ReadContentAsString saygı gösterir. 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, ile MaxArrayLengthgüvenli bir okuyucu kullandığındaDataContractSerializer, bu kotadan daha büyük bayt dizilerinin seri durumdan çıkarılmaz. 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. Bu dize listesi, okuyucu oluşturulduğunda ve değiştirilemediğinde düzeltilir. 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, sözlüğün BinaryMessageEncodingBindingElement boyutunu sınırlayan üzerinde ayrı MaxSessionSize bir özellik vardır.

Diğer kotaların çoğundan farklı olarak, bu kota iletileri yazarken de geçerlidir. İleti okunurken aşılırsa, QuotaExceededException her zamanki gibi oluşturulur. İleti yazılırken aşılırsa, kotanın aşılmasıyla sonuçlanan tüm dizeler dinamik sözlükler özelliği kullanılmadan olduğu gibi 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ımdaki tehditleri azaltmak için gerekli değildir çünkü bellek kullanımı zaten ile MaxReceivedMessageSizesınırlıdır. Ancak, MaxReceivedMessageSize genişletme öncesi baytları sayar. İkili kodlama kullanımda olduğunda, bellek tüketimi yalnızca bir faktörüyle MaxSessionSizesınırlı olarak değerinin ötesine MaxReceivedMessageSizegeçebilir. Bu nedenle, ikili kodlama kullanılırken her zaman tüm okuyucu kotalarını (özellikle MaxStringContentLength) ayarlamak önemlidir.

ile DataContractSerializerIExtensibleDataObject birlikte ikili kodlama kullanılırken, bir sözlük genişletme saldırısı bağlamak için arabirim 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. Ile çarpılması MaxReceivedMessageSize sorun oluşturmayacak kadar MaxSessionSize düşük kota ayarlanamıyorsa, ikili kodlamayı kullanırken özelliği devre dışı bırakınIExtensibleDataObject. özniteliğinde IgnoreExtensionDataObjectServiceBehaviorAttribute özelliğini olarak true ayarlayın. Alternatif olarak, arabirimi uygulamayın IExtensibleDataObject . Daha fazla bilgi için bkz . İletme Uyumlu Veri Sözleşmeleri.

Kota Özeti

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

Koşul Ayarlanacağı önemli kotalar
Küçük iletilerin, metnin veya MTOM kodlamanın akışı veya akışı yok MaxReceivedMessageSize, MaxBytesPerReadve MaxDepth
Küçük iletileri akış veya akışla aktarma 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

  • Aktarım düzeyi zaman aşımları büyük veya küçük iletilerin akışını yaparken her zaman ayarlanmalıdır ve akış kullanımdayken hiçbir zaman zaman uyumlu okuma/yazma kullanmamalı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:

  • Seri durumdan çıkarıcı 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

(üzerinde XmlSerializergüvenlik bilgileri için ilgili belgelere bakın.) için XmlSerializer güvenlik modeli, ile benzerdir DataContractSerializerve çoğunlukla ayrıntılı olarak farklılık gösterir. Örneğin, XmlIncludeAttribute özniteliği özniteliği yerine KnownTypeAttribute tür ekleme için 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 büyük bir bellek ayak izine sahip olabilir veya kurtarılamayan özel durumlar 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 nedenlerden dolayı, seri durumdan çıkarıcının yükleyebileceği tür kümesini denetlemek önemlidir.

Seri DataContractSerializer durumdan çıkar, gevşek bir şekilde bağlı. Gelen verilerden ortak dil çalışma zamanı (CLR) türünü ve derleme adlarını hiçbir zaman okumaz. Bu, davranışına XmlSerializerbenzer, ancak , BinaryFormatterve SoapFormatterdavranışlarından NetDataContractSerializerfarklı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 DataContractSerializer zaman sözleşmeye göre beklenen bir türü yüklemesine izin verilir. Örneğin, bir veri sözleşmesinin türünde CustomerDataContractSerializer bir veri üyesi varsa, bu veri üyesini seri durumdan Customer çıkardığında türünün yüklenmesine 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 seri durumdan Customer çıkarıcıya şu mekanizmalardan biri aracılığıyla "bilindiği" 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, derleme sırasında açıkça öğesine geçirilen DataContractSerializer bilinen türlerin listesi.

Bu mekanizmaların her biri, seri durumdan çıkarıcının yükleyebileceği daha fazla tür sunarak yüzey alanını artırır. 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 dize veri üyesiyle seri durumdan çıkarırken bile, kötü amaçlı bir ileti yine de örneğinin MyDangerousType oluşturulmasına neden olabilir. içindeki MyDangerousTypekod(özellik ayarlayıcıları gibi) çalıştırılabilir. Bu yapıldıktan sonra seri durumdan çıkarıcı bu örneği dize veri üyesine atamaya çalışır ve bir özel durumla 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.

Çok fazla bilinen türün başka bir sonucu vardır: , DataContractSerializer uygulama etki alanında serileştirme/seri durumdan çıkarma kodu önbelleği oluşturur ve her tür için seri hale getirmesi ve seri durumdan çıkarması gereken bir giriş 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ğiyle OnDeserializedAttribute işaretlenen geri çağırma özellikle yararlıdır çünkü seri durumdan çıkarma tamamlandıktan sonra çalışır ve genel durumu inceleme ve düzeltme şansı olur. Daha fazla bilgi için bkz . Sürüme Dayanıklı 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 yalnızca güvenilen verilerle kullanılmak üzere .NET Framework uzaktan iletişimiyle çalışacak şekilde tasarlanmıştır. Bu öznitelikle işaretlenen mevcut türler durum güvenliği göz önünde bulundurularak tasarlanmamış olabilir.

  • Durum güvenliği söz IsRequired konusu olduğunda verilerin varlığını garanti etmek için özniteliğinin özelliğine DataMemberAttribute güvenmeyin. Veriler her zaman , zeroveya invalidolabilirnull.

  • Güvenilmeyen bir veri kaynağından seri durumdan çıkarılmış bir nesne grafiğine, önce doğrulamadan asla güvenmeyin. Tek tek her nesne tutarlı bir durumda olabilir, ancak bir bütün olarak nesne grafı 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, ve ile BinaryFormatterSoapFormatterbenzerdir. 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 öncelikle .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 özelliği olarak ayarlanmışsa AssemblyFormatSimple, gelen veriler yüklenecek türü yetersiz 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 ekler, bilgilerin açığa çıkmasına, sonuçta elde edilen nesne grafiğiyle veya serileştirilmiş verilerle oynanmasına veya sonuçta elde edilen 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. kullanırken NetDataContractSerializer, kotayı MaxItemsInObjectGraph 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'a Özgü Tehditler

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

, XmlSerializer çalışma zamanında seri hale getiren ve seri durumdan çıkaran kod içeren 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 , önceden oluşturulmuş serileştirme derlemelerini çalışma zamanında oluşturmak yerine kullandığı bir moda sahiptir. Uygun bir serileştirme derlemesi XmlSerializer bulabilen her durumda bu mod tetiklenir. serileştirme XmlSerializer derlemesinin serileştirilmiş türleri içeren derlemeyi imzalamak için kullanılan anahtar tarafından imzalanıp imzalanmadığını denetler. 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.

bir XmlSerializer hizmet reddi saldırısına tabi olabilir. kotası XmlSerializer yok MaxItemsInObjectGraph (üzerinde DataContractSerializerolduğu gibi). 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ştirilmiş türler veya başka yollarla serileştirme işlemi üzerinde denetimi olduğu durumlarda, kısmen güvenilen kod serileştirilmiş akışta seri hale getirilmiş akışta seri hale getiricinin büyük miktarda veri çıkarmasına neden olabilir ve bu da hizmet reddinin (DoS) bu akışın alıcısına neden olabilir. 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 ekler, bilgilerin açığa çıkmasına, sonuçta elde edilen nesne grafiğiyle veya serileştirilmiş verilerle oynanmasına veya sonuçta elde edilen 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 Öznitelik bir türe (veya olarak SerializableAttribute işaretlenmiş ancak ISerializabledeğil) uygulanırsa, seri durumdan çıkarıcı tüm oluşturucular genel olmayan veya taleplerle korunsa bile böyle bir türün ö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ısmen güvenilen koda yedek eklenmiş bir DataContractSerializer örneği geçirirseniz, kod bu vekildeki değiştirilebilir ayarları 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üvenilen koda teslim ederseniz, kısmen güvenilen kod nesnesini seri hale getirerek içindeki ExtensionDataObject verileri okuyabilir. Ayrıcalıklı bir veri kaynağından daha sonra kısmen güvenilen koda true geçirilen bir nesneye seri durumdan çıkarırken olarak ayarlamayı IgnoreExtensionDataObject göz önünde bulundurun.

  • DataContractSerializer ve DataContractJsonSerializer tam güven içinde özel, korumalı, iç ve genel üyelerin seri hale getirilmesini destekler. Ancak kısmi güvende yalnızca genel üyeler seri hale getirilebilir. Bir SecurityException uygulama, ortak olmayan bir üyeyi seri hale getirme girişiminde bulunursa oluşturulur.

    İç 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 seri hale getirmek isteyen bir derleme, iç üyelerinin System.Runtime.Serialization.dll görünür olduğunu bildirir.

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

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

    İlk dezavantaj, özniteliğin kabul etme özelliğinin InternalsVisibleToAttribute bütünleştirilmiş kod genelinde olmasıdır. Başka bir ifadeyle, yalnızca belirli bir sınıfın iç üyelerinin seri hale getirilebileceğini belirtemezsiniz. Tabii ki, yalnızca bu üyeye öznitelik eklemeyerek belirli bir iç üyeyi seri hale getirmemeyi DataMemberAttribute seçebilirsiniz. Benzer şekilde, bir geliştirici de küçük görünürlük endişeleriyle bir üyeyi özel veya korumalı yerine şirket içinde 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 PermissionsHelper.InternetZone güven için öğesine PermissionSet karşılık gelir. 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. İletinin göndereni akışın ortasında gönderme işlemini durdurarak daha fazla içerik beklenirse kodunuzu tahmin edilemeyen bir durumda bırakabilir. 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 olarak olarak ayarlayarak veya özelliği seçmeli olarak devre dışı bırakarak bu durumdan IExtensibleObjectData 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, örneğin bir web hizmetinde servicemodel meta veri yardımcı programı aracı (Svcutil.exe) kullanılarak istemci sınıfı oluşturulurken gerçekleşir. Ancak, daha gelişmiş senaryolarda çalışma zamanında şemayı 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ı veya WebHttpBehavioruyguladığındaWebScriptEnablingBehavior, WCF hem XML hem de JSON iletilerini kabul edebilen bir uç nokta 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, sınıfın XmlDictionaryReader diğer okuyucuların aksine sağladığı okuyucuları kullanın. Kasa okuyucular , CreateBinaryReaderveya CreateMtomReader yöntemleri kullanılarak CreateTextReaderoluş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.

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

  • İleti oluştururken yeterli koruma sunmuyorsa MaxReceivedMessageSize parametresini ayarlayınmaxSizeOfHeaders.

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

  • XPath ileti filtresi kullanırken, filtre ziyaretlerinin XML düğümlerinin miktarını sınırlamak için öğesini ayarlayın NodeQuota . Ç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 bkz.