ASP.NET Core'da Siteler Arası İstek Sahteciliği (XSRF/CSRF) saldırılarını önleme

Tarafından Fiyaz Hasan ve Rick Anderson

Siteler arası istek sahteciliği, kötü amaçlı bir web uygulamasının bir istemci tarayıcı ile bu tarayıcıya güvenen bir web uygulaması arasındaki etkileşimi etkilediği, web'de barındırılan uygulamalara yönelik bir saldırıdır. Bu saldırılar mümkündür çünkü web tarayıcıları bir web sitesine her istekle birlikte bazı kimlik doğrulama belirteçleri türlerini otomatik olarak gönderir. Saldırı, kullanıcının daha önce kimliği doğrulanmış oturumundan yararlandığından, bu açıklardan yararlanma biçimi tek tıklamayla saldırı veya oturum sürme olarak da bilinir. Siteler arası istek sahteciliği, XSRF veya CSRF olarak da bilinir.

CSRF saldırısı örneği:

1. Bir kullanıcı form kimlik doğrulamasını kullanarak www.good-banking-site.example.com sitesine oturum açar. Sunucu kullanıcının kimliğini doğrular ve kimlik doğrulaması cookieiçeren bir yanıt gönderir. Site, geçerli bir kimlik doğrulaması cookieile aldığı tüm isteklere güvendiği için saldırıya açık durumdadır.

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

   Kötü amaçlı site, www.bad-crook-site.example.comaşağıdaki örneğe benzer bir HTML formu içerir:

   <h1>Congratulations! You're a Winner!</h1>
   <form action="https://www.good-banking-site.example.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önderildiğini fark edin. Bu, CSRF'nin "siteler arası" bölümüdür.

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

4. İstek, kullanıcının kimlik doğrulama bağlamıyla sunucuda çalışır www.good-banking-site.example.com ve kimliği doğrulanmış bir kullanıcının gerçekleştirmesine izin verilen tüm eylemleri 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ı yapabilir:

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

Bu alternatif senaryolar, başlangıçta kötü amaçlı siteyi ziyaret etmekten başka kullanıcıdan herhangi bir eylem veya giriş gerektirmez.

HTTPS kullanmak CSRF saldırısını engellemez. Kötü amaçlı site, güvenli olmayan bir istek gönderebildiği kadar kolay bir şekilde https://www.good-banking-site.example.com/ isteği de gönderebilir.

Bazı saldırılar GET isteklerine yanıt veren uç noktaları hedefler ve bu durumda eylemi gerçekleştirmek için bir görüntü etiketi kullanılabilir. Bu saldırı biçimi, görüntülere izin veren ancak JavaScript'i 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ü amaçlı saldırılara karşı savunmasızdır. Durumu değiştiren GET istekleri güvenli değildir. Get isteğinde hiçbir zaman durumu değiştirmemek en iyi yöntemdir.

Kimlik doğrulaması için tanımlama bilgileri kullanan web uygulamalarına CSRF saldırıları mümkündür çünkü:

• Tarayıcılar, web uygulaması tarafından verilen çerezleri depolar.
• Depolanan tanımlama bilgileri, kimliği doğrulanmış kullanıcılar için oturum tanımlama bilgilerini içerir.
• Tarayıcılar, bir etki alanıyla ilişkili tüm tanımlama bilgilerini, uygulama isteğinin tarayıcıda nasıl oluşturulduğundan bağımsız olarak her istekte web uygulamasına gönderir.

Ancak CSRF saldırıları, tanımlama bilgilerini kötüye kullanmakla sınırlı değildir. Örneğin, Temel ve Özet kimlik doğrulaması da savunmasızdır. Kullanıcı Temel veya Özet kimlik doğrulamasıyla oturum açtığında, oturum bitene kadar tarayıcı kimlik bilgilerini otomatik olarak gönderir.

Bu bağlamda oturum, kullanıcının kimliğinin doğrulandığı istemci tarafı oturumuna başvurur. Sunucu tarafı oturumlarıyla veya ASP.NET Core oturum ara yazılımıyla ilgisizdir.

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

• Web uygulamalarını kullanmayı bitirdiğinizde oturumunu kapatın.
• Tarayıcı tanımlama bilgilerini düzenli aralıklarla temizleyin.

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

Kimlik doğrulamasının temelleri

