ASP.NET MVC ve Web Sayfalarında XSRF/CSRF Önleme

Makale
07/13/2023

Siteler arası istek sahteciliği (XSRF veya CSRF olarak da bilinir), kötü amaçlı bir web sitesinin bir istemci tarayıcısı ile bu tarayıcının güvendiği bir web sitesi arasındaki etkileşimi etkilediği web'de barındırılan uygulamalara yönelik bir saldırıdır. Web tarayıcıları bir web sitesine yapılan her istekte kimlik doğrulama belirteçlerini otomatik olarak göndereceği için bu saldırılar mümkün hale gelir. Kurallı örnek, ASP gibi bir kimlik doğrulama tanımlama bilgisidir. NET'in Forms Kimlik Doğrulama bileti. Ancak, herhangi bir kalıcı kimlik doğrulama mekanizması kullanan web siteleri (Windows Kimlik Doğrulaması, Temel vb.) bu saldırılar tarafından hedeflenebilir.

XSRF saldırısı, kimlik avı saldırısından farklıdır. Kimlik avı saldırıları, kurbandan etkileşim gerektirir. Kimlik avı saldırısında, kötü amaçlı bir web sitesi hedef web sitesini taklit eder ve kurban saldırgana hassas bilgiler sağlamakla kandırılır. XSRF saldırısında, genellikle kurbandan etkileşime gerek yoktur. Bunun yerine, saldırgan tarayıcının tüm ilgili tanımlama bilgilerini hedef web sitesine otomatik olarak göndermesine güvenir.

Daha fazla bilgi için bkz. Open Web Application Security Project (OWASP) XSRF.

Saldırının anatomisi

XSRF saldırısına yol açmak için bazı çevrimiçi bankacılık işlemleri gerçekleştirmek isteyen bir kullanıcıyı düşünün. Bu kullanıcı ilk olarak WoodgroveBank.com ziyaret eder ve oturum açar; bu noktada yanıt üst bilgisi kimlik doğrulama tanımlama bilgisini içerir:

HTTP/1.1 200 OK
Date: Mon, 18 Jun 2012 21:22:33 GMT
X-AspNet-Version: 4.0.30319
Set-Cookie: .ASPXAUTH={authentication-token}; path=/; secure; HttpOnly;
{ Cache-Control, Content-Type, Location, Server and other keys/values not listed. }

Kimlik doğrulama tanımlama bilgisi bir oturum tanımlama bilgisi olduğundan, tarayıcı işlemi çıktığında tarayıcı tarafından otomatik olarak temizlenir. Ancak, bu zamana kadar tarayıcı otomatik olarak her WoodgroveBank.com isteğine tanımlama bilgisini ekler. Kullanıcı artık 1000 ABD dolarını başka bir hesaba aktarmak istiyor, bu nedenle bankacılık sitesinde bir form dolduruyor ve tarayıcı sunucuya şu isteği yapıyor:

POST /DoTransfer HTTP/1.1
Host: WoodgroveBank.com
Content-Type: application/x-www-form-urlencoded
Cookie: .ASPXAUTH={authentication-token}
toAcct=12345&amount=1,000.00

Bu işlemin bir yan etkisi olduğundan (parasal bir işlem başlatır), bankacılık sitesi bu işlemi başlatmak için bir HTTP POST gerektirmeyi seçti. Sunucu istekten kimlik doğrulama belirtecini okur, geçerli kullanıcının hesap numarasını arar, yeterli fon bulunduğunu doğrular ve ardından işlemi hedef hesaba başlatır.

Çevrimiçi bankacılığı tamamlandı, kullanıcı bankacılık sitesinden uzaklaşıyor ve web'de diğer konumları ziyaret ediyor. Bu sitelerden biri olan fabrikam.com, bir iframe> içine <eklenmiş bir sayfada aşağıdaki işaretlemeyi içerir:

<form id="theForm" action="https://WoodgroveBank.com/DoTransfer" method="post">
    <input type="hidden" name="toAcct" value="67890" />
    <input type="hidden" name="amount" value="250.00" />
