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

Bu makalede, statik sunucu tarafı işleme ile Web Apps geliştirirken Blazor geliştiricilerin dikkate alması gereken güvenlik konuları açıklanmaktadır.

Blazor etkileşimli web uygulamaları yazmak için üç farklı modeli bir arada sunar. HTTP tabanlı bir istek/yanıt modeli olan geleneksel sunucu tarafı işleme. Tabanlı SignalRbir işleme modeli olan etkileşimli sunucu tarafı işleme. Son olarak, WebAssembly'yi temel alan bir işleme modeli olan istemci tarafı işleme.

Desteklenen işleme modlarından birinde işlenen etkileşimli bileşenler olduğunda, etkileşimli işleme modları için tanımlanan tüm genel güvenlik konuları Web Apps için geçerlidir Blazor . Aşağıdaki bölümlerde Web Apps'te Blazor etkileşimli olmayan sunucu tarafı işlemeye özgü güvenlik konuları ve işleme modları birbiriyle etkileşim kurarken geçerli olan belirli noktalar açıklanmaktadır.

Sunucu tarafı işleme için genel dikkat edilmesi gerekenler

Sunucu tarafı işleme (SSR) modeli, HTTP'nin geleneksel istek/yanıt modelini temel alır. Bu nedenle, SSR ile istek/yanıt HTTP'leri arasında ortak endişe alanları vardır. Genel güvenlik konuları ve belirli tehditler başarıyla azaltılmalıdır. Çerçeve, bu tehditlerden bazılarını yönetmek için yerleşik mekanizmalar sağlar, ancak diğer tehditler uygulama koduna özeldir ve uygulama tarafından işlenmesi gerekir. Bu tehditler aşağıdaki gibi kategorilere ayırılabilir:

• Kimlik doğrulaması ve yetkilendirme: Uygulama, kullanıcının kimliğinin doğrulandığından ve uygulamaya ve kullanıma sağladığı kaynaklara erişme yetkisinin olduğundan emin olmalıdır. Çerçeve, kimlik doğrulaması ve yetkilendirme için yerleşik mekanizmalar sağlar, ancak uygulamanın mekanizmaların düzgün yapılandırıldığından ve kullanıldığından emin olması gerekir. Kimlik doğrulaması ve yetkilendirme için yerleşik mekanizmalar, belgelerin Sunucu güvenlik düğümünde Blazor ve ASP.NET Core belgelerinin Güvenlik veIdentitydüğümünde ele alınmıştır, bu nedenle bunlar burada ele alınmayacaktır.

• Giriş doğrulama ve temizleme: Bir istemciden gelen tüm girişler kullanılmadan önce doğrulanmalı ve temizlenmelidir. Aksi takdirde, uygulama SQL ekleme, siteler arası betik oluşturma, siteler arası istek sahteciliği, açık yeniden yönlendirme ve diğer saldırı biçimleri gibi saldırılara maruz kalabilir. Giriş, isteğin herhangi bir yerinden gelebilir.

• Oturum yönetimi: Kullanıcı oturumlarının düzgün yönetilmesi, uygulamanın oturum düzeltme, oturum ele geçirme ve diğer saldırılar gibi saldırılara maruz kalmadığından emin olmak için kritik öneme sahiptir. Oturumda depolanan bilgilerin düzgün bir şekilde korunması ve şifrelenmesi ve uygulamanın kodunun kötü niyetli bir kullanıcının oturumları tahmin etmesini veya düzenlemesini engellemesi gerekir.

• Hata işleme ve günlüğe kaydetme: Uygulamanın hataların düzgün işlenip günlüğe kaydedildiğinden emin olması gerekir. Aksi takdirde uygulama, bilgilerin açığa çıkması gibi saldırılara maruz kalabilir. Uygulama yanıtta hassas bilgiler döndürdüğünde veya uygulama uygulamaya saldırmak için kullanılabilecek verilerle ayrıntılı hata iletileri döndürdüğünde bu durum oluşabilir.

• Veri koruması: Hassas veriler, WebAssembly'de çalışırken uygulama mantığını da içeren düzgün bir şekilde korunmalıdır, çünkü bunlar kolayca tersine mühendislik uygulanabilir.