Cookietabanlı kimlik doğrulaması, popüler bir kimlik doğrulaması biçimidir. Özellikle Tek Sayfalı Uygulamalar (SPA' lar) için belirteç tabanlı kimlik doğrulama sistemlerinin popülerliği artmaktadır.

Cookietabanlı kimlik doğrulaması

Bir kişi kullanıcı adı ve parolasını kullanarak kimlik doğrulaması yaptığında, kendisine kimlik doğrulama bileti içeren bir belirteç verilir. Belirteç, kimlik doğrulaması ve yetkilendirme için kullanılabilir. Belirteç, istemcinin yaptığı her istekle gönderilen bir cookie olarak depolanır. Bu cookie’ın oluşturulması ve doğrulanması, cookie kimlik doğrulama ara yazılımı kullanılarak gerçekleştirilir. Arayazılım, bir kullanıcı kimliğini şifrelenmiş bir olarak seri hale getirmektedir. Sonraki isteklerde ara yazılım cookie'yi doğrular, kimliği yeniden oluşturur ve kimliği HttpContext.User özelliğine atar.

Belirteç tabanlı kimlik doğrulaması

Bir kullanıcının kimliği doğrulandığında, ona bir belirteç verilir (bir sahteciliğe karşı koruma belirteci değil). Belirteç, haklar biçiminde kullanıcı bilgilerini veya uygulamada tutulan kullanıcı durumuna işaret eden bir referans belirteci içerir. Kullanıcı kimlik doğrulaması gerektiren bir kaynağa erişmeye çalıştığında belirteç, Taşıyıcı belirteci biçiminde ek yetkilendirme üst bilgisi ile uygulamaya gönderilir. Bu yaklaşım uygulamayı durumsuz hale getirir. Sonraki her istekte, belirteç sunucu tarafı doğrulama isteğine geçirilir. Bu belirteç şifrelenmez; kodlanır. Sunucuda belirtecin kodu bilgilerine erişmek için çözülmektedir. Sonraki isteklerde belirteci göndermek için belirteci tarayıcının yerel depolama alanında depolayın. Jetonu tarayıcı yerel depolama alanına yerleştirmek, geri almak ve taşıyıcı jeton olarak kullanmak, CSRF saldırılarına karşı koruma sağlar. Ancak, uygulama XSS aracılığıyla betik eklemeye veya güvenliği aşılmış bir dış JavaScript dosyasına karşı savunmasız olursa, bir siber saldırı yerel depolama alanından herhangi bir değeri alabilir ve kendilerine gönderebilir. ASP.NET Core varsayılan olarak değişkenlerden gelen tüm sunucu tarafı çıkışlarını kodlayarak XSS riskini azaltır. Html.Raw veya özel kodu güvenilmeyen girişle kullanarak bu davranışı geçersiz kılarsanız XSS riskini artırabilirsiniz.

Belirteç tarayıcının yerel depolama alanında depolanıyorsa CSRF güvenlik açığı konusunda endişelenmeyin. CSRF, belirtecin bir cookie içinde depolandığı durumlarda sorundur. Daha fazla bilgi için GitHub konusuna bakın: SPA kodu örneği iki çerez ekler.

Bir alan adında barındırılan birden fazla uygulama

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

ve example1.contoso.net farklı konaklar olsa example2.contoso.net da, etki alanı altındaki *.contoso.net konaklar arasında örtük bir güven ilişkisi vardır. Bu örtük güven ilişkisi, potansiyel olarak güvenilmeyen konakların birbirlerinin çerezlerini etkilemesine olanak tanır (AJAX isteklerini yöneten aynı kaynak ilkeleri HTTP çerezleri için geçerli olmayabilir).

Aynı etki alanında barındırılan uygulamalar arasındaki güvenilir tanımlama bilgilerini istismar eden saldırılar, etki alanlarının paylaşılmamasıyla önlenebilir. Her bir uygulama kendi alanında barındırıldığında, istismar edilecek örtük bir güven ilişkisi yoktur.

ASP.NET Core'da Sahtecilikle Mücadele

Uyarı

ASP.NET Core, ASP.NET Core Veri Koruması kullanarak kötü amaçlı yazılımdan koruma uygular. Veri koruma yığını bir sunucu grubunda çalışacak şekilde yapılandırılmalıdır. Daha fazla bilgi için bkz . Veri korumasını yapılandırma.

Aşağıdaki API'lerden biri çağrıldığında, sahtecilik karşıtı ara yazılım bağımlılık enjeksiyonu konteynerine eklenir:

• AddMvc
• MapRazorPages
• MapControllerRoute
• AddRazorComponents

Daha fazla bilgi için Minimal API'lerle Sahteciliğe Karşı Koruma bölümüne bakın.

FormTagHelper, HTML form öğelerine sahtecilik önleme belirteçleri ekler. Bir dosyada Razor aşağıdaki işaretleme otomatik olarak kötü amaçlı yazılımdan koruma belirteçleri oluşturur:

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

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

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

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

HTML form öğeleri için kimlik doğrulama belirteçlerinin otomatik oluşturulması devre dışı bırakılabilir.

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

  <form method="post" asp-antiforgery="false">
      <!-- ... -->
  </form>
  

• Form öğesi Etiket Yardımcısı ! geri çevirme simgesi kullanılarak Etiket Yardımcıları'nı geri çevirmiş olur:

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

• FormTagHelper öğesini görünümden kaldırın. Bir görünümden FormTagHelper kaldırılabilir, bunun için Razor görünümüne aşağıdaki yönerge eklenmelidir.

  @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şı korumanın en yaygın yaklaşımı Eşitleyici Belirteci Deseni'ni (STP) kullanmaktır. Kullanıcı form verilerini içeren bir sayfa istediğinde STP kullanılır:

1. Sunucu, geçerli kullanıcının kimliğiyle ilişkilendirilmiş 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 öngörülemez. Belirteç, bir dizi isteğin düzgün sıralanmasını sağlamak için de kullanılabilir (örneğin, istek sırasının sağlanması: sayfa 1 > sayfa 2 > sayfa 3). ASP.NET Core MVC ve Razor Pages şablonlarındaki tüm formlar, sahtecilik önleyici jetonlar oluşturur. Aşağıdaki görünüm örnekleri çifti, kötü amaçlı yazılımdan koruma belirteçleri oluşturur:

<form asp-action="Index" asp-controller="Home" method="post">
    <!-- ... -->
</form>

@using (Html.BeginForm("Index", "Home"))
{
    <!-- ... -->
}

HTML yardımcısı <form> ile Etiket Yardımcıları kullanmadan bir @Html.AntiForgeryToken öğesine açıkça bir sahtecilik karşıtı belirteç ekleyin.

<form asp-action="Index" asp-controller="Home" method="post">
    @Html.AntiForgeryToken()

    <!-- ... -->
</form>

Önceki durumların her birinde, ASP.NET Core aşağıdaki örneğe benzer bir gizli form alanı ekler:

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

ASP.NET Core, kötü amaçlı yazılımdan koruma belirteçleriyle çalışmak için üç filtre içerir:

• ValidateAntiForgeryToken
• AutoValidateAntiforgeryToken
• SahtecilikKarşıtıTokenYoksay

AddControllers ile antiforgery

ÇağrıAddControllersasla sahteciliğe karşı koruma belirteçlerini etkinleştirmez. AddControllersWithViews yerleşik sahtecilik önleme belirteci desteğine sahip olmak için çağrılmalıdır.

Birden çok tarayıcı sekmesi ve Eşitleyici Belirteci Deseni

Farklı kullanıcılar olarak oturum açan veya anonim olarak oturum açan birden çok sekme desteklenmez.

AntiforgeryOptions ile sahtecilik önleyiciyi yapılandırın

Uygulamanın AntiforgeryOptions dosyasını Program içinde özelleştirin.

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

Aşağıdaki tabloda gösterildiği gibi cookie sınıfının özelliklerini kullanarak, sahteciliği önleme CookieBuilder özelliklerini ayarlayın.

Seçenek	Açıklama
Cookie	Sahtecilik karşıtı tanımlama bilgilerini oluşturmak için kullanılan ayarları belirler.
FormFieldName	Antiforgery sistemi tarafından görünümlerde sahteciliğe karşı belirteçleri oluşturmak için kullanılan gizli form alanının adı.
HeaderName	Sahtecilik önleme sistemi tarafından kullanılan başlığın adı. ise null, sistem yalnızca form verilerini dikkate alır.
SuppressXFrameOptionsHeader	Başlığın oluşturulmasının engellenip gizlenmeyeceğini X-Frame-Options belirtir. Başlık varsayılan olarak "SAMEORIGIN" değeriyle oluşturulur. Varsayılan değer false olarak ayarlanır.

Bazı tarayıcılar güvenli olmayan uç noktaların 'güvenli' bayrağı olan tanımlama bilgilerini ayarlamasına veya 'güvenli' bayrağı ayarlanmış tanımlama bilgilerinin üzerine yazmasına izin vermez (daha fazla bilgi için bkz. Güvenli olmayan kaynaklardan 'güvenli' tanımlama bilgilerinin değiştirilmesini kaldırma). Güvenli ve güvensiz uç noktaların karıştırılması uygulamalarda yaygın bir senaryo olduğundan, ASP.NET Core, sahtecilik karşıtı gibi bazı tanımlama bilgilerindeki güvenli ilke kısıtlamasını, cookie'nin cookie'sini SecurePolicy olarak ayarlayarak gevşetir. Kötü amaçlı bir kullanıcı bir sahteciliğe karşı cookiekoruma çalsa bile, genellikle bir form alanı (daha yaygın) veya ayrı bir istek üst bilgisi (daha az yaygın) ve kimlik doğrulaması cookiearacılığıyla gönderilen sahteciliğe karşı koruma belirtecini de çalmalıdır. Kimlik doğrulaması veya yetkilendirmeyle ilgili tanımlama bilgileri, CookieSecurePolicy.None'dan daha güçlü bir ilke kullanır.

İsteğe bağlı olarak, uygulamanın cookie dosyasında aşağıdaki Development özellik ayarıyla, yalnızca HTTPS üzerinden Güvenli Yuva Katmanı (SSL) kullanarak ortamlarda olmayan ortamlardaki kötü amaçlı AntiforgeryOptions.CookieProgram yazılımdan korumanın güvenliğini sağlayabilirsiniz:

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddAntiforgery(o =>
    {
        o.Cookie.SecurePolicy = CookieSecurePolicy.Always;
    });
}