</form>
<script type="text/javascript">
    document.getElementById('theForm').submit();
</script>

Bu da tarayıcının bu isteği göndermesine neden olur:

POST /DoTransfer HTTP/1.1
Host: WoodgroveBank.com
Content-Type: application/x-www-form-urlencoded
Cookie: .ASPXAUTH={authentication-token}
toAcct=67890&amount=250.00

Saldırgan, kullanıcının hedef web sitesi için geçerli bir kimlik doğrulama belirtecine sahip olabileceği gerçeğinden yararlanıyor ve tarayıcının hedef siteye otomatik olarak HTTP POST oluşturmasına neden olmak için küçük bir Javascript parçacığı kullanıyor. Kimlik doğrulama belirteci hala geçerliyse, bankacılık sitesi saldırganın seçtiği hesaba 250 ABD doları aktarım başlatır.

Etkisiz azaltmalar

Yukarıdaki senaryoda, WoodgroveBank.com SSL üzerinden erişildiği ve yalnızca SSL kimlik doğrulama tanımlama bilgisine sahip olmasının saldırıyı engellemek için yetersiz olduğunu unutmamak ilginçtir. Saldırgan, form> öğesinde <URI şemasını (https) belirtebilir ve bu tanımlama bilgileri hedeflenen hedefin URI düzeniyle tutarlı olduğu sürece tarayıcı hedef siteye süresi dolmuş tanımlama bilgileri göndermeye devam eder.

Yalnızca güvenilen siteleri ziyaret etmek çevrimiçi ortamda güvende kalmaya yardımcı olduğundan, kullanıcının güvenilmeyen siteleri ziyaret etmemesi gerektiği tartışılabilir. Bu konuda bazı gerçekler var, ancak ne yazık ki bu tavsiye her zaman pratik değildir. Belki de kullanıcı yerel haber sitesine ConsolidatedMessenger.com "güvenir" ve bunun yerine bu siteyi ziyaret eder, ancak bu sitede bir saldırganın fabrikam.com üzerinde çalışan kod parçacığını eklemesine olanak tanıyan bir XSS güvenlik açığı vardır.

Gelen isteklerin etki alanınıza başvuran bir Referer üst bilgisi olduğunu doğrulayabilirsiniz. Bu, farkında olmadan üçüncü taraf etki alanından gönderilen istekleri durdurur. Ancak bazı kişiler gizlilik nedeniyle tarayıcılarının Başvuran üst bilgisini devre dışı bırakır ve kurbanda belirli güvensiz yazılımlar yüklüyse saldırganlar bazen bu üst bilgiyi yanıltabilir. Başvuran üst bilgisinin doğrulanması, XSRF saldırılarını önlemeye yönelik güvenli bir yaklaşım olarak kabul edilmez.

Web Stack Runtime XSRF azaltmaları

ASP.NET Web Stack Çalışma Zamanı, XSRF saldırılarına karşı savunma yapmak için eşitleyici belirteci deseninin bir değişkenini kullanır. Eşitleyici belirteci düzeninin genel biçimi, her HTTP POST ile sunucuya iki XSRF önleme belirteci gönderilmesidir (Kimlik doğrulama belirtecine ek olarak): biri tanımlama bilgisi, diğeri ise form değeri olarak. ASP.NET çalışma zamanı tarafından oluşturulan belirteç değerleri saldırgan tarafından belirlenimci veya öngörülebilir değildir. Belirteçler gönderildiğinde, sunucu isteğin devam etme iznini yalnızca her iki belirteç de karşılaştırma denetiminden geçtiğinde verir.

XSRF istek doğrulama oturum belirteci HTTP tanımlama bilgisi olarak depolanır ve şu anda yükünde aşağıdaki bilgileri içerir:

Rastgele bir 128 bit tanımlayıcıdan oluşan bir güvenlik belirteci.
Aşağıdaki görüntüde, Internet Explorer F12 geliştirici araçlarıyla görüntülenen XSRF istek doğrulama oturumu belirteci gösterilmektedir: (Bunun geçerli uygulama olduğunu ve değişme olasılığı da yüksek olduğunu unutmayın.)