• Hizmet reddi: Uygulama, hizmet reddi gibi saldırılara maruz kalmadığından emin olmalıdır. Örneğin, uygulama deneme yanılma saldırılarına karşı düzgün korunmadığında veya bir eylem uygulamanın çok fazla kaynak tüketmesine neden olabileceğinde bu durum ortaya çıkar.

Giriş doğrulama ve temizleme

CSRF belirteci, kimlik doğrulaması cookie, oturum tanımlayıcısı veya kimliği doğrulanmış şifreleme ile korunan başka bir yük gibi bilgileri sunucuda oluşturulmadığı ve korunmadığı sürece istemciden gelen tüm girişlerin güvenilmeyen olarak kabul edilmesi gerekir.

Giriş normalde bağlama işlemi aracılığıyla , örneğin öznitelik veya [SupplyParameterFromForm] öznitelik aracılığıyla uygulama tarafından [SupplyParameterFromQuery] kullanılabilir. Bu girişi işlemeden önce uygulamanın verilerin geçerli olduğundan emin olması gerekir. Örneğin, uygulama form verilerini bir bileşen özelliğine eşlerken bağlama hatası olmadığını onaylamalıdır. Aksi takdirde uygulama geçersiz verileri işleyebilecek.

Giriş yeniden yönlendirme gerçekleştirmek için kullanılıyorsa, uygulamanın girişin geçerli olduğundan ve geçersiz olarak kabul edilen bir etki alanına veya uygulama temel yolu içindeki geçersiz bir alt yola işaret etmediğinden emin olması gerekir. Aksi takdirde uygulama, bir saldırganın kullanıcıyı kötü amaçlı bir siteye yönlendiren bir bağlantı oluşturabildiği açık yeniden yönlendirme saldırılarına maruz kalabilir.

Giriş bir veritabanı sorgusu gerçekleştirmek için kullanılıyorsa, uygulamanın girişin geçerli olduğunu ve uygulamayı SQL ekleme saldırılarına maruz getirmediğini onaylaması gerekir. Aksi takdirde, saldırgan veritabanından bilgi ayıklamak veya veritabanını değiştirmek için kullanılabilecek kötü amaçlı bir sorgu oluşturabilir.

Kullanıcı girişinden gelmiş olabilecek veriler de yanıta eklenmeden önce temizlenmelidir. Örneğin, girişte, kullanıcıdan bilgi ayıklamak veya kullanıcı adına eylemler gerçekleştirmek için kullanılabilecek siteler arası betik saldırıları gerçekleştirmek için kullanılabilecek HTML veya JavaScript bulunabilir.

Çerçeve, giriş doğrulama ve temizleme işlemlerine yardımcı olmak için aşağıdaki mekanizmaları sağlar:

• Tüm ilişkili form verileri temel doğruluk için doğrulanır. Bir giriş ayrıştırılamıyorsa bağlama işlemi, verilerle herhangi bir eylem gerçekleştirmeden önce uygulamanın keşfedebileceği bir hata bildirir. Yerleşik EditForm bileşen, formu geri çağırmadan önce bunu dikkate OnValidSubmit alır. Blazor bir veya daha fazla bağlama hatası varsa geri çağırmanın yürütülmesini önler.
• Çerçeve, siteler arası istek sahteciliği saldırılarına karşı koruma sağlamak için bir sahteciliğe karşı koruma belirteci kullanır. Daha fazla bilgi için bkz . ASP.NET Core Blazor kimlik doğrulaması ve yetkilendirme ve ASP.NET Core Blazor formlara genel bakış.

Verilerin o anda geçerli ve doğru olduğundan ve kullanıcının eylemi gerçekleştirmesine izin verildiğinden emin olmak için, belirli bir eylem gerçekleştirildikten sonra tüm giriş ve izinler sunucuda doğrulanmalıdır. Bu yaklaşım, etkileşimli sunucu tarafı işleme için sağlanan güvenlik kılavuzuyla tutarlıdır.

Oturum yönetimi

Oturum yönetimi çerçeve tarafından işlenir. Çerçeve, kullanıcı oturumunu cookie tanımlamak için bir oturum kullanır. Oturum cookie , ASP.NET Core Data Protection API'leri kullanılarak korunur. Oturuma cookie tarayıcıda çalışan JavaScript kodu erişemez ve kullanıcı tarafından kolayca tahmin edilemez veya işlenemez.

