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 bilgisi olan 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, JavaScript birlikte çalışma (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.

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 kendi Blazor bağımlılık ekleme kapsayıcı kapsamına sahip bir bağlantı hattı başlatır, bu nedenle kapsamlı hizmetler oturum başına Blazor benzersizdir.

Özel olarak tasarlanmış olan uygulamalarda durum bilgisi olan tekil hizmetleri Blazor 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önetimi.

IHttpContextAccessor/HttpContextbileşenlerde Razor

[CascadingParameter]
public HttpContext? HttpContext { get; set; }

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

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 önlemi olarak zaman aşımına uğradı ancak Blazor uygulamalar aynı koruma önlemlerini sağlamaz. 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ündüğü noktaya yavaş gelebilir.

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.
• İşleme için bir disk belleği düzeni kullanılmıyorsa, sunucu kullanıcı arabiriminde 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. Dağıtılmamış öğeler de bellekte tutulabilir ve bu daha az idealdir.

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.

İ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:

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 CircuitOptions diğer ASP.NET Core ve SignalR 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 olayı gönderme ve işleme tamamlama 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ı arabirimini gerektiği gibi zaman uyumsuz olarak yeniden adlandırarak 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, yapılandırılabilir bir zaman aşımına sahiptir ve bu zaman aşımı başarısız olur ve çağırana bir OperationCanceledException döndürü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 her çağrı temelinde denetlemek için bir iptal belirteci sağlanabilir. Mümkün olduğunda varsayılan çağrı zaman aşımını kullanın ve iptal belirteci sağlanırsa istemciye yapılan herhangi bir çağrıya zaman bağlıdır.
• 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:

• Çağırmalar sırasında oluşabilecek hataları hesaba eklemek için deyimler içindeki try-catch birlikte çalışma çağrılarını sarmalarJS. 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 ekleme (DI) aracılığıyla oluşturulan nesneler aracılığıyla DotNetObjectReference kullanıma sunulan yöntemler için nesnelerin kapsamlı nesneler olarak kaydedilmesi gerekir. Bu, uygulamanın kullandığı tüm DI hizmetleri için geçerlidir.
    • Statik yöntemler için, uygulama bir sunucu örneğindeki tüm kullanıcılar arasında açıkça tasarıma göre durum paylaşmadığı sürece, istemciyle kapsamı belirlenmeyecek 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 oluşturma (XSS) güvenlik açıklarına neden olmadan verileri geçirmeyi işlediğinden emin olun. Örneğin, bir öğenin özelliğini ayarlayarak innerHTML kullanıcı tarafından sağlanan verileri DOM'a yazmayın. ve diğer güvenli olmayan JavaScript temel öğelerini devre dışı bırakmak eval 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üvenlik İlkesiNi Zorunlu Kılma .
• Çerçevenin dağıtım uygulamasının üzerine .NET çağrılarının özel dağıtımını 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 Blazor form 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 zaman uyumsuz olduğundan, uygulamanın yeni bir işleme oluşturarak tepki vermesi için zamana sahip olmadan ö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 koşullu olarak değerini counttemel alır:

<p>Count: @count</p>

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

@code 
{
    private int count = 0;

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

İstemci, çerçeve bu bileşenin yeni bir işlemesini oluşturmadan önce bir veya daha fazla artım olayı dağıtabilir. Sonuç olarakcount, düğme kullanıcı arabirimi tarafından yeterince hızlı bir şekilde kaldırılmadığından kullanıcı tarafından üç kat 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++;
        }
    }
}

denetimi işleyicinin if (count < 3) { ... } içine ekleyerek, artırma count kararı geçerli uygulama durumunu temel alı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ğırması, dış hizmetten veya veritabanından veri getirme gibi uzun süre çalışan bir işlemi zaman uyumsuz olarak çağırırsa, bir koruma 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 olarak true DataService.GetDataAsync ayarlırisLoading. iken isLoading true, düğme kullanıcı arabiriminde devre dışı bırakılı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 koruma deseni, arka plan işlemi desenle async-await zaman uyumsuz olarak yürütülürse ç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 koruma kullanmaya ek olarak, bileşen atıldığında uzun süre çalışan işlemleri iptal etmek için bir CancellationToken kullanmayı göz önünde bulundurun. 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 onscrollgibi oninput 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üğe kaydetme ve hassas veriler
• HTTPS ile aktarımdaki bilgileri koruma
• Siteler arası betik oluşturma (XSS)
• Çıkış noktaları arası koruma
• Tıklama jakı
• Yeniden yönlendirmeleri açma

Günlüğe kaydetme ve hassas veriler

JS istemci ve sunucu arasındaki birlikte çalışma etkileşimleri sunucu günlüklerine örneklerle kaydedilir ILogger . Blazor gerçek olaylar veya JS birlikte çalışma girişleri ve çıkışları gibi hassas bilgilerin günlüğe 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, ayrıntılı hatalar etkinleştirilerek hassas hata bilgileri istemcinin kullanımına sunulabilir.