My A S P dot NET M V C Application Index sayfasını gösteren ekran görüntüsü. Ağ sekmesi açık.

Alan belirteci olarak <input type="hidden" /> depolanır ve yükünde aşağıdaki bilgileri içerir:

Oturum açan kullanıcının kullanıcı adı (kimliği doğrulandıysa).
IAntiForgeryAdditionalDataProvider tarafından sağlanan ek veriler.

XSRF karşıtı belirteçlerin yükleri şifrelenir ve imzalandığından, belirteçleri incelemek için araçlar kullanırken kullanıcı adını görüntüleyemezsiniz. Web uygulaması ASP.NET 4.0'ı hedeflediğinde, şifreleme hizmetleri MachineKey.Encode yordamı tarafından sağlanır. Web uygulaması ASP.NET 4.5 veya üzerini hedeflediğinde, daha iyi performans, genişletilebilirlik ve güvenlik sunan MachineKey.Protect yordamı tarafından şifreleme hizmetleri sağlanır. Diğer ayrıntılar için aşağıdaki blog gönderilerine bakın:

Belirteçleri oluşturma

XSRF'den koruma belirteçleri oluşturmak için MVC görünümünden veya @AntiForgery.GetHtml() Razor sayfasından @Html.AntiForgeryToken yöntemini çağırın. Çalışma zamanı daha sonra aşağıdaki adımları gerçekleştirir:

Geçerli HTTP isteği zaten bir anti-XSRF oturum belirteci (XSRF tanımlama bilgisi __RequestVerificationToken) içeriyorsa, güvenlik belirteci ondan ayıklanır. HTTP isteği bir anti-XSRF oturum belirteci içermiyorsa veya güvenlik belirtecinin ayıklanması başarısız olursa, yeni bir rastgele XSRF önleme belirteci oluşturulur.
Yukarıdaki (1) adımdaki güvenlik belirteci ve oturum açmış geçerli kullanıcının kimliği kullanılarak XSRF'den koruma alan belirteci oluşturulur. (Kullanıcı kimliğini belirleme hakkında daha fazla bilgi için aşağıdaki Özel destek içeren senaryolar bölümüne bakın.) Ayrıca, bir IAntiForgeryAdditionalDataProvider yapılandırılırsa, çalışma zamanı GetAdditionalData yöntemini çağırır ve döndürülen dizeyi alan belirtecine ekler. (Daha fazla bilgi için Yapılandırma ve genişletilebilirlik bölümüne bakın.)
(1) adımında yeni bir XSRF önleme belirteci oluşturulduysa, bunu içerecek yeni bir oturum belirteci oluşturulur ve giden HTTP tanımlama bilgileri koleksiyonuna eklenir. (2) adımındaki alan belirteci bir <input type="hidden" /> öğeye sarmalanır ve bu HTML işaretlemesi veya AntiForgery.GetHtml()değerinin Html.AntiForgeryToken() dönüş değeri olur.

Belirteçleri doğrulama

Gelen XSRF önleme belirteçlerini doğrulamak için geliştirici, MVC eyleminde veya denetleyicisinde ValidateAntiForgeryToken özniteliğini içerir veya Razor sayfasından çağrı @AntiForgery.Validate() yapar. Çalışma zamanı aşağıdaki adımları gerçekleştirir:

Gelen oturum belirteci ve alan belirteci okunur ve her birinden XSRF önleme belirteci ayıklanır. XSRF önleme belirteçleri, oluşturma yordamında adım başına (2) aynı olmalıdır.
Geçerli kullanıcının kimliği doğrulanırsa, kullanıcı adı alan belirtecinde depolanan kullanıcı adıyla karşılaştırılır. Kullanıcı adları eşleşmelidir.
IAntiForgeryAdditionalDataProvider yapılandırılmışsa, çalışma zamanı ValidateAdditionalData yöntemini çağırır. yöntemi true Boole değerini döndürmelidir.

Doğrulama başarılı olursa, isteğin devam etmesine izin verilir. Doğrulama başarısız olursa, çerçeve bir HttpAntiForgeryException oluşturur.