Daha fazla bilgi için bkz. CookieAuthenticationOptions.

IAntiforgery ile antiforgery belirteçleri oluşturma

IAntiforgery , kötü amaçlı yazılımdan koruma özelliklerini yapılandırmak için API'yi sağlar. IAntiforgery, Program.cs kullanılarak WebApplication.Services istenebilir. Aşağıdaki örnek, uygulamanın giriş sayfasındaki ara yazılımı kullanarak bir kötü amaçlı yazılımdan koruma belirteci oluşturur ve bunu yanıtta cookieolarak gönderir:

app.UseRouting();

app.UseAuthorization();

var antiforgery = app.Services.GetRequiredService<IAntiforgery>();

app.Use((context, next) =>
{
    var requestPath = context.Request.Path.Value;

    if (string.Equals(requestPath, "/", StringComparison.OrdinalIgnoreCase)
        || string.Equals(requestPath, "/index.html", StringComparison.OrdinalIgnoreCase))
    {
        var tokenSet = antiforgery.GetAndStoreTokens(context);
        context.Response.Cookies.Append("XSRF-TOKEN", tokenSet.RequestToken!,
            new CookieOptions { HttpOnly = false });
    }

    return next(context);
});

Yukarıdaki örnek, cookie adlı bir XSRF-TOKEN ayarlar. İstemci bunu cookie okuyabilir ve değerini AJAX isteklerine başlık olarak ekleyebilir. Örneğin, Angular, varsayılan olarak bir adı okuyan yerleşik XSRF koruması cookie içerirXSRF-TOKEN.

