ASP.NET Core Blazor etkileşimli sunucu tarafı işleme için tehdit azaltma kılavuzu

Bu makalede, etkileşimli sunucu tarafında Blazorgüvenlik tehditlerini azaltma açıklanmaktadır.

Uygulamalar, sunucu ve istemcinin uzun süreli bir ilişki sürdürdüğü durum koruyan bir veri işleme modelini benimser. Kalıcı durum, aynı zamanda uzun ömürlü olabilecek bağlantıları kapsayan bir bağlantı hattı tarafından korunur.

Kullanıcı bir siteyi ziyaret ettiğinde, sunucu sunucunun belleğinde bir bağlantı hattı oluşturur. Devre, kullanıcının kullanıcı arabiriminde bir düğme seçmesi gibi olaylara hangi içeriğin işlenip yanıt vereceğini tarayıcıya gösterir. Bu eylemleri gerçekleştirmek için bir bağlantı hattı kullanıcının tarayıcısında JavaScript işlevlerini ve sunucudaki .NET yöntemlerini çağırır. Bu iki yönlü JavaScript tabanlı etkileşim, JSbirlikte çalışma) olarak adlandırılır.

JS Birlikte çalışma İnternet üzerinden gerçekleştiğinden ve istemci uzak bir tarayıcı kullandığından, uygulamalar web uygulaması güvenlik sorunlarının çoğunu paylaşır. Bu konu, sunucu tarafı Blazor uygulamalara yönelik yaygın tehditleri açıklar ve İnternet'e yönelik uygulamalara odaklanan tehdit azaltma yönergeleri sağlar.

Şirket ağlarının veya intranetlerin içindekiler gibi kısıtlanmış ortamlarda, risk azaltma yönergelerinden bazıları şunlardan bazılarıdır:

• Kısıtlanmış ortamda geçerli değildir.
• Kısıtlanmış bir ortamda güvenlik riski düşük olduğundan, uygulanması gereken maliyete değmez.

WebSocket sıkıştırma etkinleştirilmiş Etkileşimli Sunucu Bileşenleri

Sıkıştırma, CRIME ve BREACH gibi saldırılar dahil, uygulamayı bağlantının TLS şifrelemesine karşı yan kanal saldırılarına maruz bırakabilir. Bu tür saldırılar, siber saldırganın şunları yapmasını gerektirir:

• Bir tarayıcıyı, saldırganın kontrol ettiği bir yükle istek göndermeye zorlamak için, çapraz site form gönderimi yoluyla veya siteyi başka bir sitenin iframe'ine gömerek savunmasız bir siteye yönlendirebilirsiniz.
• Ağ üzerinden sıkıştırılmış ve şifrelenmiş yanıtın uzunluğunu gözlemleyin.

Uygulamanın güvenlik açığına açık olması için yanıttaki siber saldırıcının yükünü yansıtması gerekir; örneğin, yanıta yolu veya sorgu dizesini yazarak. Siber saldırı, yanıtın uzunluğunu kullanarak, bağlantının şifrelenmesini atlayarak yanıtla ilgili tüm bilgileri "tahmin edebilir".

Genel olarak bakıldığında, Blazor uygulamalar uygun güvenlik önlemleriyle WebSocket bağlantısı üzerinden sıkıştırmayı etkinleştirebilir:

• Uygulama, siber saldırgan tarafından manipüle edilebilen içeriği istekten aldığında (örneğin, yol veya sorgu dizesi) ve bunu sayfanın HTML'sine yerleştirir veya yanıtın başka bir parçası haline getirirse savunmasız olabilir.

• Blazor aşağıdaki güvenlik önlemlerini otomatik olarak uygular:

  • Sıkıştırma yapılandırıldığında, Blazor uygulamanın bir iframe'e eklenmesini otomatik olarak engeller; bu da sunucudan gelen ilk (sıkıştırılmamış) yanıtın işlenmesini engeller ve WebSocket bağlantısının başlatılmasını engeller.

  • Uygulamayı bir iframe'e ekleme kısıtlaması gevşetilebilir. Ancak kısıtlamanın gevşetilmesi, gömülü belgenin siteler arası betik güvenlik açığı yoluyla tehlikeye atılması durumunda uygulamayı saldırılara maruz bırakır, bu da siber saldırıyı yürütmek için bir yol sağlar.

• Normalde bu tür bir saldırının gerçekleşmesi için, siber saldırının yanıtı tahmin edebilmesi için uygulamanın yanıtlardaki içeriği tekrar tekrar yeniden üretmesi gerekir. Verilen Blazor nasıl işlendiği (önce bir kez işlenir ve daha sonra sadece değişen öğeler için içeriğin farklarını üretir) göz önüne alındığında, bir siber saldırganın bunu başarması zordur. Ancak, bir siber saldırıcı için imkansız değildir, bu nedenle bir siber saldırıcı tarafından yönlendirilebilen dış bilgilerin yanı sıra hassas bilgilerin işlenmesini önlemek için dikkatli olunmalıdır. Bunun bazı örnekleri şunlardır:

  • Başka bir kullanıcı tarafından eklenen veritabanı verileriyle birlikte Kişisel Tanımlanabilir Bilgileri (PII) sayfada aynı anda görüntüleyin.

  • Başka bir kullanıcıdan JS interop veya sunucudaki yerel bir tekil hizmet aracılığıyla gelen veriyle aynı anda sayfaya PII bilgilerini render etme.

