ASP.NET Core siteler arası Istek sahteciliği (XSRF/CSRF) saldırılarını önle

By fiyaz hasan, Rick Andersonve Steve Smith

Siteler arası istek sahteciliği (XSRF veya CSRF olarak da bilinir), kötü amaçlı bir Web uygulamasının, bir istemci tarayıcısı ile bu tarayıcıya güvenen bir Web uygulaması arasındaki etkileşimi etkileyebilecek Web 'de barındırılan uygulamalara karşı bir saldırıdır. Web tarayıcıları her bir Web sitesi isteğiyle otomatik olarak bazı kimlik doğrulama belirteçleri gönderdikleri için bu saldırılar mümkündür. Bu güvenlik düzeyi, tek tıklamayla saldırı veya oturum adı olarak da bilinir çünkü saldırı, kullanıcının önceden kimliği doğrulanmış oturumunun avantajlarından yararlanır.

CSRF saldırılarına bir örnek:

  1. Kullanıcı, www.good-banking-site.com Forms kimlik doğrulaması kullanarak oturum açar. Sunucu, kullanıcının kimliğini doğrular ve kimlik doğrulaması içeren bir yanıt yayınlar cookie . Site, geçerli bir kimlik doğrulamasıyla aldığı herhangi bir isteğe güvendiğinden, saldırıya karşı savunmasız olur cookie .

  2. Kullanıcı kötü amaçlı bir siteyi ziyaret ettiğinde www.bad-crook-site.com .

    Kötü amaçlı site, www.bad-crook-site.com aşağıdakine benzer BIR HTML formu içerir:

    <h1>Congratulations! You're a Winner!</h1>
    <form action="http://good-banking-site.com/api/account" method="post">
        <input type="hidden" name="Transaction" value="withdraw">
        <input type="hidden" name="Amount" value="1000000">
        <input type="submit" value="Click to collect your prize!">
    </form>
    

    Formun action kötü amaçlı siteye değil, güvenlik açığı bulunan siteye gönderdiğine dikkat edin. Bu, CSRF 'nin "siteler arası" parçasıdır.

  3. Kullanıcı Gönder düğmesini seçer. Tarayıcı isteği yapar ve cookie istenen etki alanı için kimlik doğrulamasını otomatik olarak ekler www.good-banking-site.com .

  4. İstek, www.good-banking-site.com kullanıcının kimlik doğrulama bağlamıyla sunucuda çalışır ve kimliği doğrulanmış bir kullanıcının gerçekleştirmesine izin verilen herhangi bir eylemi gerçekleştirebilir.

Kullanıcının formu göndermek için düğmeyi seçtiği senaryoya ek olarak, kötü amaçlı site şunları verebilir:

  • Formu otomatik olarak gönderen bir komut dosyası çalıştırın.
  • Form gönderimini bir AJAX isteği olarak gönderin.
  • Formu CSS kullanarak gizleyin.

Bu alternatif senaryolar, ilk olarak kötü amaçlı siteyi ziyaret eden kullanıcıdan herhangi bir eylem veya giriş gerektirmez.

HTTPS kullanmak CSRF saldırılarına engel olmaz. Kötü amaçlı site, https://www.good-banking-site.com/ güvenli olmayan bir istek gönderebilmesini mümkün olduğunca kolay bir şekilde gönderebilir.

Bazı saldırılar, GET isteklerine yanıt veren uç noktaları, bu durumda eylemi gerçekleştirmek için bir resim etiketi kullanılabilir. Bu saldırı biçimi, görüntülere izin veren ancak JavaScript 'ı engelleyen Forum sitelerinde yaygındır. Değişkenlerin veya kaynakların değiştirildiği, GET isteklerinde durumu değiştiren uygulamalar kötü niyetli saldırılara açıktır. Durumu değiştirme isteklerini güvenli olmayan GET istekleri. Bir GET isteğindeki durumu hiçbir şekilde değiştirmemek en iyi uygulamadır.

Şu nedenle kimlik doğrulama için kullanılan Web uygulamalarına CSRF saldırıları mümkündür cookie :

  • cookieBir Web uygulaması tarafından verilen tarayıcılar mağazası öğeleri.
  • Depolanan cookie cookie Kullanıcılar, kimliği doğrulanmış kullanıcılar için oturum içerir.
  • Tarayıcılar, cookie uygulama isteğinin tarayıcıdan oluşturulma şeklinden bağımsız olarak her istekte bir etki alanı ile ilişkili tüm s 'leri Web uygulamasına gönderir.