Antiforgery doğrulaması gerektirir

ValidateAntiForgeryToken eylem filtresi tek bir eyleme, denetleyiciye veya genel olarak uygulanabilir. bu filtrenin uygulandığı eylemlere yapılan istekler, istek geçerli bir kötü amaçlı yazılımdan koruma belirteci içermediği sürece engellenir:

[HttpPost]
[ValidateAntiForgeryToken]
public IActionResult Index()
{
    // ...

    return RedirectToAction();
}

Bu ValidateAntiForgeryToken özniteliği, HTTP GET istekleri dahil olmak üzere, işaretlediği eylem yöntemleri için isteklerde bir belirteç gerektirir. Uygulamanın kontrolörlerinde ValidateAntiForgeryToken özniteliği uygulanmışsa, bu öznitelik IgnoreAntiforgeryToken özniteliği ile geçersiz kılınabilir.

Güvenli olmayan HTTP yöntemleri için sahtecilik karşıtı jetonları otomatik olarak doğrula.

AutoValidateAntiforgeryToken özniteliğini geniş kapsamlı özniteliğini uygulayıp ardından öznitelikleriyle değiştirmek yerine kullanabilirsiniz. Bu öznitelik, aşağıdaki HTTP yöntemleri kullanılarak yapılan istekler için belirteç gerektirmemesi dışında özniteliğiyle aynı şekilde ValidateAntiForgeryToken çalışır:

• GET
• BAŞ
• SEÇENEKLER
• TRACE