Hata koşulları

ASP.NET Web Stack Runtime v2'den başlayarak, doğrulama sırasında oluşturulan tüm HttpAntiForgeryException,neyin yanlış gittiği hakkında ayrıntılı bilgi içerir. Şu anda tanımlanmış hata koşulları şunlardır:

Oturum belirteci veya form belirteci istekte yok.
Oturum belirteci veya form belirteci okunamıyor. Bunun en olası nedeni, ASP.NET Web Stack Çalışma Zamanı'nın eşleşmeyen sürümlerini çalıştıran bir grup veya Web.config içindeki machineKey> öğesinin <makineler arasında farklılık gösterdiği bir grup olabilir. XSRF önleme belirtecini değiştirerek bu özel durumu zorlamak için Fiddler gibi bir araç kullanabilirsiniz.
Oturum belirteci ve alan belirteci değiştirildi.
Oturum belirteci ve alan belirteci eşleşmeyen güvenlik belirteçleri içeriyor.
Alan belirtecinin içine eklenmiş kullanıcı adı, oturum açmış geçerli kullanıcının kullanıcı adıyla eşleşmiyor.
IAntiForgeryAdditionalDataProvider.ValidateAdditionalData yöntemi false döndürdü.

XSRF önleme özellikleri ayrıca belirteç oluşturma veya doğrulama sırasında ek denetim gerçekleştirebilir ve bu denetimler sırasındaki hatalar özel durumların oluşturulmasına neden olabilir. Daha fazla bilgi için WIF / ACS / talep tabanlı kimlik doğrulamasıve Yapılandırma ve genişletilebilirlik bölümlerine bakın.

Özel destek içeren senaryolar

Anonim kimlik doğrulama

Anti-XSRF sistemi anonim kullanıcılar için özel destek içerir; burada "anonim" IIdentity.IsAuthenticated özelliğinin false döndürdüğü bir kullanıcı olarak tanımlanır. Senaryolar, oturum açma sayfasına (kullanıcının kimliği doğrulanmadan önce) XSRF koruması sağlamayı ve uygulamanın kullanıcıları tanımlamak için IIdentity dışında bir mekanizma kullandığı özel kimlik doğrulama düzenlerini içerir.

Bu senaryoları desteklemek için oturum ve alan belirteçlerinin 128 bit rastgele oluşturulmuş bir opak tanımlayıcı olan bir güvenlik belirteci ile birleştirildiğini hatırlayın. Bu güvenlik belirteci, sitede gezinirken tek bir kullanıcının oturumunu izlemek için kullanılır, bu nedenle anonim tanımlayıcının amacına etkili bir şekilde hizmet eder. Yukarıda açıklanan oluşturma ve doğrulama yordamları için kullanıcı adı yerine boş bir dize kullanılır.

WIF / ACS / talep tabanlı kimlik doğrulaması

Normalde, .NET Framework yerleşik IIdentity sınıflarının IIdentity.Name özelliği belirli bir uygulama içindeki belirli bir kullanıcıyı benzersiz olarak tanımlamak için yeterlidir. Örneğin , FormsIdentity.Name üyelik veritabanında depolanan kullanıcı adını döndürür (bu veritabanına bağlı olarak tüm uygulamalar için benzersizdir), WindowsIdentity.Name kullanıcının etki alanı nitelenmiş kimliğini döndürür vb. Bu sistemler yalnızca kimlik doğrulaması sağlamaz; ayrıca bir uygulamanın kullanıcılarını da tanımlar .

Öte yandan, talep tabanlı kimlik doğrulaması belirli bir kullanıcının tanımlanmasını gerektirmez. Bunun yerine, ClaimsPrincipal ve ClaimsIdentity türleri, tek tek taleplerin "18+ yaş" veya "başka bir şey için yönetici" olabileceği bir Dizi Talep örneğiyle ilişkilendirilir. Kullanıcı tanımlanmamış olduğundan, çalışma zamanı ClaimsIdentity.Name özelliğini bu kullanıcı için benzersiz bir tanımlayıcı olarak kullanamaz. Ekip, ClaimsIdentity.Namenull döndürdüğü, kolay (görünen) bir ad döndürdüğü veya kullanıcı için benzersiz tanımlayıcı olarak kullanılmak üzere uygun olmayan bir dize döndürdüğü gerçek dünya örneklerini görmüştür.