Genel olarak, güvenilmeyen kaynaklardan verileri aynı işleme toplu işleminin parçası olarak işleyebilen bileşenlerle birlikte hassas bilgiler içeren bileşenleri işlemekten kaçınmanızı öneririz. Güvenilmeyen kaynaklar arasında yol parametreleri, sorgu dizeleri, birlikte çalışma verileri JS ve üçüncü taraf bir kullanıcının denetleyebileceği diğer veri kaynakları (veritabanları, dış hizmetler) bulunur.

Paylaşılan durum

Sunucu tarafı Blazor uygulamalar sunucu belleğinde yer alır ve aynı işlem içinde birden çok uygulama oturumu barındırılır. Her uygulama oturumu için, Blazor kendi bağımlılık ekleme kapsayıcı kapsamıyla bir devre başlatır, bu nedenle kapsam dahilindeki hizmetler her bir Blazor oturumu için benzersizdir.

Uyarı

Aynı sunucuda durum paylaşan uygulamaların, çok dikkatli olunmadıkça, tekli hizmetleri kullanmasını önermeyiz; çünkü bu, devreler arasında kullanıcı durumunun sızması gibi güvenlik açıklarına yol açabilir.

Özellikle bu amaç için tasarlanmış durumda olan tekil hizmetleri Blazor uygulamalarda kullanabilirsiniz. Örneğin, bir bellek önbelleği belirli bir girdiye erişmek için bir anahtar gerektirdiğinden tekil bellek önbelleği kullanımı kabul edilebilir. Kullanıcıların önbellekle birlikte kullanılan önbellek anahtarları üzerinde denetimi olmadığı varsayıldığında, önbellekte depolanan durum devreler arasında sızmaz.

Durum yönetimi hakkında genel yönergeler için bkz. ASP.NET Çekirdek Blazor durum yönetimine genel bakış.

IHttpContextAccessor/HttpContext

Daha fazla bilgi için bkz. IHttpContextAccessor/HttpContext ASP.NET Core Blazor uygulamalarında.

Kaynak tükenmesi

Bir istemci sunucuyla etkileşime geçtiğinde ve sunucunun aşırı kaynak tüketmesine neden olduğunda kaynak tükenmesi oluşabilir. Aşırı kaynak tüketimi öncelikli olarak şu etkiler:

• CPU
• Bellek
• İstemci bağlantıları

Hizmet Reddi (DoS) saldırıları genellikle bir uygulamanın veya sunucunun kaynaklarını tüketmeye çalışır. Ancak, kaynak tükenmesi sisteme yapılan bir saldırının sonucu olmayabilir. Örneğin, sonlu kaynaklar yüksek kullanıcı talebi nedeniyle tükenebilir. DoS, DoS bölümünde daha ayrıntılı olarak ele alınmıştır.

Veritabanları ve dosya tanıtıcıları (dosyaları okumak ve yazmak için kullanılır) gibi çerçeve dışındaki Blazor kaynaklar da kaynak tükenmesi yaşayabilir. Daha fazla bilgi için bkz . ASP.NET Temel En İyi Yöntemler.

CPU (Merkezi İşlem Birimi)

Bir veya daha fazla istemci sunucuyu yoğun CPU çalışması yapmaya zorladığında CPU tükenmesi oluşabilir.

Örneğin, Bir Fibonnacci numarası hesaplayan bir uygulama düşünün. Fibonnacci sayısı, bir Fibonnacci dizisinden üretilir ve burada dizideki her sayı önceki iki sayının toplamıdır. Yanıta ulaşmak için gereken çalışma miktarı, dizinin uzunluğuna ve ilk değerin boyutuna bağlıdır. Uygulama bir istemcinin isteğine sınır uygulamazsa YOĞUN CPU kullanan hesaplamalar CPU'nun süresine hakim olabilir ve diğer görevlerin performansını azaltabilir. Aşırı kaynak tüketimi, kullanılabilirliği etkileyen bir güvenlik sorunudur.

CPU tükenmesi, genel kullanıma yönelik tüm uygulamalar için bir sorundur. Normal web uygulamalarında istekler ve bağlantılar bir güvenlik tedbiri olarak zaman aşımına uğrar, ancak Blazor uygulamalar aynı güvenlik tedbirlerini sunmaz. Blazor uygulamalar, cpu yoğunluklu çalışma gerçekleştirmeden önce uygun denetimleri ve sınırları içermelidir.

Bellek

Bir veya daha fazla istemci sunucuyu büyük miktarda bellek tüketmeye zorladığında bellek tükenmesi oluşabilir.

Örneğin, öğe listesini kabul eden ve görüntüleyen bir bileşene sahip bir uygulamayı düşünün. Blazor Uygulama izin verilen öğe sayısına veya istemciye geri işlenen öğe sayısına sınır getirmezse yoğun bellek kullanan işleme ve işleme, sunucunun performansının az olduğu noktaya kadar sunucunun belleğine hakim olabilir. Sunucu kilitlenebilir veya kilitlenmiş gibi görünecek kadar çok yavaşlayabilir.

Sunucudaki olası bir bellek tükenme senaryosuyla ilgili öğelerin listesini korumak ve görüntülemek için aşağıdaki senaryoyu göz önünde bulundurun:

• Bir List<T> özellik veya alandaki öğeler sunucunun belleğini kullanır. Uygulama öğelerin listesinin sınırsız büyümesine izin veriyorsa sunucunun belleğinin tükenmesi riski vardır. Belleğin yetersiz olması, geçerli oturumun sona ermesini (kilitlenmesini) ve bu sunucu örneğindeki tüm eşzamanlı oturumların bellek yetersiz özel durumu almasına neden olur. Bu senaryonun oluşmasını önlemek için uygulamanın eşzamanlı kullanıcılara öğe sınırı uygulayan bir veri yapısı kullanması gerekir.
• Görüntüleme için bir disk belleği düzeni kullanılmıyorsa, sunucu arayüzde görünmeyen nesneler için ek bellek kullanır. Öğe sayısı sınırı olmadan, bellek talepleri kullanılabilir sunucu belleğini tüketebilir. Bu senaryoyu önlemek için aşağıdaki yaklaşımlardan birini kullanın:
  • İşleme sırasında sayfalandırılmış listeler kullanın.
  • Yalnızca ilk 100 ile 1.000 arasında öğeyi görüntüler ve kullanıcının görüntülenen öğelerin ötesindeki öğeleri bulmak için arama ölçütleri girmesini gerektirir.
  • Daha gelişmiş bir işleme senaryosu için, sanallaştırmayı destekleyen listeleri veya kılavuzları uygulayın. Sanallaştırmayı kullanarak listeler, şu anda kullanıcı tarafından görülebilen öğelerin yalnızca bir alt kümesini işler. Kullanıcı kullanıcı arabirimindeki kaydırma çubuğuyla etkileşime geçtiğinde, bileşen yalnızca görüntüleme için gereken öğeleri işler. Şu anda görüntüleme için gerekli olmayan öğeler, ideal yaklaşım olan ikincil depolamada tutulabilir. Gösterilmeyen öğeler de bellekte tutulabilir ve bu, daha az ideal bir durumdur.

Not

Blazor sanallaştırma için yerleşik desteğe sahiptir. Daha fazla bilgi için bkz . ASP.NET Temel Razor bileşen sanallaştırma.

Blazor uygulamalar WPF, Windows Forms veya Blazor WebAssemblygibi durum bilgisi olan uygulamalar için diğer kullanıcı arabirimi çerçevelerine benzer bir programlama modeli sunar. Temel fark, kullanıcı arabirimi çerçevelerinin birkaçında uygulama tarafından kullanılan belleğin istemciye ait olması ve yalnızca bu istemciyi etkilemesidir. Örneğin, bir Blazor WebAssembly uygulama tamamen istemci üzerinde çalışır ve yalnızca istemci bellek kaynaklarını kullanır. Sunucu tarafı Blazor bir uygulama için, uygulama tarafından kullanılan bellek sunucuya aittir ve sunucu örneğindeki istemciler arasında paylaşılır.

Sunucu tarafı bellek talepleri, tüm sunucu tarafı Blazor uygulamaları için dikkate alınmalıdır. Ancak çoğu web uygulaması durum bilgisi yoktur ve bir istek işlenirken kullanılan bellek yanıt döndürülürken serbest bırakılır. Genel bir öneri olarak, istemci bağlantılarını kalıcı hale getiren diğer sunucu tarafı uygulamalarındaki gibi istemcilerin ilişkisiz miktarda bellek ayırmasına izin verme. Sunucu tarafı Blazor uygulaması tarafından tüketilen bellek, tek bir istekten daha uzun süre kalıcı olur.

Not

Geliştirme sırasında, istemcilerin bellek taleplerini değerlendirmek için bir profil aracı kullanılabilir veya bir iz yakalanabilir. Profil oluşturucu veya izleme, belirli bir istemciye ayrılan belleği yakalamaz. Geliştirme sırasında belirli bir istemcinin bellek kullanımını yakalamak için bir döküm yakalayın ve kullanıcının bağlantı hattında köklenen tüm nesnelerin bellek talebini inceleyin.

İstemci bağlantıları

Bir veya daha fazla istemci sunucuya çok fazla eşzamanlı bağlantı açtığında bağlantı tükenmesi oluşabilir ve bu da diğer istemcilerin yeni bağlantılar kurmasını engeller.

Blazor istemcileri oturum başına tek bir bağlantı kurar ve tarayıcı penceresi açık olduğu sürece bağlantıyı açık tutar. Bağlantıların kalıcı yapısı ve sunucu tarafı Blazor uygulamaların durum bilgisi göz önünde bulundurulduğunda, bağlantı tükenmesi uygulamanın kullanılabilirliği için daha büyük bir risktir.

Bir uygulama için kullanıcı başına bağlantı sayısı sınırı yoktur. Uygulama bir bağlantı sınırı gerektiriyorsa aşağıdaki yaklaşımlardan birini veya birkaçını uygulayın:

• Yetkisiz kullanıcıların uygulamaya bağlanma becerisini doğal olarak sınırlayan kimlik doğrulaması iste. Bu senaryonın etkili olması için kullanıcıların isteğe bağlı olarak yeni kullanıcılar sağlaması engellenmelidir.
• Kullanıcı başına bağlantı sayısını sınırlayın. Bağlantıları sınırlamak aşağıdaki yaklaşımlarla gerçekleştirilebilir. Yasal kullanıcıların uygulamaya erişmesine izin vermek için dikkatli olun (örneğin, istemcinin IP adresine göre bir bağlantı sınırı oluşturulduğunda).
  • Uygulama düzeyi
    • Uç nokta yönlendirme genişletilebilirliği.
    • Uygulamaya bağlanmak ve kullanıcı başına etkin oturumları izlemek için kimlik doğrulaması gerektir.
    • Sınıra ulaştıktan sonra yeni oturumları reddedin.
    • Proxy WebSocket, istemcilerden uygulamaya bağlantıları çoğullayan Azure SignalR Hizmeti gibi bir ara sunucu kullanarak bir uygulamaya bağlantı kurar. Bu, bir istemcinin kurabileceğinden daha fazla bağlantı kapasitesine sahip bir uygulamaya olanak tanır ve istemcinin sunucuya olan bağlantıları tüketmesini önler.
  • Sunucu düzeyi: Uygulamanın önünde ara sunucu/ağ geçidi kullanın.
    • Azure Application Gateway, web uygulamalarınıza gelen trafiği yönetmenizi sağlayan bir web trafiği (OSI katman 7) yük dengeleyicidir. Daha fazla bilgi için bkz . Application Gateway'de WebSocket desteğine genel bakış.
    • Azure Front Door, iş yüklerinizi birden çok bilgi işlem kaynağına dağıtmaya yönelik bir yük dengeleme hizmetidir.

Hizmet Reddi (DoS) saldırıları

Hizmet Reddi (DoS) saldırıları , sunucunun bir veya daha fazla kaynağını tüketmesine neden olan bir istemciyi içerir ve bu da uygulamayı kullanılamaz hale getirir. Blazoruygulamalar varsayılan sınırları içerir ve DoS saldırılarına karşı koruma sağlamak için ayarlanan SignalR diğer ASP.NET Core ve CircuitOptions sınırları kullanır:

• CircuitOptions.DisconnectedCircuitMaxRetained
• CircuitOptions.DisconnectedCircuitRetentionPeriod
• CircuitOptions.JSInteropDefaultCallTimeout
• CircuitOptions.MaxBufferedUnacknowledgedRenderBatches
• HubConnectionContextOptions.MaximumReceiveMessageSize

Daha fazla bilgi ve yapılandırma kodlama örnekleri için aşağıdaki makalelere bakın:

• ASP.NET Temel BlazorSignalR kılavuzu
• ASP.NET Core SignalR yapılandırma

Tarayıcıyla etkileşimler (istemci)

İstemci, birlikte çalışma etkinliği dağıtımı ve işleme sürecinin tamamlanması yoluyla JS sunucuyla etkileşim kurar. JS birlikte çalışma iletişimi JavaScript ile .NET arasında her iki yoldan da geçer:

• Tarayıcı olayları istemciden sunucuya zaman uyumsuz bir şekilde gönderilir.
• Sunucu, kullanıcı arayüzünü gerektiğinde eşzamansız olarak yeniden oluşturarak yanıt verir.

.NET'ten çağrılan JavaScript işlevleri

.NET yöntemlerinden JavaScript'e yapılan çağrılar için:

• Tüm çağrılar, belirli bir süre yapılandırılabilir bir zaman aşımına sahiptir ve bu süreden sonra başarısız olur, çağırana bir OperationCanceledException döndürülür.
  • Aramalar (CircuitOptions.JSInteropDefaultCallTimeout) için bir dakikalık varsayılan bir zaman aşımı vardır. Bu sınırı yapılandırmak için bkz . ASP.NET Core'da Blazor.NET yöntemlerinden JavaScript işlevlerini çağırma.
  • İptali çağrı bazında kontrol etmek için bir iptal belirteci sağlanabilir. Mümkün olduğunda varsayılan çağrı zaman aşımını kullanın ve eğer bir iptal belirteci sağlanmışsa istemciye yapılan herhangi bir çağrı için bir zaman sınırı belirleyin.
• JavaScript çağrısının sonucuna güvenilemiyor. Tarayıcıda Blazor çalışan uygulama istemcisi çağrılacak JavaScript işlevini arar. İşlev çağrılır ve sonuç veya hata oluşturulur. Kötü amaçlı bir istemci şu girişimde bulunabilir:
  • JavaScript işlevinden bir hata döndürerek uygulamada bir soruna neden olun.
  • JavaScript işlevinden beklenmeyen bir sonuç döndürerek sunucuda istenmeyen bir davranışa neden olun.

Önceki senaryolara karşı korumak için aşağıdaki önlemleri alın:

• Hataları hesaplamak için JS birlikte çalışma çağrılarını try-catch deyimleri içinde sarın. Daha fazla bilgi için bkz . ASP.NET Core Blazor uygulamalarında hataları işleme.
• Herhangi bir işlem yapmadan önce hata iletileri de dahil olmak üzere birlikte çalışma çağrılarından JS döndürülen verileri doğrulayın.

Tarayıcıdan çağrılan .NET yöntemleri

JavaScript'ten .NET yöntemlerine yapılan çağrılara güvenmeyin. Bir .NET yöntemi JavaScript'e sunulduğunda,.NET yönteminin nasıl çağrıldığı göz önünde bulundurun:

• JavaScript'e sunulan herhangi bir .NET yöntemini, uygulamanın genel uç noktası gibi değerlendirin.
  • Girişi doğrulayın.
    • Değerlerin beklenen aralıklar içinde olduğundan emin olun.
    • Kullanıcının istenen eylemi gerçekleştirme iznine sahip olduğundan emin olun.
  • .NET yöntemi çağrısının bir parçası olarak aşırı miktarda kaynak ayırmayın. Örneğin, CPU ve bellek kullanımına yönelik denetimler gerçekleştirin ve sınırlar yerleştirin.
  • Statik ve örnek yöntemlerinin JavaScript istemcilerine gösterilebileceğini dikkate alın. Tasarım uygun kısıtlamalarla paylaşım durumunu çağırmadığı sürece oturumlar arasında durum paylaşımından kaçının.
    • Başlangıçta bağımlılık enjeksiyonu (DI) ile oluşturulan nesneler aracılığıyla DotNetObjectReference sunulan örnek yöntemler için, nesneler scope olarak ayarlanmış nesneler olarak kaydedilmelidir. Bu, uygulamanın kullandığı tüm DI hizmetleri için geçerlidir.
    • Statik yöntemler için, uygulama tasarımı gereği bir sunucu örneğindeki tüm kullanıcılar arasında durum paylaşımına açık olarak izin verilmediği sürece, istemcinin kapsamı dışına çıkacak bir durum oluşturmaktan kaçının.
  • Kullanıcı tarafından sağlanan verileri parametrelerde JavaScript çağrılarına geçirmekten kaçının. Verileri parametrelere geçirmek kesinlikle gerekliyse, JavaScript kodunun siteler arası betik çalıştırma (XSS) güvenlik açıklarına neden olmadan veri aktarımını doğru bir şekilde işlediğinden emin olun. Örneğin, bir öğenin özelliğini ayarlayarak innerHTML kullanıcı tarafından sağlanan verileri DOM'a yazmayın. İçerik Güvenlik İlkesi (CSP) kullanmayı ve diğer güvenli olmayan JavaScript temel öğelerini devre dışı bırakmayı düşünün. Daha fazla bilgi için bkz. ASP.NET Core Blazoriçin İçerik Güvenliği İlkesini Zorlama ve MDN'nin CSP kılavuzu.
• Çerçevenin kendi dağıtım uygulamasının üzerine .NET çağrılarının özel dağıtım yöntemlerini uygulamaktan kaçının. .NET yöntemlerinin tarayıcıya açıklanması gelişmiş bir senaryodur, genel Blazor geliştirme için önerilmez.

Ekinlikler

Olaylar bir uygulamaya giriş noktası sağlar. Web uygulamalarında uç noktaları korumaya yönelik kurallar, uygulamalarda olay işleme için de Blazor geçerlidir. Kötü amaçlı istemci, bir olayın yükü olarak göndermek istediği verileri gönderebilir.

Örneğin:

• için <select> değişiklik olayı, uygulamanın istemciye sunduğu seçenekler içinde olmayan bir değer gönderebilir.
• , <input> istemci tarafı doğrulamasını atlayarak sunucuya herhangi bir metin verisi gönderebilir.

Uygulamanın işlediği tüm olaylar için verileri doğrulaması gerekir. Çerçeve Blazorform bileşenleri temel doğrulamalar gerçekleştirir. Uygulama özel form bileşenleri kullanıyorsa, olay verilerini uygun şekilde doğrulamak için özel kod yazılmalıdır.

Olaylar eşzamansız olduğundan, uygulama yeni bir işleme oluşturarak tepki vermeden önce sunucuya birden çok olay gönderilebilir. Bunun dikkate alınması gereken bazı güvenlik etkileri vardır. Uygulamadaki istemci eylemlerinin sınırlanması, geçerli işlenmiş görünüm durumuna bağlı değil, olay işleyicileri içinde gerçekleştirilmelidir.

Bir kullanıcının sayacı en fazla üç kez artırmasına izin veren bir sayaç bileşeni düşünün. Sayacı artırma düğmesi, count'nın değerine bağlı olarak koşulludur.

<p>Count: @count</p>

@if (count < 3)
{
    <button @onclick="IncrementCount" value="Increment count" />
}

@code 
{
    private int count = 0;

    private void IncrementCount()
    {
        count++;
    }
}

İstemci, framework bu bileşeni yeniden oluşturmadan önce bir veya daha fazla artırım olayı gönderebilir. Sonuç olarak, count kullanıcı arabirimi düğmeyi yeterince hızlı kaldırmadığı için kullanıcı tarafından üçten fazla kez artırılabilir. Üç count artım sınırına ulaşmanın doğru yolu aşağıdaki örnekte gösterilmiştir:

<p>Count: @count</p>

@if (count < 3)
{
    <button @onclick="IncrementCount" value="Increment count" />
}

@code 
{
    private int count = 0;

    private void IncrementCount()
    {
        if (count < 3)
        {
            count++;
        }
    }
}

İşleyicinin içine if (count < 3) { ... } kontrolünü ekleyerek, count artırma kararı geçerli uygulama durumuna dayanır. Karar, önceki örnekte olduğu gibi kullanıcı arabiriminin durumuna bağlı değildir ve bu durum geçici olarak eski olabilir.

Birden çok gönderime karşı koruma

Bir olay geri çağırım işlevi, dış hizmetten veya veritabanından veri getirme gibi uzun süre çalışan bir işlemi eşzamansız olarak çalıştırırsa, bir koruma mekanizması kullanmayı göz önünde bulundurun. Koruma, kullanıcının görsel geri bildirimle işlem devam ederken birden çok işlemi sıralamasını engelleyebilir. Aşağıdaki bileşen kodu, sunucudan veri alırken isLoading'i true olarak ayarlarken DataService.GetDataAsync veriyi alır. isLoading durumunda true, düğme kullanıcı arabiriminde devre dışıdır.