Hizmetler içinde depolanan veriler gibi diğer oturum verileriyle ilgili olarak, belirli bir işlem örneğindeki tüm kullanıcı oturumlarında paylaşılan tekil hizmetlerin aksine, kapsamlı hizmetler belirli bir kullanıcı oturumuna göre benzersiz olduğundan oturum verileri kapsamlı hizmetler içinde depolanmalıdır.

SSR söz konusu olduğunda, hizmetin ömrü tek bir istekle sınırlı olduğundan çoğu durumda kapsamı belirlenmiş ve geçici hizmetler arasında çok fazla fark yoktur. İki senaryoda fark vardır:

• Hizmet birden fazla konuma veya istek sırasında farklı zamanlarda eklenirse.
• Hizmet etkileşimli bir sunucu bağlamında kullanılabiliyorsa, burada birden çok işlemeden kurtulabilir ve hizmetin kapsamının kullanıcı oturumu olarak belirlenmiş olması temelidir.

Hata işleme ve günlüğe kaydetme

Çerçeve, uygulama için çerçeve düzeyinde yerleşik günlük kaydı sağlar. Çerçeve, bir formun sahtelik önleme belirtecinin doğrulanamaması, kök bileşenin işlenmeye başlaması ve bir eylemin ne zaman dağıtılması gibi önemli olayları günlüğe kaydeder. Uygulama, kaydedilmesi önemli olabilecek diğer olayları günlüğe kaydetmekle sorumludur.

Çerçeve, uygulama için çerçeve düzeyinde yerleşik hata işleme sağlar. Çerçeve, bir bileşenin işlenmesi sırasında oluşan hataları işler ve kolay bir hata iletisi görüntülemek için hata sınırı mekanizmasını kullanır veya hatanın hata sayfasını işlemek için yapılandırılan özel durum işleme ara yazılımına kadar kabarcık oluşturmasına izin verir.

Yanıt istemciye gönderilmeye başladıktan sonra akış işleme sırasında oluşan hatalar, son yanıtta genel bir hata iletisi olarak görüntülenir. Hatanın nedeni hakkındaki ayrıntılar yalnızca geliştirme sırasında eklenir.

Veri koruması

Çerçeve, belirli bir kullanıcı oturumu için hassas bilgileri korumaya yönelik mekanizmalar sunar ve yerleşik bileşenlerin kimlik doğrulaması kullanırken cookie kullanıcı kimliğini koruma gibi hassas bilgileri korumak için bu mekanizmaları kullanmasını sağlar. Çerçeve tarafından işlenen senaryoların dışında, uygulamaya özgü diğer bilgilerin korunması geliştirici kodundan sorumludur. Bunu yapmanın en yaygın yolu ASP.NET Çekirdek Veri Koruma API'leri veya başka bir şifreleme biçimidir. Genel bir kural olarak, uygulama şunlardan sorumludur:

• Kullanıcının başka bir kullanıcının özel bilgilerini inceleyememe veya değiştirememesini sağlama.
• Kullanıcının iç tanımlayıcı gibi başka bir kullanıcının kullanıcı verilerini değiştirememesini sağlama.

Veri korumayla ilgili olarak, kodun nerede yürütülmekte olduğunu açıkça anlamanız gerekir. Statik sunucu tarafı işleme (statik SSR) ve etkileşimli sunucu tarafı işleme (etkileşimli SSR) için kod sunucuda depolanır ve hiçbir zaman istemciye ulaşmaz. Interactive WebAssembly işleme modu için uygulama kodu her zaman istemciye ulaşır; bu da uygulama kodunda depolanan hassas bilgilerin uygulamaya erişimi olan herkesin kullanımına açık olduğu anlamına gelir. Kodu "korumak" için gizleme ve benzeri teknikler etkili değildir. Kod istemciye ulaştığında hassas bilgileri ayıklamak için tersine mühendislik yapılabilir.

Hizmet reddi