Talep tabanlı kimlik doğrulaması kullanan dağıtımların çoğu özellikle Azure Access Control Hizmeti 'ni (ACS) kullanır. ACS, geliştiricinin tek tek kimlik sağlayıcılarını (ADFS, Microsoft Hesabı sağlayıcısı, Yahoo! gibi OpenID sağlayıcıları vb.) yapılandırmasına ve kimlik sağlayıcılarının ad tanımlayıcıları döndürmesine olanak tanır. Bu ad tanımlayıcıları e-posta adresi gibi Kişisel Bilgileri (PII) içerebilir veya Özel Kişisel Tanımlayıcı (PPID) gibi anonimleştirilebilir. Ne olursa olsun, tanımlama grubu (kimlik sağlayıcısı, ad tanımlayıcısı) sitede gezinirken belirli bir kullanıcı için uygun bir izleme belirteci görevi görür, bu nedenle ASP.NET Web Stack Çalışma Zamanı XSRF'yi önleme alan belirteçlerini oluştururken ve doğrularken kullanıcı adı yerine tanımlama grubu kullanabilir. Kimlik sağlayıcısı ve ad tanımlayıcısı için belirli URI'ler şunlardır:

https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

(daha fazla bilgi için bu ACS belge sayfasına bakın.)

Belirteç oluştururken veya doğrularken, ASP.NET Web Stack Çalışma Zamanı çalışma zamanında türlere bağlamayı dener:

Microsoft.IdentityModel.Claims.IClaimsIdentity, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 (WIF SDK için.)
System.Security.Claims.ClaimsIdentity (.NET 4.5 için).

Bu türler varsa ve geçerli kullanıcının IIIIdentity'i bu türlerden birini uygular veya alt sınıflarsa, XSRF koruması özelliği belirteçleri oluştururken ve doğrularken kullanıcı adı yerine (kimlik sağlayıcısı, ad tanımlayıcısı) tanımlama grubu kullanır. Böyle bir tanımlama grubu yoksa istek, geliştiriciye kullanımdaki belirli talep tabanlı kimlik doğrulama mekanizmasını anlamak için XSRF önleme sisteminin nasıl yapılandırılacağını açıklayan bir hatayla başarısız olur. Daha fazla bilgi için Yapılandırma ve genişletilebilirlik bölümüne bakın.

OAuth / OpenID kimlik doğrulaması

Son olarak, XSRF'yi önleme özelliği, OAuth veya OpenID kimlik doğrulaması kullanan uygulamalar için özel desteğe sahiptir. Bu destek buluşsal tabanlıdır: Geçerli IIdentity.Name http:// veya https:// ile başlıyorsa, kullanıcı adı karşılaştırmaları varsayılan OrdinalIgnoreCase karşılaştırıcısı yerine Sıralı karşılaştırıcı kullanılarak yapılır.

Yapılandırma ve genişletilebilirlik

Geliştiriciler bazen XSRF'den koruma oluşturma ve doğrulama davranışları üzerinde daha sıkı bir denetim isteyebilir. Örneğin, MVC ve Web Sayfaları yardımcılarının yanıta http tanımlama bilgilerini otomatik olarak eklemeye yönelik varsayılan davranışı istenmeyen bir durum olabilir ve geliştirici belirteçleri başka bir yerde kalıcı hale getirmek isteyebilir. Bu konuda yardımcı olacak iki API vardır:

AntiForgery.GetTokens(string oldCookieToken, out string newCookieToken, out string formToken);
AntiForgery.Validate(string cookieToken, string formToken);