Ancak, CSRF saldırıları, ' ı kötüye ile sınırlı değildir cookie . Örneğin, temel ve Özet kimlik doğrulaması da savunmasız olacaktır. Bir Kullanıcı temel veya Özet kimlik doğrulamasıyla oturum açtıktan sonra, oturum sona erene kadar tarayıcı kimlik bilgilerini otomatik olarak gönderir † .

†Bu bağlamda oturum , kullanıcının kimlik doğrulaması sırasında istemci tarafı oturumu anlamına gelir. sunucu tarafı oturumları veya ASP.NET Core oturum ara yazılımıile ilgisi yoktur.

Kullanıcılar, önlemler alarak CSRF güvenlik açıklarına karşı koruma sağlayabilir:

  • Web Apps 'in kullanımı bittiğinde oturumunuzu kapatın.
  • cookieDüzenli aralıklarla tarayıcı öğeleri temizleyin.

Ancak, CSRF güvenlik açıkları son kullanıcıdan değil, Web uygulamasıyla ilgili bir sorundur.

Kimlik doğrulamasının temelleri

Cookietabanlı kimlik doğrulaması, popüler bir kimlik doğrulama biçimidir. Belirteç tabanlı kimlik doğrulama sistemleri, özellikle tek sayfalı uygulamalar (maça 'Lar) için popülerlik olarak büyüyordur.

Bir Kullanıcı Kullanıcı adını ve parolasını kullanarak kimliğini doğruladığında, kimlik doğrulama ve yetkilendirme için kullanılabilecek bir kimlik doğrulama bileti içeren bir belirteç verilirler. Belirteç, cookie istemcinin yaptığı her istekte eşlik eden bir olarak depolanır. Bu işlemi oluşturmak ve doğrulamak cookie , Cookie kimlik doğrulama ara yazılımı tarafından gerçekleştirilir. Ara yazılım , bir Kullanıcı sorumlusunu şifreli olarak serileştirir cookie . Sonraki isteklerde, ara yazılım öğesini doğrular cookie , sorumluyu yeniden oluşturur ve sorumluyu Kullanıcı özelliğine atar.

Belirteç tabanlı kimlik doğrulaması

Bir kullanıcının kimliği doğrulandığında, bunlar bir belirteç (antibir belirteç değil) olarak verilirler. Belirteç, talepler formundaki Kullanıcı bilgilerini veya uygulamayı uygulamada tutulan Kullanıcı durumuna işaret eden bir başvuru belirtecini içerir. Bir kullanıcı kimlik doğrulaması gerektiren bir kaynağa erişmeyi denediğinde, belirteç, taşıyıcı belirteç biçiminde ek bir yetkilendirme üstbilgisiyle uygulamaya gönderilir. Bu, uygulamanın durum bilgisiz olmasını sağlar. Sonraki her istekte, belirteç sunucu tarafı doğrulama isteğine geçirilir. Bu belirteç şifrelenmez; kodlandı. Sunucusunda, bilgilerine erişmek için belirtecin kodu çözülür. Sonraki isteklere belirteç göndermek için, belirteci tarayıcının yerel deposunda depolayın. Belirteç tarayıcının yerel deposunda depolanıyorsa, CSRF güvenlik açığıyla ilgilenmeyin. CSRF, belirteç bir içinde depolandığında sorun teşkil ediyor cookie . daha fazla bilgi için bkz. SPA kod örneği GitHub, iki cookie s ekleme.

Tek bir etki alanında barındırılan birden çok uygulama

Paylaşılan barındırma ortamları, oturum ele geçirme, oturum açma CSRF ve diğer saldırılara karşı savunmasız kalır.

example1.contoso.netVe example2.contoso.net farklı konaklar olsa da, etki alanı altındaki konaklar arasında örtülü bir güven ilişkisi vardır *.contoso.net . Bu örtük güven ilişkisi, güvenilir olmayan ana bilgisayarların birbirini etkilemesine olanak tanır cookie (AJAX isteklerini yöneten aynı kaynak ILKELERI http s için de geçerlidir cookie ).

cookieAynı etki alanı üzerinde barındırılan uygulamalar arasında güvenilir bir şekilde yararlanan saldırılar, etki alanları paylaşılmayabilir. Her uygulama kendi etki alanında barındırıldığı zaman, cookie açıktan yararlanılabilmesi için örtük güven ilişkisi yoktur.

ASP.NET Core antiforgery yapılandırması

Uyarı

ASP.NET Core, ASP.NET Core veri korumasınıkullanarak antiforgery uygular. Veri koruma yığınının bir sunucu grubunda çalışacak şekilde yapılandırılması gerekir. Daha fazla bilgi için bkz. veri korumayı yapılandırma .

Aşağıdaki API 'lerden biri çağrıldığında, antiforgery ara yazılımı bağımlılık ekleme kapsayıcısına eklenir Startup.ConfigureServices :

' De çağrıldığında, antiforgery ara yazılımı bağımlılık ekleme kapsayıcısına eklenir AddMvcStartup.ConfigureServices

ASP.NET Core 2,0 veya sonraki sürümlerde formtaghelper , antiforgery belirteçlerini HTML form öğelerine çıkartır. Bir dosyada bulunan aşağıdaki biçimlendirme, Razor antiforgery belirteçlerini otomatik olarak oluşturur:

<form method="post">
    ...
</form>

Benzer şekilde, ıhtmlhelper. BeginForm , formun yöntemi get değilse, varsayılan olarak antiforgery belirteçleri oluşturur.

HTML form öğeleri için antiforgery belirteçlerinin otomatik olarak oluşturulması, <form> etiketi method="post" özniteliği içerdiğinde ve aşağıdakilerden biri doğru olduğunda gerçekleşir:

  • Action özniteliği boş ( action="" ).
  • Eylem özniteliği sağlanmadı ( <form method="post"> ).

HTML form öğeleri için antiforgery belirteçlerinin otomatik nesli devre dışı bırakılabilir:

  • Özniteliği ile antiforgery belirteçlerini açıkça devre dışı bırakın asp-antiforgery :

    <form method="post" asp-antiforgery="false">
        ...
    </form>
    
  • Form öğesi etiket Yardımcısı! geri alma simgesi kullanılarak etiket yardımcılarını kabuletmedi:

    <!form method="post">
        ...
    </!form>
    
  • Görünümden ' i kaldırın FormTagHelper . , FormTagHelper Şu yönergeyi görünüme ekleyerek bir görünümden kaldırılabilir Razor :

    @removeTagHelper Microsoft.AspNetCore.Mvc.TagHelpers.FormTagHelper, Microsoft.AspNetCore.Mvc.TagHelpers
    

Not

Razor Sayfalar , XSRF/CSRF 'den otomatik olarak korunur. Daha fazla bilgi için bkz. XSRF/CSRF ve Razor Sayfalar.

CSRF saldırılarına karşı savunma için en yaygın yaklaşım, Eşitleyici belirteç deseninin (STP) kullanılması. Kullanıcı form verileri içeren bir sayfa istediğinde STP kullanılır:

  1. Sunucu, geçerli kullanıcının kimliğiyle ilişkili bir belirteci istemciye gönderir.
  2. İstemci doğrulama için belirteci sunucuya geri gönderir.
  3. Sunucu kimliği doğrulanmış kullanıcının kimliğiyle eşleşmeyen bir belirteç alırsa istek reddedilir.

Belirteç benzersizdir ve tahmin edilemez. Belirteç Ayrıca, bir dizi isteğin doğru sıralamasını sağlamak için de kullanılabilir (örneğin,: sayfa 1 > sayfa 2 > sayfa 3). ASP.NET Core MVC ve sayfa şablonlarındaki tüm formlar, Razor antiforgery belirteçleri oluşturur. Aşağıdaki görünüm örnekleri, antiforgery belirteçleri oluşturur:

<form asp-controller="Todo" asp-action="Create" method="post">
    ...
</form>

@using (Html.BeginForm("Create", "Todo"))
{
    ...
}

<form>HTML Yardımcısı Ile etiket yardımcıları kullanmadan bir öğeye açık bir şekilde antiforgery belirteci ekleyin @Html.AntiForgeryToken :

<form action="/" method="post">
    @Html.AntiForgeryToken()
</form>

yukarıdaki durumların her birinde, ASP.NET Core şuna benzer bir gizli form alanı ekler:

<input name="__RequestVerificationToken" type="hidden" value="CfDJ8NrAkS ... s2-m9Yw">

ASP.NET Core, antiforgery belirteçleriyle çalışmak için üç filtre içerir:

Antiforgery seçenekleri

İçindeki antiforgery seçeneklerini özelleştirin Startup.ConfigureServices :

services.AddAntiforgery(options => 
{
    // Set Cookie properties using CookieBuilder properties†.
    options.FormFieldName = "AntiforgeryFieldname";
    options.HeaderName = "X-CSRF-TOKEN-HEADERNAME";
    options.SuppressXFrameOptionsHeader = false;
});

Cookie Cookie Builder sınıfının özelliklerini kullanarak antiforgery özelliklerini ayarlayın.

Seçenek Açıklama
Cookie Antiforgery 'leri oluşturmak için kullanılan ayarları belirler cookie .
Form alanadı Görünümlerde antiforgery belirteçlerini işlemek için antiforgery sistemi tarafından kullanılan gizli form alanının adı.
HeaderName Antiforgery sistemi tarafından kullanılan üstbilginin adı. Varsa null , sistem yalnızca form verilerini dikkate alır.
SuppressXFrameOptionsHeader Üstbilginin oluşturulup oluşturulmayacağını bastırıp gizlenmeyeceğini belirtir X-Frame-Options . Varsayılan olarak, üst bilgi "SAMEORIGIN" değeri ile oluşturulur. Varsayılan olarak olur false .
services.AddAntiforgery(options => 
{
    options.CookieDomain = "contoso.com";
    options.CookieName = "X-CSRF-TOKEN-COOKIENAME";
    options.CookiePath = "Path";
    options.FormFieldName = "AntiforgeryFieldname";
    options.HeaderName = "X-CSRF-TOKEN-HEADERNAME";
    options.RequireSsl = false;
    options.SuppressXFrameOptionsHeader = false;
});
Seçenek Açıklama
Cookie Antiforgery 'leri oluşturmak için kullanılan ayarları belirler cookie .
CookieEtki alanı Öğesinin etki alanı cookie . Varsayılan olarak olur null . Bu özellik artık kullanılmıyor ve gelecek bir sürümde kaldırılacak. Önerilen alternatif şunlardır Cookie . Alanını.
CookieName cookie öğesinin adı. Ayarlanmamışsa, sistem varsayılan Cookie ön eki (") ile başlayan benzersiz bir ad oluşturur. AspNetCore. Antiforgery. "). Bu özellik artık kullanılmıyor ve gelecek bir sürümde kaldırılacak. Önerilen alternatif şunlardır Cookie . Ada.
CookieYolun Üzerinde ayarlanan yol cookie . Bu özellik artık kullanılmıyor ve gelecek bir sürümde kaldırılacak. Önerilen alternatif şunlardır Cookie . Yolun.
Form alanadı Görünümlerde antiforgery belirteçlerini işlemek için antiforgery sistemi tarafından kullanılan gizli form alanının adı.
HeaderName Antiforgery sistemi tarafından kullanılan üstbilginin adı. Varsa null , sistem yalnızca form verilerini dikkate alır.
RequireSsl Antiforgery sistemi için HTTPS 'nin gerekli olup olmadığını belirtir. true, Https olmayan istekler başarısız olur. Varsayılan olarak olur false . Bu özellik artık kullanılmıyor ve gelecek bir sürümde kaldırılacak. Önerilen alternatif ayarlanır Cookie . SecurePolicy.
SuppressXFrameOptionsHeader Üstbilginin oluşturulup oluşturulmayacağını bastırıp gizlenmeyeceğini belirtir X-Frame-Options . Varsayılan olarak, üst bilgi "SAMEORIGIN" değeri ile oluşturulur. Varsayılan olarak olur false .

Daha fazla bilgi için bkz. Cookie authenticationoptions.

Iantiforgery ile antiforgery özelliklerini yapılandırma

Iantiforgery , antiforgery özelliklerini YAPıLANDıRMAK için API sağlar. IAntiforgery , Configure sınıfının yönteminde istenebilir Startup . aşağıdaki örnek, bir antiforgery belirteci oluşturmak ve yanıt olarak cookie (bu konunun ilerleyen kısımlarında açıklanan varsayılan Angular adlandırma kuralını kullanarak) olarak yanıtta göndermek için uygulamanın giriş sayfasından ara yazılım kullanır:

public void Configure(IApplicationBuilder app, IAntiforgery antiforgery)
{
    app.Use(next => context =>
    {
        string path = context.Request.Path.Value;

        if (
            string.Equals(path, "/", StringComparison.OrdinalIgnoreCase) ||
            string.Equals(path, "/index.html", StringComparison.OrdinalIgnoreCase))
        {
            // The request token can be sent as a JavaScript-readable cookie, 
            // and Angular uses it by default.
            var tokens = antiforgery.GetAndStoreTokens(context);
            context.Response.Cookies.Append("XSRF-TOKEN", tokens.RequestToken, 
                new CookieOptions() { HttpOnly = false });
        }

        return next(context);
    });
}

Antiforgery doğrulaması gerektir

Validateantiforgeritoken , tek bir eyleme, denetleyiciye veya küresel olarak uygulanabilen bir eylem filtresidir. Bu filtre uygulanmış eylemlere yapılan istekler, istek geçerli bir antiforgery belirteci içermiyorsa engellenir.

[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> RemoveLogin(RemoveLoginViewModel account)
{
    ManageMessageId? message = ManageMessageId.Error;
    var user = await GetCurrentUserAsync();

    if (user != null)
    {
        var result = 
            await _userManager.RemoveLoginAsync(
                user, account.LoginProvider, account.ProviderKey);

        if (result.Succeeded)
        {
            await _signInManager.SignInAsync(user, isPersistent: false);
            message = ManageMessageId.RemoveLoginSuccess;
        }
    }

    return RedirectToAction(nameof(ManageLogins), new { Message = message });
}

ValidateAntiForgeryTokenÖznitelik, http get istekleri de dahil olmak üzere, işaret eden eylem yöntemlerine istek için bir belirteç gerektirir. Öznitelik, ValidateAntiForgeryToken uygulamanın denetleyicileri arasında uygulanırsa, özniteliğiyle geçersiz kılınabilir IgnoreAntiforgeryToken .

Not

ASP.NET Core, istekleri otomatik olarak almak için antiforgery belirteçleri eklemeyi desteklemez.

Yalnızca güvenli olmayan HTTP metotları için antiforgery belirteçlerini otomatik olarak doğrula

ASP.NET Core uygulamalar güvenli HTTP yöntemleri (GET, HEAD, OPTIONS ve TRACE) için antiforgery belirteçleri oluşturmaz. Özniteliği genel olarak uygulamak ValidateAntiForgeryToken ve ardından özniteliklerle geçersiz kılmak yerine IgnoreAntiforgeryToken , oto Validateantiforgerontoken özniteliği kullanılabilir. Bu öznitelik, özniteliğiyle aynı şekilde çalışır ValidateAntiForgeryToken , ancak AŞAĞıDAKI http yöntemlerini kullanarak yapılan isteklere belirteç gerektirmez:

  • GET
  • HEAD
  • SEÇENEKLER
  • TRACE

AutoValidateAntiforgeryTokenAPI olmayan senaryolara yönelik olarak kullanılması önerilir. Bu, varsayılan olarak POST eylemlerinin korunmasını sağlar. Diğer bir deyişle, ValidateAntiForgeryToken tek tek eylem yöntemlerine uygulanmamışsa, varsayılan olarak antiforgery belirteçlerini yok saymanız gerekir. Bu senaryoda, bir POST eylemi yönteminin korumasız olarak bırakılması, uygulamanın CSRF saldırılarına karşı savunmasız bırakılması daha yüksektir. Tüm gönderimler, antiforgery belirtecini göndermelidir.

API 'lerin, belirtecin parçası olmayan bir otomatik mekanizması yoktur cookie . Uygulama, büyük olasılıkla istemci kodu uygulamasına bağlıdır. Bazı örnekler aşağıda gösterilmiştir:

Sınıf düzeyi örnek:

[Authorize]
[AutoValidateAntiforgeryToken]
public class ManageController : Controller
{

Genel örnek:

servislere. AddMvc (Options => seçenekleri. Filters. Add (New, oto Validateantiforgeryıtokenattribute ()));

services.AddControllersWithViews(options =>
    options.Filters.Add(new AutoValidateAntiforgeryTokenAttribute()));

Küresel veya denetleyici antiforgery özniteliklerini geçersiz kıl

Ignoreantiforgeri Token filtresi, belirli bir eyleme (veya denetleyiciye) yönelik bir antiforgery belirtecinin gereksinimini ortadan kaldırmak için kullanılır. Uygulandığında, bu filtre ValidateAntiForgeryToken ve AutoValidateAntiforgeryToken daha yüksek düzeyde (genel olarak veya bir denetleyicide) belirtilen filtreleri geçersiz kılar.

[Authorize]
[AutoValidateAntiforgeryToken]
public class ManageController : Controller
{
    [HttpPost]
    [IgnoreAntiforgeryToken]
    public async Task<IActionResult> DoSomethingSafe(SomeViewModel model)
    {
        // no antiforgery token required
    }
}

Kimlik doğrulamasından sonra belirteçleri Yenile

Kullanıcının kimliği doğrulandıktan sonra, Kullanıcı bir görünüm veya sayfalar sayfasına yönlendirildikten sonra belirteçlerin yenilenmesi gerekir Razor .

JavaScript, AJAX ve maça

Geleneksel HTML tabanlı uygulamalarda, antiforgery belirteçleri gizli form alanları kullanılarak sunucuya geçirilir. Modern JavaScript tabanlı uygulamalar ve maça 'Lar, programlama yoluyla birçok istek yapılır. Bu AJAX istekleri, belirteci göndermek için diğer teknikleri (istek üstbilgileri veya cookie öğeleri gibi) kullanabilir.

cookieS kimlik doğrulama belirteçlerini depolamak ve SUNUCUDAKI API isteklerinin kimliğini doğrulamak için kullanılıyorsa, CSRF olası bir sorundur. Yerel depolama, belirteci depolamak için kullanılıyorsa, yerel depolama alanındaki değerler her istek ile sunucuya otomatik olarak gönderilmediğinden CSRF güvenlik açığı azaltılabilir. Bu nedenle, istemci üzerinde antiforgery belirtecini depolamak ve belirteci istek üst bilgisi olarak göndermek için yerel depolama kullanmak önerilen bir yaklaşımdır.

JavaScript

Görünümler ile JavaScript kullanarak, belirteç, görünümün içinden bir hizmet kullanılarak oluşturulabilir. Microsoft. AspNetCore. antiforgery. ıantiforgery hizmetini görünüme ekleyin ve Getandstorebelirteçleriniçağırın:

@{
    ViewData["Title"] = "AJAX Demo";
}
@inject Microsoft.AspNetCore.Antiforgery.IAntiforgery Xsrf
@functions{
    public string GetAntiXsrfRequestToken()
    {
        return Xsrf.GetAndStoreTokens(Context).RequestToken;
    }
}

<input type="hidden" id="RequestVerificationToken" 
       name="RequestVerificationToken" value="@GetAntiXsrfRequestToken()">

<h2>@ViewData["Title"].</h2>
<h3>@ViewData["Message"]</h3>

<div class="row">
    <p><input type="button" id="antiforgery" value="Antiforgery"></p>
    <script>
        var xhttp = new XMLHttpRequest();
        xhttp.onreadystatechange = function() {
            if (xhttp.readyState == XMLHttpRequest.DONE) {
                if (xhttp.status == 200) {
                    alert(xhttp.responseText);
                } else {
                    alert('There was an error processing the AJAX request.');
                }
            }
        };

        document.addEventListener('DOMContentLoaded', function() {
            document.getElementById("antiforgery").onclick = function () {
                xhttp.open('POST', '@Url.Action("Antiforgery", "Home")', true);
                xhttp.setRequestHeader("RequestVerificationToken", 
                    document.getElementById('RequestVerificationToken').value);
                xhttp.send();
            }
        });
    </script>
</div>

Bu yaklaşım, sunucudan ayarları doğrudan veya istemciden okurken doğrudan anlaşma gereksinimini ortadan kaldırır cookie .

Önceki örnekte, AJAX GÖNDERI üst bilgisinin gizli alan değerini okumak için JavaScript kullanılmaktadır.

JavaScript Ayrıca, içindeki belirteçlere erişebilir cookie ve belirtecinin, cookie belirtecin değeri ile bir üst bilgi oluşturmak için içeriğini kullanabilir.

context.Response.Cookies.Append("CSRF-TOKEN", tokens.RequestToken, 
    new Microsoft.AspNetCore.Http.CookieOptions { HttpOnly = false });

Çağrılan bir üst bilgide belirteç göndermek için komut dosyası isteklerinin kabul edilmediği varsayılarak X-CSRF-TOKEN , bir üst bilgiyi aramak için antiforgery hizmetini yapılandırın X-CSRF-TOKEN :

services.AddAntiforgery(options => options.HeaderName = "X-CSRF-TOKEN");

Aşağıdaki örnek, uygun üst bilgiyle bir AJAX isteği oluşturmak için JavaScript kullanır:

function getCookie(cname) {
    var name = cname + "=";
    var decodedCookie = decodeURIComponent(document.cookie);
    var ca = decodedCookie.split(';');
    for (var i = 0; i < ca.length; i++) {
        var c = ca[i];
        while (c.charAt(0) === ' ') {
            c = c.substring(1);
        }
        if (c.indexOf(name) === 0) {
            return c.substring(name.length, c.length);
        }
    }
    return "";
}

var csrfToken = getCookie("CSRF-TOKEN");

var xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function () {
    if (xhttp.readyState === XMLHttpRequest.DONE) {
        if (xhttp.status === 204) {
            alert('Todo item is created successfully.');
        } else {
            alert('There was an error processing the AJAX request.');
        }
    }
};
xhttp.open('POST', '/api/items', true);
xhttp.setRequestHeader("Content-type", "application/json");
xhttp.setRequestHeader("X-CSRF-TOKEN", csrfToken);
xhttp.send(JSON.stringify({ "name": "Learn C#" }));

AngularJS

AngularJS, CSRF'yi ele alan bir kural kullanır. Sunucu adıyla bir cookie gönderirse, AngularJS hizmeti sunucuya istek gönderirken değeri üst XSRF-TOKEN $http cookie bilgiye ekler. Bu işlem otomatiktir. Üst bilginin istemcide açıkça ayarlanmış olması gerekmez. Üst bilgi adı: X-XSRF-TOKEN . Sunucu bu üst bilgileri algılamalı ve içeriğini doğrulamalı.

Uygulama ASP.NET Core api'nizin bu kuralla çalışması için:

  • Adlı bir içinde belirteç sağlamak için cookie uygulamanızı XSRF-TOKEN yapılandırma.
  • adlı bir üst bilgi için sahtecilik önleme hizmetini X-XSRF-TOKEN yapılandırma.
public void Configure(IApplicationBuilder app, IAntiforgery antiforgery)
{
    app.Use(next => context =>
    {
        string path = context.Request.Path.Value;

        if (
            string.Equals(path, "/", StringComparison.OrdinalIgnoreCase) ||
            string.Equals(path, "/index.html", StringComparison.OrdinalIgnoreCase))
        {
            // The request token can be sent as a JavaScript-readable cookie, 
            // and Angular uses it by default.
            var tokens = antiforgery.GetAndStoreTokens(context);
            context.Response.Cookies.Append("XSRF-TOKEN", tokens.RequestToken, 
                new CookieOptions() { HttpOnly = false });
        }

        return next(context);
    });
}

public void ConfigureServices(IServiceCollection services)
{
    // Angular's default header name for sending the XSRF token.
    services.AddAntiforgery(options => options.HeaderName = "X-XSRF-TOKEN");
}

Örnek kodu görüntüleme veya indirme ( nasılindir)

Windows kimlik doğrulaması ve sahtecilik cookie önleme

Uygulama Windows kimlik doğrulaması kullanılırken, uygulama uç noktalarının csRF saldırılarına karşı aynı şekilde korunması cookie gerekir. Tarayıcı kimlik doğrulama bağlamını sunucuya örtülü olarak gönderir, bu nedenle uç noktaların CSRF saldırılarına karşı korunması gerekir.

Sahteciyi genişletme

IAntiForgeryAdditionalDataProvider türü, geliştiricilerin her belirteçte ek verileri yuvarlatarak CSRF'den koruma sisteminin davranışını genişletmesini sağlar. GetAdditionalData yöntemi, her alan belirteci üretilende çağrılır ve dönüş değeri oluşturulan belirtecin içine katıştırıldı. Bir uygulayıcı bir zaman damgası, bir nonce veya başka bir değer dönüp belirteç doğrulandıktan sonra bu verileri doğrulamak için ValidateAdditionalData çağrısında bulunur. İstemcinin kullanıcı adı, oluşturulan belirteçlere zaten eklenmiş durumdadır, bu nedenle bu bilgileri dahil etmek zorunda değildir. Belirteç ek veriler içerir ancak IAntiForgeryAdditionalDataProvider yapılandırılmamışsa ek veriler doğrulanmaz.

Ek kaynaklar