Çerçeve, sunucu düzeyinde istek/yanıt parametrelerinde maksimum istek boyutu ve üst bilgi boyutu gibi sınırlar sağlar. Uygulama koduyla ilgili olarak, Blazor'nin form eşleme sistemi, MVC'nin model bağlama sistemi tarafından tanımlananlara benzer sınırlar tanımlar:

• Hata sayısı üst sınırı.
• Bağlayıcı için en fazla özyineleme derinliği sınırı.
• Bir koleksiyona bağlı öğe sayısı üst sınırı.

Buna ek olarak, form için tanımlanan en büyük form anahtarı boyutu ve değer boyutu ve en fazla girdi sayısı gibi sınırlar vardır.

Genel olarak, uygulamanın bir isteğin sunucu tarafından asimetrik miktarda çalışmayı tetikleme olasılığı olduğunda değerlendirmesi gerekir. Buna örnek olarak, kullanıcı N tarafından parametrelendirilen bir istek gönderdiğinde ve sunucu yanıt olarak N kez daha pahalı bir işlem gerçekleştirdiğinde, burada N kullanıcının denetlediği ve süresiz olarak büyüyebileceği bir parametredir. Normalde, uygulamanın işlemeye istekli olduğu maksimum N sınırı getirmesi veya herhangi bir işlemin sabit bir faktör tarafından istekten daha az, eşit veya daha pahalı olduğundan emin olması gerekir.

Bu yönün, istemcinin gerçekleştirdiği iş ile sunucunun gerçekleştirdiği iş arasındaki büyüme farkıyla, belirli bir 1→N karşılaştırmasından daha fazla ilgisi vardır. Örneğin, bir istemci N biriminin gerçekleştirmesi zaman alan bir iş öğesi (listeye öğe ekleme) gönderebilir, ancak sunucunun işlenmesi için N^2^ gerekir (çünkü çok saf bir şey yapıyor olabilir). Önemli olan N ile N^2^ arasındaki farktır.

Bu nedenle, sunucunun uygulamaya özgü ne kadar iş yapmak için istekli olması gerektiğine ilişkin bir sınır vardır. Kaynaklar sunucuda olduğundan bu özellik sunucu tarafı iş yükleri için geçerlidir ancak çoğu durumda istemcideki WebAssembly iş yükleri için geçerli olmayabilir.

Diğer önemli yön ise bunun yalnızca CPU süresine ayrılmamış olmasıdır. Ayrıca bellek, ağ ve disk üzerindeki alan gibi tüm kaynaklar için de geçerlidir.

WebAssembly iş yükleri için genellikle istemcinin gerçekleştirdiği iş miktarı konusunda çok az endişe vardır çünkü istemci normalde istemcide kullanılabilir olan kaynaklarla sınırlıdır. Ancak, örneğin bir uygulama diğer kullanıcılardan veri görüntülüyorsa ve bir kullanıcı, verileri görüntüleyen istemcileri kullanıcı tarafından eklenen veri miktarıyla orantılı olmayan bir iş yapmaya zorlayan sisteme veri ekleme yeteneğine sahipse istemcinin etkilenebileceği bazı senaryolar vardır.

Önerilen (kapsamlı olmayan) denetim listesi

• Kullanıcının kimliğinin doğrulandığından ve uygulamaya ve kullanıma sağladığı kaynaklara erişim yetkisine sahip olduğundan emin olun.
• Bir istemciden gelen tüm girişleri kullanmadan önce doğrulayın ve temizleme.
• Durumun kullanıcılar arasında yanlışlıkla paylaşılmadığından emin olmak için kullanıcı oturumlarını düzgün bir şekilde yönetin.
• Hassas bilgilerin açığa çıkmasına engel olmak için hataları düzgün bir şekilde işleyin ve günlüğe kaydedin.
• Kullanıcılar tarafından gerçekleştirilen olası sorunları ve denetim eylemlerini belirlemek için uygulamada önemli olayları günlüğe kaydetme.
• ASP.NET Temel Veri Koruma API'lerini veya kullanılabilir bileşenlerden birini (Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage, PersistentComponentState) kullanarak hassas bilgileri koruyun.
• Uygulamanın belirli bir istek tarafından kullanılabilecek kaynakları anladığınızdan ve hizmet reddi saldırılarını önlemek için sınırları olduğundan emin olun.