GetTokens yöntemi, mevcut bir XSRF isteği doğrulama oturum belirtecini (null olabilir) alır ve yeni bir XSRF isteği doğrulama oturumu belirteci ve alan belirteci çıktısı olarak üretir. Belirteçler, dekorasyonu olmayan opak dizelerdir; örneğin formToken değeri bir <giriş> etiketinde sarmalanmaz. newCookieToken değeri null olabilir; bu durumda oldCookieToken değeri hala geçerlidir ve yeni yanıt tanımlama bilgisi ayarlanmamalıdır. GetTokens çağıranı, gerekli yanıt tanımlama bilgilerinin kalıcı hale getirilmesinden veya gerekli işaretlemelerin oluşturulmasından sorumludur; GetTokens yönteminin kendisi yanıtı yan etki olarak değiştirmez. Validate yöntemi, gelen oturum ve alan belirteçlerini alır ve bunlar üzerinde yukarıda belirtilen doğrulama mantığını çalıştırır.

AntiForgeryConfig

Geliştirici, Application_Start'dan XSRF önleme sistemini yapılandırabilir. Yapılandırma programlıdır. Static AntiForgeryConfig türünün özellikleri aşağıda açıklanmıştır. Talep kullanan kullanıcıların çoğu UniqueClaimTypeIdentifier özelliğini ayarlamak ister.

Özellik	Açıklama
AdditionalDataProvider	Belirteç oluşturma sırasında ek veriler sağlayan ve belirteç doğrulaması sırasında ek veriler kullanan bir IAntiForgeryAdditionalDataProvider . Varsayılan değer null'dır. Daha fazla bilgi için IAntiForgeryAdditionalDataProvider bölümüne bakın.
Cookiename	Anti-XSRF oturum belirtecini depolamak için kullanılan HTTP tanımlama bilgisinin adını sağlayan dize. Bu değer ayarlanmazsa, uygulamanın dağıtılan sanal yoluna göre otomatik olarak bir ad oluşturulur. Varsayılan değer null'dır.
Requiressl	XSRF'den koruma belirteçlerinin SSL ile güvenli bir kanal üzerinden gönderilmesi gerekip gerekmediğini belirten bir Boole değeri. Bu değer doğruysa, otomatik olarak oluşturulan tanımlama bilgileri "güvenli" bayrağına sahip olur ve SSL aracılığıyla gönderilmeyen bir isteğin içinden çağrılırsa XSRF API'leri oluşturulur. Varsayılan değer false şeklindedir.
SuppressIdentityHeuristicChecks	Anti-XSRF sisteminin talep tabanlı kimlikler için desteğini devre dışı bırakıp bırakmayacağını belirten bir Boole değeri. Bu değer doğruysa sistem, IIdentity.Name benzersiz bir kullanıcı başına tanımlayıcı olarak kullanmak için uygun olduğunu varsayar ve WIF / ACS / talep tabanlı kimlik doğrulaması bölümünde açıklandığı gibi özel durum IClaimsIdentity veya ClClaimsIdentity'yi denemez. `false` varsayılan değerdir.
UniqueClaimTypeIdentifier	Kullanıcı başına benzersiz tanımlayıcı olarak kullanmak için hangi talep türünün uygun olduğunu gösteren dize. Bu değer ayarlanırsa ve geçerli IIdentity talep tabanlıysa, sistem UniqueClaimTypeIdentifier tarafından belirtilen türdeki bir talebi ayıklamayı dener ve alan belirtecini oluştururken kullanıcının kullanıcı adı yerine ilgili değer kullanılır. Talep türü bulunamazsa sistem istekte başarısız olur. Varsayılan değer null değeridir. Bu değer, sistemin kullanıcının kullanıcı adı yerine daha önce açıklandığı gibi (kimlik sağlayıcısı, ad tanımlayıcısı) tanımlama grubu kullanması gerektiğini gösterir.

IAntiForgeryAdditionalDataProvider

IAntiForgeryAdditionalDataProvider türü, geliştiricilerin her belirteçte ek verileri yuvarlayarak XSRF'yi önleme sisteminin davranışını genişletmesine olanak tanır. GetAdditionalData yöntemi, alan belirteci her oluşturulduğunda çağrılır ve döndürülen değer oluşturulan belirtecin içine eklenir. Uygulayıcı bir zaman damgası, nonce veya bu yöntemden istediği başka bir değeri döndürebilir.