<button disabled="@isLoading" @onclick="UpdateData">Update</button>

@code {
    private bool isLoading;
    private Data[] data = Array.Empty<Data>();

    private async Task UpdateData()
    {
        if (!isLoading)
        {
            isLoading = true;
            data = await DataService.GetDataAsync(DateTime.Now);
            isLoading = false;
        }
    }
}

Önceki örnekte gösterildiği gibi, güvenlik deseni, arka plan işlemi async-await deseniyle zaman uyumsuz olarak yürütüldüğünde çalışır.

Erken iptal etme ve atıldıktan sonra kullanımdan kaçınma

Birden çok gönderime karşı koruma bölümünde açıklandığı gibi bir güvenlik önlemi kullanmaya ek olarak, bileşen atıldığında uzun süren işlemleri iptal etmek için bir kullanmayı düşünebilirsiniz. Bu yaklaşım, bileşenlerde kullanımdan sonra atılmasından kaçınmanın ek avantajına sahiptir:

@implements IDisposable

...

@code {
    private readonly CancellationTokenSource TokenSource = 
        new CancellationTokenSource();

    private async Task UpdateData()
    {
        ...

        data = await DataService.GetDataAsync(DateTime.Now, TokenSource.Token);

        if (TokenSource.Token.IsCancellationRequested)
        {
           return;
        }

        ...
    }

    public void Dispose()
    {
        TokenSource.Cancel();
    }
}

Büyük miktarda veri üreten olaylardan kaçının

veya oninputgibi onscroll bazı DOM olayları büyük miktarda veri üretebilir. Bu olayları sunucu tarafı Blazor sunucuda kullanmaktan kaçının.

Ek güvenlik kılavuzu

ASP.NET Core uygulamalarının güvenliğini sağlamaya yönelik yönergeler sunucu tarafı Blazor uygulamalar için geçerlidir ve bu makalenin aşağıdaki bölümlerinde ele alınmıştır:

• Günlük ve hassas veriler
• HTTPS ile aktarımdaki bilgileri koruma
• Siteler arası komut dosyası çalıştırma (XSS)
• Farklı kaynaklar arası koruma
• Click-jacking
• Yeniden yönlendirmeleri açma

Kayıt işlemleri ve hassas veriler

JS istemci ve sunucu arasındaki birlikte çalışma etkileşimleri, sunucu günlüklerine ILogger örnekler olarak kaydedilir. Blazor gerçek olaylar veya JS birlikte çalışma girişleri ve çıkışları gibi hassas bilgilerin kaydedilmesini önler.

Sunucuda bir hata oluştuğunda, çerçeve istemciye bildirir ve oturumu siler. İstemci, tarayıcının geliştirici araçlarında görülebilen genel bir hata iletisi alır.

İstemci tarafı hatası çağrı yığınını içermez ve hatanın nedeni hakkında ayrıntılı bilgi sağlamaz, ancak sunucu günlükleri bu tür bilgileri içerir. Geliştirme amacıyla, hassas hata bilgileri istemcinin kullanımına ayrıntılı hatalar etkinleştirilerek sunulabilir.

Uyarı

Hata bilgilerinin İnternet'te istemcilere açıklanması, her zaman kaçınılması gereken bir güvenlik riskidir.

HTTPS ile aktarımdaki bilgileri koruma

Blazor , istemci ile sunucu arasındaki iletişim için kullanır SignalR . Blazor, genellikle WebSockets olan ve SignalR tarafından müzakere edilen aktarımı normalde kullanır.

Blazor sunucu ile istemci arasında gönderilen verilerin bütünlüğünü ve gizliliğini sağlamaz. Her zaman HTTPS kullanın.

Siteler arası komut dosyası çalıştırma (XSS)

Siteler arası betik (XSS), yetkisiz bir tarafın tarayıcı bağlamında rastgele mantık yürütmesine olanak tanır. Güvenliği aşılmış bir uygulama istemcide rastgele kod çalıştırabilir. Bu güvenlik açığı, sunucuya karşı bir dizi kötü amaçlı eylem gerçekleştirmek için kullanılabilir:

• Sahte/geçersiz olayları sunucuya dağıtın.
• Gönderim başarısız/geçersiz işleme tamamlamaları.
• Render tamamlamalarını göndermekten kaçının.
• JavaScript'ten .NET'e birlikte çalışma çağrıları gönderme.
• .NET'ten JavaScript'e birlikte çalışma çağrılarının yanıtını değiştirin.
• .NET'i JS birlikte çalışma sonuçlarına göndermekten kaçının.

Çerçeve, Blazor önceki tehditlerden bazılarına karşı koruma adımları uygular:

• İstemci işleme toplu işlemlerini onaylamıyorsa yeni kullanıcı arabirimi güncelleştirmeleri üretmeyi durdurur. CircuitOptions.MaxBufferedUnacknowledgedRenderBatches ile yapılandırıldı.
• İstemciden yanıt almazsa, bir dakika sonra herhangi bir .NET'ten JavaScript'e çağrı zaman aşımına uğrayacaktır. CircuitOptions.JSInteropDefaultCallTimeout ile yapılandırıldı.
• Tarayıcıdan gelen tüm girişlerde JS etkileşim sırasında temel doğrulama işlemi gerçekleştirir.
  • .NET referansları geçerli ve .NET yöntemi tarafından beklenen türde olan.
  • Veriler yanlış biçimlendirilmiş değil.
  • Yöntem için yükte doğru sayıda argüman bulunuyor.
  • Yöntemi çağırmadan önce bağımsız değişkenler veya sonuç düzgün bir şekilde seriden çıkarılabilir.
• Dağıtılan olaylardan tarayıcıdan gelen tüm girişlerde temel doğrulama gerçekleştirir:
  • Olayın geçerli bir türü var.
  • Etkinliğin verileri deserializasyon edilebilir.
  • Etkinlikle ilişkilendirilmiş bir olay işleyicisi vardır.

Çerçevenin uyguladığı önlemlere ek olarak, uygulamanın tehditlere karşı koruma sağlamak ve uygun eylemleri gerçekleştirmek için geliştirici tarafından kodlanması gerekir:

• Olayları işlerken her zaman verileri doğrulayın.
• Geçersiz verileri aldıktan sonra uygun eylemi gerçekleştirin:
  • Verileri yoksayın ve geri dönün. Bu, uygulamanın istekleri işlemeye devam etmesini sağlar.
  • Uygulama, girişin geçersiz olduğu ve meşru bir istemci tarafından oluşturulamayacağını belirlerse, bir özel durum fırlatın. Özel durum oluşturma devreyi yok eder ve oturumu sonlandırır.
• Günlüklere dahil edilen rendering işlem toplu tamamlamaları tarafından sağlanan hata iletisine güvenmeyin. Hata istemci tarafından sağlanır ve istemcinin güvenliği aşılmış olabileceğinden genel olarak güvenilir değildir.
• JavaScript ve .NET yöntemleri arasında hangi yönde olursa olsun birlikte çalışma çağrılarında giriş verilerine JS güvenmeyin.
• Uygulama, bağımsız değişkenler veya sonuçlar doğru seri durumdan çıkarılmış olsa bile bağımsız değişkenlerin ve sonuçların içeriğinin geçerli olduğunu doğrulamakla sorumludur.

XSS güvenlik açığının mevcut olması için uygulamanın işlenen sayfaya kullanıcı girişi eklemesi gerekir. Blazor derleme zamanı adımını yürütür; burada bir .razor dosyasındaki işaretleme, yordamsal C# mantığına dönüştürülür. C# mantığı çalışma zamanında öğeleri, metni ve alt bileşenleri açıklayan bir işleme ağacı oluşturur. Bu, tarayıcının DOM'sine bir dizi JavaScript yönergesi aracılığıyla uygulanır (veya ön kullanım durumunda HTML olarak serileştirilir):

• Normal Razor söz dizimi aracılığıyla işlenen kullanıcı girişi (örneğin, @someStringValue) XSS güvenlik açığını ortaya çıkarmaz çünkü Razor söz dizimi DOM'a yalnızca metin yazabilen komutlar aracılığıyla eklenir. Değer HTML işaretlemesi içerse bile, değer statik metin olarak görüntülenir. Ön kayıt sırasında çıkış HTML kodludur ve bu da içeriği statik metin olarak görüntüler.
• Bileşen yazarları, kullanmadan RazorC# dilinde bileşenler yazabilir. Bileşen yazarı, çıkış gönderirken doğru API'leri kullanmakla sorumludur. Örneğin, builder.AddContent(0, someUserSuppliedString) ve değilbuilder.AddMarkupContent(0, someUserSuppliedString) kullanın, çünkü ikincisi bir XSS güvenlik açığına neden olabilir.

XSS güvenlik açıklarını daha da azaltmayı göz önünde bulundurun. Örneğin, kısıtlayıcı bir İçerik Güvenliği İlkesi (CSP) uygulayın. Daha fazla bilgi için bkz. ASP.NET Core Blazoriçin İçerik Güvenliği İlkesini Zorlama ve MDN'nin CSP kılavuzu.

Daha fazla bilgi için bkz ASP.NET Core'da Siteler Arası Komut Dosyası (XSS) Engelleme.

Kaynaklar arası koruma

Çıkış noktaları arası saldırılar, farklı bir kaynaktan bir istemcinin sunucuya karşı bir eylem gerçekleştirmesini içerir. Kötü amaçlı eylem genellikle bir GET isteği veya POST formudur (Siteler Arası İstek Sahteciliği, CSRF), ancak kötü amaçlı bir WebSocket açmak da mümkündür. Blazoruygulamalar, hub protokolü kullanan diğer SignalR tüm uygulamaların sunduğu garantinin aynısını sunar:

• Ek önlemler alınmadığı takdirde uygulamalara çapraz-köken erişimi sağlanabilir. Farklı kaynaklar arası erişimi devre dışı bırakmak için, CORS Ara Yazılımını işlem hattına ekleyip uç nokta meta verilerine DisableCorsAttribute ekleyerek Blazor uç noktasında CORS'yi devre dışı bırakın veya Farklı Kaynaklar Arası Kaynak Paylaşımı ayarlarını yapılandırarak izin verilen kaynakların kümesini sınırlayın. WebSocket kaynak kısıtlamaları hakkında yönergeler için bkz. ASP.NET Core'da WebSockets desteği.
• CORS etkinse, CORS yapılandırmasına bağlı olarak uygulamayı korumak için ek adımlar gerekebilir. CORS genel olarak etkinleştirildiyse, uç nokta rota oluşturucu üzerinde BlazorSignalR çağrısı yapıldıktan sonra DisableCorsAttribute metasını uç nokta meta verilerine ekleyerek CORS, hub için devre dışı bırakılabilir.