API dışı senaryolar için geniş kapsamlı olarak kullanılmasını AutoValidateAntiforgeryToken öneririz. Bu öznitelik POST eylemlerinin varsayılan olarak korunmasını sağlar. Bunun alternatifi, tek tek eylem yöntemlerine uygulanmadığı sürece, varsayılan olarak sahtekarlık önleme belirteçlerini yoksaymaktır. Post eylem yönteminin yanlışlıkla korumasız bırakılması ve uygulamayı CSRF saldırılarına karşı savunmasız bırakma olasılığı bu senaryoda daha yüksektir. Tüm POST'ler, kötü amaçlı yazılımdan koruma belirtecini göndermelidir.

API'ler belirtecin parçası olmayancookie kısmını göndermek için otomatik bir mekanizmaya sahip değildir. Uygulama büyük olasılıkla istemci kodu uygulamasına bağlıdır. Aşağıda bazı örnekler gösterilmiştir:

Sınıf düzeyi örneği:

[AutoValidateAntiforgeryToken]
public class HomeController : Controller

Genel örnek:

builder.Services.AddControllersWithViews(options =>
{
    options.Filters.Add(new AutoValidateAntiforgeryTokenAttribute());
});

Genel veya denetleyici sahtecilik önleme özniteliklerini geçersiz kılma

IgnoreAntiforgeryToken filtresi, belirli bir eylem (veya denetleyici) için bir antiforgery belirteci gereksinimini ortadan kaldırmak için kullanılır. Uygulandığında, bu filtre, daha yüksek bir düzeyde (ValidateAntiForgeryToken veya AutoValidateAntiforgeryToken filtrelerinde) belirtilen genel veya denetleyici düzeyindeki filtreleri geçersiz kılar.

[IgnoreAntiforgeryToken]
public IActionResult IndexOverride()
{
    // ...

    return RedirectToAction();
}

Kimlik doğrulaması sonrasında belirteçleri yenileme

Belirteçler, kullanıcının kimliği doğrulandıktan sonra kullanıcıyı bir görünüme veya Razor Sayfalar sayfasına yönlendirerek yenilenmelidir.

JavaScript, AJAX ve SPA'lar

Geleneksel HTML tabanlı uygulamalarda, kötü amaçlı yazılımdan koruma belirteçleri gizli form alanları kullanılarak sunucuya geçirilir. Modern JavaScript tabanlı uygulamalarda ve SPA'larda program aracılığıyla birçok istek yapılır. Bu AJAX istekleri, belirteci göndermek için istek başlıkları veya tanımlama bilgileri gibi diğer teknikleri kullanabilir.

Kimlik doğrulama belirteçlerini depolamak ve sunucuda API isteklerini kimliğini doğrulamak için tanımlama bilgileri kullanılıyorsa, CSRF olası bir sorundur. Belirteci depolamak için yerel depolama kullanılıyorsa, yerel depolamadaki değerler her istekle birlikte sunucuya otomatik olarak gönderilmediğinden CSRF güvenlik açığı giderilebilir. İstemcide kötü amaçlı yazılımdan koruma belirtecini depolamak için yerel depolamayı kullanmak ve belirteci istek üst bilgisi olarak göndermek önerilen bir yaklaşımdır.

Blazor

Daha fazla bilgi için bkz . ASP.NET Çekirdek Blazor kimlik doğrulaması ve yetkilendirme.

JavaScript

JavaScript'i görünümlerle kullanarak belirteç, görünümün içinden bir hizmet kullanılarak oluşturulabilir. IAntiforgery hizmetini görünüme aktar ve GetAndStoreTokens çağır:

@inject Microsoft.AspNetCore.Antiforgery.IAntiforgery Antiforgery

@{
    ViewData["Title"] = "JavaScript";

    var requestToken = Antiforgery.GetAndStoreTokens(Context).RequestToken;
}

<input id="RequestVerificationToken" type="hidden" value="@requestToken" />

<button id="button" class="btn btn-primary">Submit with Token</button>
<div id="result" class="mt-2"></div>

@section Scripts {
<script>
    document.addEventListener("DOMContentLoaded", () => {
        const resultElement = document.getElementById("result");

        document.getElementById("button").addEventListener("click", async () => {

            const response = await fetch("@Url.Action("FetchEndpoint")", {
                method: "POST",
                headers: {
                    RequestVerificationToken:
                        document.getElementById("RequestVerificationToken").value
                }
            });

            if (response.ok) {
                resultElement.innerText = await response.text();
            } else {
                resultElement.innerText = `Request Failed: ${response.status}`
            }
        });
    });
</script>
}

Yukarıdaki örnekte, AJAX POST üst bilgisinin gizli alan değerini okumak için JavaScript kullanılır.

Bu yaklaşım, sunucudan tanımlama bilgileri ayarlama veya bunları istemciden okuma gereksinimini ortadan kaldırır. Ancak, IAntiforgery hizmeti enjekte etmek mümkün değilse, tanımlama bilgilerindeki belirteçlere erişmek için JavaScript kullanın.