Benzer şekilde, bir alan belirteci her doğrulandığında ValidateAdditionalData yöntemi çağrılır ve belirtecin içine eklenmiş olan "ek veri" dizesi yöntemine geçirilir. Doğrulama yordamı bir zaman aşımı (belirtecin oluşturulduğu sırada depolanan zamana göre geçerli saati denetleyerek), bir nonce denetim yordamı veya istenen başka bir mantık uygulayabilir.

Tasarım kararları ve güvenlik konuları

Oturum ve alan belirteçlerini bağlayan güvenlik belirteci teknik olarak yalnızca anonim /kimliği doğrulanmamış kullanıcıları XSRF saldırılarına karşı korumaya çalışırken gereklidir. Kullanıcının kimliği doğrulandığında, kimlik doğrulama belirtecinin kendisi (tanımlama bilgisi biçiminde gönderilmiş olabilir) eşitleyici belirteç çiftinin yarısı olarak kullanılabilir. Bununla birlikte, kimliği doğrulanmamış kullanıcıların isabet ettiği oturum açma sayfalarını korumak için geçerli senaryolar vardır ve kimliği doğrulanmış kullanıcılar için bile güvenlik belirtecini her zaman oluşturup doğrulayarak XSRF'yi önleme mantığı daha basit hale getirildi. Ayrıca, bir alan belirtecinin bir saldırgan tarafından tehlikeye atılması durumunda, oturum belirtecini ayarlamak veya tahmin etmek saldırganın üstesinden gelmek için başka bir engel olacağından bazı ek koruma sağlar.

Geliştiriciler, tek bir etki alanında birden çok uygulama barındırıldığında dikkatli olmalıdır. Örneğin, example1.cloudapp.net ve example2.cloudapp.net farklı konaklar olsa da* .cloudapp.net etki alanı altındaki tüm konaklar arasında örtük bir güven ilişkisi vardır. Bu örtük güven ilişkisi, güvenilmeyen olabilecek konakların birbirlerinin tanımlama bilgilerini etkilemesine olanak tanır (AJAX isteklerini yöneten aynı kaynak ilkeleri HTTP tanımlama bilgileri için geçerli olmayabilir). ASP.NET Web Stack Çalışma Zamanı, kullanıcı adının alan belirtecine katıştırılmasıyla ilgili bazı azaltmalar sağlar, bu nedenle kötü amaçlı bir alt etki alanı oturum belirtecinin üzerine yazabilse bile kullanıcı için geçerli bir alan belirteci oluşturamaz. Ancak, böyle bir ortamda barındırıldığında yerleşik XSRF'yi önleme yordamları yine de oturum ele geçirme veya XSRF oturum açma işlemlerine karşı savunma yapamaz.

Anti-XSRF rutinleri şu anda tıklama kaçırma karşı savunma değil. Tıklama kaçırmaya karşı kendilerini savunmak isteyen uygulamalar, her yanıtla bir X-Frame-Options: SAMEORIGIN üst bilgisi göndererek bunu kolayca yapabilir. Bu üst bilgi son kullanılan tüm tarayıcılar tarafından desteklenir. Daha fazla bilgi için bkz. IE blogu, SDL blogu ve OWASP. ASP.NET Web Stack Çalışma Zamanı, gelecekteki bir sürümde MVC ve Web Sayfaları anti-XSRF yardımcılarının bu üst bilgiyi otomatik olarak ayarlayarak uygulamaların bu saldırıya karşı otomatik olarak korunmasını sağlayabilir.

Web geliştiricileri, sitelerinin XSS saldırılarına karşı savunmasız olmadığından emin olmalıdır. XSS saldırıları çok güçlü bir saldırıdır ve başarılı bir açık, XSRF saldırılarına karşı ASP.NET Web Stack Runtime savunmasını da bozabilir.

Bildirim

@LeviBroderick, ASP.NET güvenlik kodunun çoğunu bu bilgilerin çoğunu yazdı.