Daha fazla bilgi için, bkz. ASP.NET Core'da Siteler Arası İstek Sahteciliği (XSRF/CSRF) saldırılarını önleme.

Tıklama dolandırıcılığı

Click-jacking, kullanıcıyı saldırı altında olan sitede eylemler gerçekleştirmesi için kandırmak amacıyla, farklı bir kökenden gelen bir siteyi kendi içeriği gibi göstermek için <iframe> öğesiyle işler.

Bir uygulamayı içinde <iframe> işlemeye karşı korumak için İçerik Güvenlik İlkesi (CSP) ve X-Frame-Options başlığını kullanın. CSP söz dizimi için bkz. MDN'nin CSP kılavuzu.

Daha fazla bilgi edinmek için aşağıdaki kaynaklara bakın:

• ASP.NET Core için İçerik Güvenlik İlkesi Zorlama Blazor
• MDN web belgeleri: X-Frame-Options

Açık yönlendirmeler

Bir uygulama oturumu başlatıldığında, sunucu oturumu başlatmanın bir parçası olarak gönderilen URL'lerin temel doğrulamasını gerçekleştirir. Çerçeve, bağlantı hattını oluşturmadan önce temel URL'nin geçerli URL'nin üst öğesi olup olmadığını denetler. Çerçeve tarafından ek denetim gerçekleştirilmez.

Kullanıcı istemcide bir bağlantı seçtiğinde, bağlantının URL'si sunucuya gönderilir ve bu da hangi eylemin gerçekleştirileceğini belirler. Örneğin, uygulama istemci tarafında gezinti gerçekleştirebilir veya tarayıcıya yeni konuma gideceğini belirtebilir.

Bileşenler, NavigationManager kullanarak programatik olarak gezinti isteklerini de tetikleyebilir. Bu tür senaryolarda uygulama bir istemci tarafı gezintisi gerçekleştirebilir veya tarayıcıya yeni konuma gideceğini belirtebilir.

Bileşenler şunları içermelidir:

• Navigasyon çağrısının bağımsız değişkenleri içinde kullanıcı girişini kullanmaktan kaçının.
• Hedefe uygulama tarafından izin verildiğinden emin olmak için bağımsız değişkenleri doğrulayın.

Aksi takdirde, kötü niyetli bir kullanıcı tarayıcıyı siber saldırı denetimindeki bir siteye gitmeye zorlayabilir. Bu senaryoda, siber saldırgan, yöntem çağrısı sırasında bazı kullanıcı girişlerini kullanarak uygulamayı kandırır NavigationManager.NavigateTo.

Bu öneri, bağlantıları uygulamanın bir parçası olarak işlenirken de geçerlidir:

• Mümkünse göreli bağlantıları kullanın.
• Mutlak bağlantı hedeflerinin bir sayfaya eklemeden önce geçerli olduğunu doğrulayın.

Daha fazla bilgi için bkz . ASP.NET Core'da açık yeniden yönlendirme saldırılarını önleme.

Güvenlik denetim listesi

Aşağıdaki güvenlik konuları listesi kapsamlı değildir:

• Etkinliklerden gelen parametreleri doğrulayın.
• Birlikte çalışma çağrılarından gelen JS giriş verilerini ve sonuçları doğrulayın.
• .NET JS ara yüz çağrıları için kullanıcı girişini kullanmaktan kaçının veya önceden doğrulayın.
• İstemcinin ilişkisiz miktarda bellek ayırmasını engelleyin.
  • Bileşen içindeki veriler.
  • DotNetObjectReference nesneler istemciye döndürülür.
• Birden çok gönderime karşı koruma.
• Bileşen kaldırıldığında uzun süre çalışan işlemleri iptal edin.
• Büyük miktarda veri üreten olaylardan kaçının.
• Kullanıcı girişini `NavigationManager.NavigateTo` çağrılarının bir parçası olarak kullanmaktan kaçının ve bu kaçınılmaz ise, önce izin verilen kaynaklardan oluşan bir küme ile URL'ler için kullanıcı girişini doğrulayın.
• Kullanıcı arabiriminin durumuna göre değil, yalnızca bileşen durumundan yetkilendirme kararları alın.
• XSS saldırılarına karşı koruma sağlamak için İçerik Güvenlik İlkesi'ni (CSP) kullanmayı göz önünde bulundurun. Daha fazla bilgi için bkz. ASP.NET Core Blazoriçin İçerik Güvenliği İlkesini Zorlama ve MDN'nin CSP kılavuzu.
• Tıklama kaçırmaya karşı koruma sağlamak için CSP ve X-Frame-Options'ı kullanmayı göz önünde bulundurun.
• CORS'yi etkinleştirirken CORS ayarlarının uygun olduğundan emin olun veya uygulamalar için Blazor CORS'yi açıkça devre dışı bırakın.
• Uygulama için sunucu tarafı sınırlarının kabul edilemez düzeyde risk olmadan kabul edilebilir bir kullanıcı deneyimi sağladığından emin olmak için Blazor test edin.