• Sunucuya yöneltilen ek bir istekte genellikle erişim belirteçlerine ulaşılır same-origin.
• Belirtecin değerini içeren cookie'yi kullanarak bir üst bilgi oluşturun.

Betiğin belirteç adlı X-XSRF-TOKEN üst bilgiye sahip bir istek gönderdiğini varsayarsak, sahtecilik önleme hizmetini X-XSRF-TOKEN üst bilgiyi arayacak şekilde yapılandırın.

builder.Services.AddAntiforgery(options => options.HeaderName = "X-XSRF-TOKEN");

Aşağıdaki örnek, istek belirtecini JavaScript tarafından okunabilecek bir öğeye (cookie) yazan korumalı bir uç nokta ekler.

app.UseAuthorization();
app.MapGet("antiforgery/token", (IAntiforgery forgeryService, HttpContext context) =>
{
    var tokens = forgeryService.GetAndStoreTokens(context);
    context.Response.Cookies.Append("XSRF-TOKEN", tokens.RequestToken!,
            new CookieOptions { HttpOnly = false });

    return Results.Ok();
}).RequireAuthorization();

Aşağıdaki örnekte JavaScript, belirteci almak ve uygun üst bilgiyle başka bir istekte bulunmak üzere AJAX isteğinde bulunmak için kullanılır:

var response = await fetch("/antiforgery/token", {
    method: "GET",
    headers: { "Authorization": authorizationToken }
});

if (response.ok) {
    // https://developer.mozilla.org/docs/web/api/document/cookie
    const xsrfToken = document.cookie
        .split("; ")
        .find(row => row.startsWith("XSRF-TOKEN="))
        .split("=")[1];

    response = await fetch("/JavaScript/FetchEndpoint", {
        method: "POST",
        headers: { "X-XSRF-TOKEN": xsrfToken, "Authorization": authorizationToken }
    });

    if (response.ok) {
        resultElement.innerText = await response.text();
    } else {
        resultElement.innerText = `Request Failed: ${response.status}`
    }
} else {    
    resultElement.innerText = `Request Failed: ${response.status}`
}

Not

Hem istek üst bilgisinde hem de form yükünde sahtecilik engelleme belirteci sağlandığında, yalnızca üst bilgideki belirteç doğrulanır.

Minimal API'lerle sahteciliğin önlenmesi

AddAntiforgery ve fonksiyonlarını DI'ye sahtecilik önleme hizmetlerini kaydetmek için çağırın. Antiforgery belirteçleri siteler arası istek sahteciliği saldırılarını azaltmak için kullanılır.

var builder = WebApplication.CreateBuilder();

builder.Services.AddAntiforgery();

var app = builder.Build();

app.UseAntiforgery();

app.MapGet("/", () => "Hello World!");

app.Run();

Kötü amaçlı yazılımdan koruma ara yazılımı:

• , istek işlem hattının geri kalanının yürütülmesini kısa devre yapmaz mı?.
• Mevcut istekteki IAntiforgeryValidationFeature üzerine HttpContext.Features'ı ayarlar.

Sahteciliği önleme belirteci yalnızca aşağıdaki durumlarda doğrulanır:

• Uç nokta, IAntiforgeryMetadatabağlamında RequiresValidation=true uygulayan meta verileri içerir.
• Uç noktayla ilişkili HTTP yöntemi POST, PUT veya PATCH türünde ilgili bir HTTP yöntemidir .
• İstek geçerli bir uç noktayla ilişkilendirildi.

Sahteciliği önleme ara katmanı, istek işlem hattını kısa devreye uğratmaz. Belirteç doğrulaması başarısız olsa bile uç nokta kodu her zaman çalışır. Belirteç doğrulamasının sonucunu gözlemlemek için IAntiforgeryValidationFeature içindeki HttpContext.Features çözümleyin ve hata ayrıntıları için IsValid özelliğini veya Error özelliğini inceleyin. Uç noktalar başarısız olan kötü amaçlı yazılımdan koruma doğrulaması için özel işleme gerektirdiğinde bu yaklaşım kullanışlıdır.

Not: El ile etkinleştirildiğinde, kullanıcı kimliği doğrulanmamış olduğunda form verilerinin okunmasını önlemek için kimlik doğrulama ve yetkilendirme ara yazılımından sonra kötü amaçlı yazılımdan koruma ara yazılımının çalışması gerekir.