HTTPS ile aktarımdaki bilgileri koruma

Blazor , istemci ile sunucu arasındaki iletişim için kullanır SignalR . Blazor normalde, genellikle WebSockets olan anlaşma yapan aktarım SignalR 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ı betik oluşturma (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ı.
• İşleme 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.
• Birlikte çalışma sonuçlarına JS .NET 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. ile CircuitOptions.MaxBufferedUnacknowledgedRenderBatchesyapılandırıldı.
• İstemciden yanıt almadan bir dakika sonra herhangi bir .NET'ten JavaScript çağrısına zaman aşımına uyacaktır. ile CircuitOptions.JSInteropDefaultCallTimeoutyapılandırıldı.
• Birlikte çalışma sırasında JS tarayıcıdan gelen tüm girişlerde temel doğrulama gerçekleştirir:
  • .NET başvuruları geçerli ve .NET yöntemi tarafından beklenen türde.
  • Veriler yanlış biçimlendirilmiş değil.
  • Yöntem için doğru sayıda bağımsız değişken yükte bulunur.
  • Yöntemi çağırmadan önce bağımsız değişkenler veya sonuç doğru seri durumdan çı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.
  • Olayın verileri seri durumdan çıkarılabilir.
  • Olayla 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 gayri meşru olduğunu ve meşru istemci tarafından oluşturulamadığını belirlerse, bir özel durum oluşturun. Özel durum oluşturma devreyi yok eder ve oturumu sonlandırır.
• Günlüklere dahil edilen toplu işleme 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 her iki yönde birlikte çalışma çağrılarında girişe 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 bir dosyadaki işaretlemenin yordamsal C# mantığına dönüştürüldüğü bir .razor derleme zamanı adımı yürütü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.
• Betik etiketlerine izin verilmez ve uygulamanın bileşen işleme ağacına dahil edilmemelidir. Bir bileşenin işaretlemesinde bir betik etiketi varsa, derleme zamanı hatası oluşturulur.
• Bileşen yazarları, kullanmadan RazorC# dilinde bileşenler yazabilir. Bileşen yazarı, çıkış gönderirken doğru API'leri kullanmakla sorumludur. Örneğin, bir XSS güvenlik açığı oluşturabileceğinden , değil builder.AddMarkupContent(0, someUserSuppliedString)kullanın builder.AddContent(0, someUserSuppliedString) .

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üvenlik İlkesiNi Zorunlu Kılma .

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

Çıkış noktaları 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:

• Uygulamaları önlemek için ek önlemler alınmadığı sürece çıkış noktaları arası erişim sağlanabilir. Çıkış noktaları arası erişimi devre dışı bırakmak için, CORS Ara Yazılımını işlem hattına ekleyerek ve uç nokta meta verilerine Blazor ekleyerek DisableCorsAttribute uç noktada CORS'yi devre dışı bırakın veya Çıkış Noktaları Arası Kaynak Paylaşımı'nı yapılandırarak SignalR izin verilen kaynak 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, CORS, uç nokta yol oluşturucusunun BlazorSignalR çağrısından DisableCorsAttribute MapBlazorHub sonra meta verileri uç nokta meta verilerine ekleyerek 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 jakı

Tıklama jacking, kullanıcıyı saldırı altında sitede eylemler gerçekleştirmesi için kandırmak için siteyi farklı bir kaynaktan sitenin içinde yer alan bir site olarak <iframe> işlemeyi içerir.

Bir uygulamayı içinde <iframe>işlemeye karşı korumak için İçerik Güvenlik İlkesi (CSP) ve X-Frame-Options üst bilgisini kullanın.

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

Yeniden yönlendirmeleri açma

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, kullanımı NavigationManageraracılığıyla gezinti isteklerini program aracılığıyla da tetikleyebilir. Bu tür senaryolarda uygulama bir istemci tarafı gezintisi gerçekleştirebilir veya tarayıcıya yeni konuma gideceğini belirtebilir.

Bileşenler:

• Gezinti çağrısı bağımsız değişkenlerinin bir parçası olarak 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ırı, yöntemin çağrılış bir parçası olarak bazı kullanıcı girişlerini kullanmak için 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:

• Olaylara ait bağımsız değişkenleri doğrulayın.
• Birlikte çalışma çağrılarından gelen JS girişleri ve sonuçları doğrulayın.
• Çağrıları birlikte kullanmak için .NET JS için kullanıcı girişini kullanmaktan (veya önceden doğrulamaktan) kaçının.
• İstemcinin ilişkisiz miktarda bellek ayırmasını engelleyin.
  • Bileşen içindeki veriler.
  • DotNetObjectReference nesneleri istemciye döndürülür.
• Birden çok gönderime karşı koruma.
• Bileşen atı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, url'lere NavigationManager.NavigateTo yönelik çağrıların bir parçası olarak kullanmaktan kaçının ve önlenemezse, önce izin verilen bir dizi kaynakta 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üvenlik İlkesiNi Zorunlu Kılma .
• Tıklama jaklarına karşı korumak 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.