Varsayılan olarak, form verilerini kabul eden Minimal API'ler, antiforgery belirteç doğrulaması gerektirir ve belirteç doğrulama başarılı olmazsa uygulama kodunu çalıştırmadan önce başarısızlıkla sonuçlanır.

Aşağıdaki GenerateForm yöntemi göz önünde bulundurun:

public static string GenerateForm(string action, 
    AntiforgeryTokenSet token, bool UseToken=true)
{
    string tokenInput = "";
    if (UseToken)
    {
        tokenInput = $@"<input name=""{token.FormFieldName}""
                         type=""hidden"" value=""{token.RequestToken}"" />";
    }

    return $@"
    <html><body>
        <form action=""{action}"" method=""POST"" enctype=""multipart/form-data"">
            {tokenInput}
            <input type=""text"" name=""name"" />
            <input type=""date"" name=""dueDate"" />
            <input type=""checkbox"" name=""isCompleted"" />
            <input type=""submit"" />
        </form>
    </body></html>
";
}

Yukarıdaki kod üç bağımsız değişkene sahiptir: eylem, sahteciliğe karşı koruma belirteci ve belirtecin kullanılıp kullanılmayacağını gösteren bir bool .

Aşağıdaki örneği göz önünde bulundurun:

using Microsoft.AspNetCore.Antiforgery;
using Microsoft.AspNetCore.Mvc;

var builder = WebApplication.CreateBuilder();

builder.Services.AddAntiforgery();

var app = builder.Build();

app.UseAntiforgery();

// Pass token
app.MapGet("/", (HttpContext context, IAntiforgery antiforgery) =>
{
    var token = antiforgery.GetAndStoreTokens(context);
    return Results.Content(MyHtml.GenerateForm("/todo", token), "text/html");
});

// Don't pass a token, fails
app.MapGet("/SkipToken", (HttpContext context, IAntiforgery antiforgery) =>
{
    var token = antiforgery.GetAndStoreTokens(context);
    return Results.Content(MyHtml.GenerateForm("/todo",token, false ), "text/html");
});

// Post to /todo2. DisableAntiforgery on that endpoint so no token needed.
app.MapGet("/DisableAntiforgery", (HttpContext context, IAntiforgery antiforgery) =>
{
    var token = antiforgery.GetAndStoreTokens(context);
    return Results.Content(MyHtml.GenerateForm("/todo2", token, false), "text/html");
});

app.MapPost("/todo", ([FromForm] Todo todo) => Results.Ok(todo));

app.MapPost("/todo2", ([FromForm] Todo todo) => Results.Ok(todo))
                                                .DisableAntiforgery();

app.Run();

class Todo
{
    public required string Name { get; set; }
    public bool IsCompleted { get; set; }
    public DateTime DueDate { get; set; }
}

public static class MyHtml
{
    public static string GenerateForm(string action, 
        AntiforgeryTokenSet token, bool UseToken=true)
    {
        string tokenInput = "";
        if (UseToken)
        {
            tokenInput = $@"<input name=""{token.FormFieldName}""
                             type=""hidden"" value=""{token.RequestToken}"" />";
        }

        return $@"
        <html><body>
            <form action=""{action}"" method=""POST"" enctype=""multipart/form-data"">
                {tokenInput}
                <input type=""text"" name=""name"" />
                <input type=""date"" name=""dueDate"" />
                <input type=""checkbox"" name=""isCompleted"" />
                <input type=""submit"" />
            </form>
        </body></html>
    ";
    }
}

Önceki kodda şu gönderileri gönder:

• /todo geçerli bir sahtecilik önleme belirteci gerektirir.
• /todo2 geçerli bir antiforgery belirteci gerektirmez çünkü çağrılır.

app.MapPost("/todo", ([FromForm] Todo todo) => Results.Ok(todo));

app.MapPost("/todo2", ([FromForm] Todo todo) => Results.Ok(todo))
                                                .DisableAntiforgery();

Uyarı

Çağırma, .DisableAntiforgery() uç nokta için siteler arası istek sahteciliği (CSRF) korumasını devre dışı bırakır. Bu yalnızca bir uç nokta CSRF saldırılarına karşı savunmasız olmadığında kullanılmalıdır, örneğin:

• Tarayıcıdan çağrılamayan uç noktalar (örneğin, iç API'ler)
• Tabanlı olmayancookie kimlik doğrulamasıyla güvenliği sağlanan uç noktalar (örneğin, taşıyıcı belirteçleri veya API anahtarları)
• Kullanıcı çerezlerine güvenmeyen iç veya altyapı uç noktaları

Kimlik doğrulaması için tanımlama bilgilerini kullanan veya kullanıcı tarafından gönderilen form verilerini işleyen tarayıcı tarafından erişilebilen uç noktalar için kötü amaçlı yazılımdan koruma doğrulamasını devre dışı bırakmayın, bu durum uygulamanızı CSRF saldırılarına maruz bırakır.

Gönderi:

• /todo sahtecilik önleme belirteci geçerli olduğundan, uç nokta tarafından / oluşturulan formdan başarıyla çalışır.
• /todo tarafından oluşturulan formda antiforgery dahil edilmediği için /SkipToken başarısız oluyor.
• /todo2 sahtecilik önleme gerektirilmediğinden, /DisableAntiforgery uç noktası tarafından oluşturulan formdan başarılı olur.

app.MapPost("/todo", ([FromForm] Todo todo) => Results.Ok(todo));

app.MapPost("/todo2", ([FromForm] Todo todo) => Results.Ok(todo))
                                                .DisableAntiforgery();

Form geçerli bir kötü amaçlı yazılımdan koruma belirteci olmadan gönderildiğinde:

• Development ortamında bir istisna atılır.
• Production Ortamda bir ileti günlüğe kaydedilir.

HTTP yöntemi sınırlamaları ve HttpMethodOverrideMiddleware etkileşimi

Ara yazılım tabanlı sahteciliğe karşı koruma yolunda, AntiforgeryMiddleware ve UseAntiforgery() sahteciliğe karşı koruma belirteçlerini yalnızca HTTP POST, PUT ve PATCH istekleri için doğrular. DELETE gibi diğer HTTP yöntemleri otomatik olarak doğrulanmaz.

Diğer HTTP yöntemleri için sahteciliğe karşı belirteçleri doğrulamak üzere, DI'den IAntiforgery alın ve ValidateRequestAsync veya IsRequestValidAsync yöntemini açıkça çağırın:

app.MapDelete("/item/{id}", async (int id, IAntiforgery antiforgery, HttpContext context) =>
{
    await antiforgery.ValidateRequestAsync(context);
    // Process the DELETE request
});

Uyarı

HttpMethodOverrideMiddleware, FormFieldName ile yapılandırıldığında (form alanı modu) ve AntiforgeryMiddleware'den önce yerleştirildiğinde, bir POST isteği DELETE (veya doğrulanmayan başka bir metot) olarak geçersiz kılınabilir. Yalnızca AntiforgeryMiddleware POST, PUT ve PATCH doğrulandığından geçersiz kılınan istek, sahteciliğe karşı doğrulamayı atlar.

Bu uç noktaları korumak için:

• İşlem hattınız buna izin veriyorsa, HttpMethodOverrideMiddleware öğesini antiforgery doğrulamasından sonra yerleştirmeyi tercih edin.
• Sahteciliğe karşı doğrulamaya dayanan uç noktalar için form alanı geçersiz kılmalarından kaçının.
• Form alanı geçersiz kılmasının önce çalışması gerekiyorsa, sahteciliğe karşı koruma belirtecini IAntiforgery.ValidateRequestAsync kullanarak açıkça doğrulayın.

Yapılandırma ayrıntıları için bkz. ASP.NET Core ara yazılım.

Windows kimlik doğrulaması ve sahtecilik önleyici tanımlama bilgileri

Windows Kimlik Doğrulaması kullanılırken, uygulama uç noktalarının tanımlama bilgileriyle aynı şekilde CSRF saldırılarına karşı korunması gerekir. Tarayıcı, kimlik doğrulama bağlamını sunucuya örtük olarak gönderir ve uç noktaların CSRF saldırılarına karşı korunması gerekir.

Sahtecilik önlemeyi genişletme

IAntiforgeryAdditionalDataProvider türü, geliştiricilerin her belirteçte ek verileri gidip getirerek anti-CSRF sisteminin davranışını genişletmesine olanak tanır. Bir GetAdditionalData alan belirteci her oluşturulduğunda yöntemi çağrılır ve döndürülen değer oluşturulan belirtecin içine eklenir. Uygulayıcı bir zaman damgası, bir nonce veya başka bir değer döndürebilir ve daha sonra, token doğrulandığında bu veriyi doğrulamak için ValidateAdditionalData çağırabilir. İstemcinin kullanıcı adı oluşturulan belirteçlere zaten eklenmiş olduğundan bu bilgileri eklemenize gerek yoktur. Belirteç ek veriler içeriyorsa ancak yapılandırılmamışsa IAntiForgeryAdditionalDataProvider , ek veriler doğrulanmaz.

Ek kaynaklar

• Web grubunda ASP.NET Core barındırma