Mencegah serangan Pemalsuan Permintaan Lintas Situs (XSRF/CSRF) di ASP.NET Core

Oleh Fiyaz Hasan dan Rick Anderson

Pemalsuan permintaan lintas situs adalah serangan terhadap aplikasi yang dihosting web di mana aplikasi web berbahaya dapat memengaruhi interaksi antara browser klien dan aplikasi web yang mempercayai browser tersebut. Serangan ini dimungkinkan karena browser web mengirim beberapa jenis token autentikasi secara otomatis dengan setiap permintaan ke situs web. Bentuk eksploitasi ini juga dikenal sebagai serangan sekali klik atau pengambilalihan sesi karena serangan ini memanfaatkan sesi pengguna yang telah diautentikasi sebelumnya. Pemalsuan permintaan lintas situs juga dikenal sebagai XSRF atau CSRF.

Contoh serangan CSRF:

1. Pengguna masuk ke www.good-banking-site.example.com menggunakan autentikasi formulir. Server mengautentikasi pengguna dan mengeluarkan respons yang menyertakan autentikasi cookie. Situs ini rentan terhadap serangan karena mempercayai permintaan apa pun yang diterimanya dengan autentikasi cookieyang valid.

2. Pengguna mengunjungi situs berbahaya, www.bad-crook-site.example.com.

   Situs berbahaya, www.bad-crook-site.example.com, berisi formulir HTML yang mirip dengan contoh berikut:

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

   Perhatikan bahwa formulir action mengirimkan data ke situs rentan, bukan ke situs berbahaya. Ini adalah bagian "lintas situs" dari CSRF.

3. Pengguna memilih tombol kirim. Browser membuat permintaan dan secara otomatis menyertakan autentikasi cookie untuk domain yang diminta, www.good-banking-site.example.com.

4. Permintaan berjalan di www.good-banking-site.example.com server dengan konteks autentikasi pengguna dan dapat melakukan tindakan apa pun yang diizinkan untuk dilakukan oleh pengguna terautentikasi.

Selain skenario di mana pengguna memilih tombol untuk mengirimkan formulir, situs berbahaya dapat:

• Jalankan skrip yang secara otomatis mengirimkan formulir.
• Kirim pengiriman formulir sebagai permintaan AJAX.
• Sembunyikan formulir menggunakan CSS.

Skenario alternatif ini tidak memerlukan tindakan atau input apa pun dari pengguna selain awalnya mengunjungi situs berbahaya.

Menggunakan HTTPS tidak mencegah serangan CSRF. Situs berbahaya dapat mengirim sebuah permintaan https://www.good-banking-site.example.com/ semudah mengirim permintaan tidak aman.

Beberapa serangan menargetkan titik akhir yang merespons permintaan GET, dalam hal ini tag gambar dapat digunakan untuk melakukan tindakan. Bentuk serangan ini umum terjadi di situs forum yang mengizinkan gambar tetapi memblokir JavaScript. Aplikasi yang mengubah status pada permintaan GET, di mana variabel atau sumber daya diubah, rentan terhadap serangan berbahaya. Permintaan GET yang mengubah status tidak aman. Praktik terbaik adalah tidak pernah mengubah status pada permintaan GET.

Serangan CSRF dimungkinkan terhadap aplikasi web yang menggunakan cookie untuk autentikasi karena:

• Browser menyimpan cookie yang dikeluarkan oleh aplikasi web.
• Cookie tersimpan mencakup cookie sesi untuk pengguna yang diautentikasi.
• Browser mengirim semua cookie yang terkait dengan domain ke aplikasi web setiap permintaan terlepas dari bagaimana permintaan ke aplikasi dihasilkan dalam browser.

Namun, serangan CSRF tidak terbatas pada mengeksploitasi cookie. Misalnya, autentikasi Dasar dan Digest juga rentan. Setelah pengguna masuk dengan autentikasi Dasar atau Digest, browser secara otomatis mengirimkan kredensial pengguna hingga sesi berakhir.

Dalam konteks ini, sesi mengacu pada sesi sisi klien tempat pengguna diautentikasi. Ini tidak terkait dengan sesi sisi server atau middleware sesi ASP.NET Core.

Pengguna dapat melindungi dari kerentanan CSRF dengan mengambil tindakan pencegahan:

• Keluar dari aplikasi web setelah selesai menggunakannya.
• Hapus cookie browser secara berkala.

Namun, kerentanan CSRF pada dasarnya merupakan masalah dengan aplikasi web, bukan pengguna akhir.

Dasar-dasar autentikasi

Autentikasi berbasis Cookie adalah bentuk autentikasi yang populer. Sistem autentikasi berbasis token semakin populer, terutama untuk Aplikasi Halaman Tunggal (SPAs).

Cookie-berbasis autentikasi

Saat pengguna mengautentikasi menggunakan nama pengguna dan kata sandi mereka, mereka mengeluarkan token yang berisi tiket autentikasi. Token dapat digunakan untuk autentikasi dan otorisasi. Token disimpan sebagai cookie yang dikirim dengan setiap permintaan yang dilakukan klien. Pembuatan dan validasi cookie ini dilakukan menggunakan middleware autentikasi cookie. Middleware mengubah prinsipal pengguna menjadi data terenkripsi cookie. Pada permintaan berikutnya, middleware memvalidasi cookie, membuat ulang entitas utama, dan menetapkan entitas utama ke properti HttpContext.User.

Autentikasi berbasis token

Saat pengguna diautentikasi, mereka diberikan token (bukan token antiforgery). Token berisi informasi pengguna dalam bentuk klaim atau token referensi yang menunjuk aplikasi ke status pengguna yang dipertahankan di aplikasi. Saat pengguna mencoba mengakses sumber daya yang memerlukan autentikasi, token dikirim ke aplikasi dengan header otorisasi tambahan dalam bentuk Bearer token. Pendekatan ini menjadikan aplikasi tidak bergantung pada status. Dalam setiap permintaan berikutnya, token diteruskan dalam permintaan validasi sisi server. Token ini tidak dienkripsi; dikodekan. Di server, token didekodekan untuk mengakses informasinya. Untuk mengirim token pada permintaan berikutnya, simpan token di penyimpanan lokal browser. Menempatkan token di penyimpanan lokal browser dan mengambilnya dan menggunakannya sebagai token pembawa memberikan perlindungan terhadap serangan CSRF. Namun, jika aplikasi rentan terhadap injeksi skrip melalui XSS atau file JavaScript eksternal yang disusupi, penyerang cyber dapat mengambil nilai apa pun dari penyimpanan lokal dan mengirimkannya ke diri mereka sendiri. ASP.NET Core mengodekan semua output sisi server dari variabel secara default, mengurangi risiko XSS. Jika Anda mengambil alih perilaku ini dengan menggunakan Html.Raw atau kode kustom dengan input yang tidak tepercaya, Maka Anda dapat meningkatkan risiko XSS.

Jangan khawatir tentang kerentanan CSRF jika token disimpan di penyimpanan lokal browser. CSRF menjadi perhatian ketika token disimpan dalam cookie. Untuk informasi selengkapnya, lihat isu GitHub tentang sampel kode SPA SPA code sample adds two cookies.

Beberapa aplikasi yang dihosting di satu domain

Lingkungan hosting bersama rentan terhadap pembajakan sesi, serangan CSRF saat masuk, dan serangan lainnya.

Meskipun example1.contoso.net dan example2.contoso.net merupakan host yang berbeda, ada hubungan kepercayaan implisit antara host di *.contoso.net bawah domain. Hubungan kepercayaan implisit ini memungkinkan host yang berpotensi tidak tepercaya untuk memengaruhi cookie satu sama lain (kebijakan asal yang sama yang mengatur permintaan AJAX tidak selalu berlaku untuk cookie HTTP).

Serangan yang mengeksploitasi cookie tepercaya antara aplikasi yang dihosting di domain yang sama dapat dicegah dengan tidak berbagi domain. Saat setiap aplikasi dihosting di domainnya sendiri, tidak ada hubungan kepercayaan implisit cookie untuk dieksploitasi.

Anti-Pemalsuan dalam ASP.NET Core

Peringatan

ASP.NET Core mengimplementasikan antiforgery menggunakan ASP.NET Core Data Protection. Tumpukan perlindungan data harus dikonfigurasi untuk bekerja di farm server. Untuk informasi selengkapnya, lihat Mengonfigurasi perlindungan data.

Layanan anti-pemalsuan didaftarkan dalam kontainer injeksi dependensi saat salah satu API berikut dipanggil di Program.cs:

• AddMvc
• MapRazorPages
• MapControllerRoute
• AddRazorComponents

Catatan

Mendaftarkan layanan tidak menambahkan middleware Antiforgery ke alur pemrosesan permintaan. MVC dan Razor Pages memvalidasi token dengan filter bawaan, sehingga tidak memerlukan middleware. Blazor dan API Minimal memerlukan panggilan eksplisit ke UseAntiforgery dalam Program.cs, yang ada secara default dalam Blazor Web App templat proyek. Untuk informasi selengkapnya, lihat ASP.NET Core Blazor autentikasi dan otorisasi dan Antiforgery dengan API Minimal.

Untuk informasi selengkapnya, lihat Antiforgery dengan Minimal APIs.

FormTagHelper menyuntikkan token anti-pemalsuan ke dalam elemen formulir HTML. Markup berikut dalam Razor file secara otomatis menghasilkan token antiforgery:

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

Demikian pula, IHtmlHelper.BeginForm menghasilkan token antiforgery secara default jika metode formulir bukan GET.

Pembuatan otomatis token antiforgery untuk elemen formulir HTML terjadi ketika <form> tag berisi method="post" atribut dan salah satu dari yang berikut ini benar:

• Atribut tindakan kosong (action="").
• Atribut tindakan tidak disediakan (<form method="post">).

Pembuatan token antiforgeri otomatis untuk elemen formulir HTML dapat dinonaktifkan:

• Nonaktifkan token antiforgery secara eksplisit dengan asp-antiforgery atribut :

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

• Elemen formulir ditolak dari Pembantu Tag dengan menggunakan simbol penolakan Pembantu Tag ! :

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

• Hapus FormTagHelper dari tampilan. FormTagHelper dapat dihapus dari tampilan dengan menambahkan direktif berikut ke Razor tampilan:

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

Catatan

Razor Halaman secara otomatis dilindungi dari XSRF/CSRF. Untuk informasi selengkapnya, lihat XSRF/CSRF dan Razor Pages.

Pendekatan paling umum untuk melindungi dari serangan CSRF adalah menggunakan Pola Token Sinkronisasi (STP). STP digunakan saat pengguna meminta halaman dengan data formulir:

1. Server mengirim token yang terkait dengan identitas pengguna saat ini ke klien.
2. Klien mengirim kembali token ke server untuk verifikasi.
3. Jika server menerima token yang tidak cocok dengan identitas pengguna yang diautentikasi, permintaan akan ditolak.

Token unik dan tidak dapat diprediksi. Token juga dapat digunakan untuk memastikan urutan yang tepat dari serangkaian permintaan (misalnya, memastikan urutan permintaan: halaman 1 > halaman 2 > halaman 3). Semua formulir dalam templat ASP.NET Core MVC dan Razor Pages menghasilkan token antiforgery. Contoh tampilan berikut ini menghasilkan token anti-pemalsuan:

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

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

Secara eksplisit tambahkan token antiforgery ke elemen <form> tanpa menggunakan Tag Helpers dengan HTML helper @Html.AntiForgeryToken.

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

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

Dalam setiap kasus sebelumnya, ASP.NET Core menambahkan bidang formulir tersembunyi yang mirip dengan contoh berikut:

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

ASP.NET Core mencakup tiga filter untuk menangani token antiforgery.

• ValidateAntiForgeryToken
• AutoValidateAntiforgeryToken
• AbaikanTokenAntipemalsuan

Penangkal Pemalsuan dengan AddControllers

AddControllers Panggilan tidak mengaktifkan token antiforgery. AddControllersWithViews harus dipanggil agar memiliki dukungan token antiforgery bawaan.

Beberapa tab browser dan Pola Token Sinkronisasi

Beberapa tab yang masuk sebagai pengguna yang berbeda, atau yang masuk sebagai anonim, tidak didukung.

Mengonfigurasi fitur anti-pemalsuan dengan AntiforgeryOptions

Kustomisasi AntiforgeryOptions dalam file aplikasi Program :

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

Atur properti antiforgery cookie menggunakan properti kelas CookieBuilder, seperti yang ditunjukkan dalam tabel berikut.

Opsi	Deskripsi
Cookie	Menentukan pengaturan yang digunakan untuk membuat cookie antiforgery.
FormFieldName	Nama kolom formulir tersembunyi yang digunakan oleh sistem antiforgery untuk memproses token antiforgery dalam tampilan.
HeaderName	Nama header yang digunakan oleh sistem anti-pemalsuan. Jika null, sistem hanya mempertimbangkan data formulir.
SuppressXFrameOptionsHeader	Menentukan apakah akan mengabaikan pembuatan header X-Frame-Options. Secara default, header dihasilkan dengan nilai "SAMEORIGIN". Bawaan ke false.

Beberapa browser tidak mengizinkan titik akhir yang tidak aman untuk mengatur cookie dengan flag 'secure' atau menimpa cookie yang flag 'secure'-nya sudah diatur (untuk informasi selengkapnya, lihat Menyarankan untuk tidak memodifikasi cookie 'secure' dari asal yang tidak aman). Karena mencampur titik akhir yang aman dan tidak aman adalah skenario umum dalam aplikasi, ASP.NET Core melonggarkan pembatasan pada kebijakan aman pada beberapa cookie, seperti antiforgery cookie, dengan mengatur cookie dari SecurePolicy ke CookieSecurePolicy.None. Bahkan jika pengguna berbahaya mencuri antiforgery cookie, mereka juga harus mencuri token antiforgery yang biasanya dikirim melalui bidang formulir (lebih umum) atau header permintaan terpisah (kurang umum) ditambah autentikasi cookie. Cookies terkait dengan autentikasi atau otorisasi menggunakan kebijakan yang lebih kuat daripada CookieSecurePolicy.None.

Secara opsional, Anda dapat mengamankan antiforgery cookie di lingkungan yang tidak menggunakan Development dengan menggunakan Secure Sockets Layer (SSL) melalui HTTPS saja, dengan pengaturan properti berikut AntiforgeryOptions.Cookie dalam file aplikasi Program :

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

Untuk informasi selengkapnya, lihat CookieAuthenticationOptions .

Hasilkan token anti-pemalsuan dengan IAntiforgery

IAntiforgery menyediakan API untuk mengonfigurasi fitur antiforgery. IAntiforgery dapat diminta dalam Program.cs menggunakan WebApplication.Services. Contoh berikut ini menggunakan middleware dari halaman utama aplikasi untuk menghasilkan token antiforgery dan mengirimkannya dalam respons sebagai cookie:

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);
});

Contoh sebelumnya menetapkan sebuah cookie yang diberi nama XSRF-TOKEN. Klien dapat membaca ini cookie dan memberikan nilainya sebagai header yang dilampirkan ke permintaan AJAX. Misalnya, Angular menyertakan perlindungan XSRF bawaan yang secara default membaca sebuah elemen bernama cookieXSRF-TOKEN.

Memerlukan validasi pencegahan pemalsuan

Filter aksi ValidateAntiForgeryToken dapat diterapkan ke aksi individu, kontroler, atau secara global. Permintaan yang dibuat untuk tindakan yang menerapkan filter ini diblokir kecuali permintaan menyertakan token antiforgery yang valid:

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

    return RedirectToAction();
}

Atribut ValidateAntiForgeryToken memerlukan token untuk permintaan ke metode tindakan yang ditandainya, termasuk permintaan HTTP GET. Jika atribut ValidateAntiForgeryToken diterapkan di seluruh pengontrol aplikasi, atribut tersebut dapat ditimpa dengan atribut IgnoreAntiforgeryToken.

Memvalidasi secara otomatis token antiforgery hanya untuk metode HTTP yang dianggap tidak aman.

Alih-alih menerapkan atribut ValidateAntiForgeryToken secara luas dan kemudian menimpanya dengan atribut IgnoreAntiforgeryToken, atribut AutoValidateAntiforgeryToken dapat digunakan. Atribut ini berfungsi secara identik dengan ValidateAntiForgeryToken atribut , kecuali bahwa atribut ini tidak memerlukan token untuk permintaan yang dibuat menggunakan metode HTTP berikut:

• DAPATKAN
• Kepala
• OPSI
• TRACE

Sebaiknya gunakan AutoValidateAntiforgeryToken secara luas untuk skenario non-API. Atribut ini memastikan tindakan POST dilindungi secara default. Alternatifnya adalah mengabaikan token antiforgery secara default, kecuali ValidateAntiForgeryToken diterapkan ke metode tindakan individual. Dalam skenario ini, lebih mungkin metode tindakan POST dibiarkan tidak terlindungi secara tidak sengaja, membuat aplikasi rentan terhadap serangan CSRF. Semua POS harus mengirim token antiforgery.

API tidak memiliki mekanisme otomatis untuk mengirimkan bagian dari token yang bukan cookie. Implementasi mungkin tergantung pada implementasi kode klien. Beberapa contoh ditunjukkan di bawah ini:

Contoh pada tingkat kelas:

[AutoValidateAntiforgeryToken]
public class HomeController : Controller

Contoh global:

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

Mengambil alih atribut antiforgery global atau pengontrol

Filter IgnoreAntiforgeryToken digunakan untuk menghilangkan kebutuhan token antiforgery untuk tindakan tertentu (atau pengontrol). Ketika diterapkan, filter ini akan mengesampingkan filter ValidateAntiForgeryToken dan AutoValidateAntiforgeryToken yang ditentukan pada tingkat yang lebih tinggi (secara global atau pada pengontrol).

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

    return RedirectToAction();
}

Penyegaran token setelah autentikasi

Token harus di-refresh setelah pengguna diautentikasi dengan mengalihkan pengguna ke halaman tampilan atau Razor Halaman.

JavaScript, AJAX, dan SPAs

Dalam aplikasi tradisional berbasis HTML, token antiforgery dikirimkan ke server menggunakan kolom formulir tersembunyi. Di aplikasi dan SPAs berbasis JavaScript modern, banyak permintaan dibuat secara terprogram. Permintaan AJAX ini dapat menggunakan teknik lain, seperti header permintaan atau cookie, untuk mengirim token.

Jika cookie digunakan untuk menyimpan token autentikasi dan untuk mengautentikasi permintaan API di server, CSRF adalah masalah potensial. Jika penyimpanan lokal digunakan untuk menyimpan token, kerentanan CSRF mungkin dimitigasi karena nilai dari penyimpanan lokal tidak dikirim secara otomatis ke server dengan setiap permintaan. Menggunakan penyimpanan lokal untuk menyimpan token antiforgery pada klien dan mengirim token sebagai header permintaan adalah pendekatan yang direkomendasikan.

Blazor

Untuk informasi selengkapnya, lihat ASP.NET Core Blazor autentikasi dan otorisasi.

JavaScript

Dengan menggunakan JavaScript pada tampilan, token dapat dibuat menggunakan layanan dari dalam tampilan tersebut. IAntiforgery Masukkan layanan ke dalam tampilan dan panggil GetAndStoreTokens:

@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>
}

Contoh sebelumnya menggunakan JavaScript untuk membaca nilai bidang tersembunyi untuk header AJAX POST.

Pendekatan ini menghilangkan kebutuhan untuk berurusan langsung dengan pengaturan cookie dari server atau membacanya dari klien. Namun, jika menyuntikkan layanan IAntiforgery tidak memungkinkan, gunakan JavaScript untuk mengakses token dalam cookie.

• Akses token dalam permintaan tambahan ke server, biasanya same-origin.
• Gunakan konten dari cookie untuk membuat header dengan nilai token.

Dengan asumsi skrip mengirimkan token di header permintaan yang disebutkan X-XSRF-TOKEN, konfigurasikan layanan antiforgery untuk mencari header X-XSRF-TOKEN.

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

Contoh berikut menambahkan titik akhir terproteksi yang menulis token permintaan ke JavaScript yang dapat cookiedibaca :

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();

Contoh berikut menggunakan JavaScript untuk membuat permintaan AJAX untuk mendapatkan token dan membuat permintaan lain dengan header yang sesuai:

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}`
}

Catatan

Ketika token antiforgery disediakan di header permintaan dan dalam payload formulir, hanya token di header yang divalidasi.

Pencegahan Pemalsuan dengan API Minimal

Panggil AddAntiforgery untuk mendaftarkan layanan antiforgery di DI, dan UseAntiforgery untuk menambahkan Middleware Antiforgery ke alur pemrosesan permintaan. Token antiforgery digunakan untuk mengurangi serangan pemalsuan permintaan lintas situs.

var builder = WebApplication.CreateBuilder();

builder.Services.AddAntiforgery();

var app = builder.Build();

app.UseAntiforgery();

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

app.Run();

Middleware pencegahan pemalsuan

• Apakah tidak menghentikan pelaksanaan sisa dari alur permintaan.
• Mengatur IAntiforgeryValidationFeature dalam HttpContext.Features permintaan saat ini.

Token antiforgery hanya divalidasi jika:

• Titik akhir berisi metadata yang menerapkan IAntiforgeryMetadata untuk RequiresValidation=true.
• Metode HTTP yang terkait dengan titik akhir adalah metode HTTP yang relevan dari jenis POST, PUT, atau PATCH.
• Permintaan dikaitkan dengan titik akhir yang valid.

Middleware antiforgery tidak mempersingkat sirkuit alur permintaan. Kode titik akhir selalu berjalan, bahkan jika validasi token gagal. Untuk mengamati hasil validasi token, tangani IAntiforgeryValidationFeature dari HttpContext.Features dan periksa properti IsValid atau properti Error untuk detail kegagalan. Pendekatan ini berguna ketika titik akhir memerlukan penanganan kustom untuk validasi antiforgery yang gagal.

Catatan: Saat diaktifkan secara manual, middleware antiforgery harus berjalan setelah middleware autentikasi dan otorisasi untuk mencegah membaca data formulir saat pengguna tidak diautentikasi.

Secara default, API Minimal yang menerima data formulir memerlukan validasi token antiforgery dan gagal sebelum menjalankan kode aplikasi jika validasi antiforgery tidak berhasil.

Pertimbangkan metode berikut GenerateForm :

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>
";
}

Kode sebelumnya memiliki tiga argumen, tindakan, token antiforgery, dan bool menunjukkan apakah token harus digunakan.

Pertimbangkan sampel berikut:

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>
    ";
    }
}

Dalam kode sebelumnya, memposting ke:

• /todo memerlukan token antiforgery yang valid.
• /todo2 tidak memerlukan token antiforgery yang valid karena DisableAntiforgery dipanggil.

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

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

Peringatan

Memanggil .DisableAntiforgery() menonaktifkan perlindungan pemalsuan permintaan lintas situs (CSRF) untuk titik akhir. Ini hanya boleh digunakan ketika titik akhir tidak rentan terhadap serangan CSRF, seperti:

• Titik akhir yang tidak dapat dipanggil dari browser (misalnya, API internal)
• Titik akhir diamankan dengan autentikasi non-berbasiscookie (misalnya, token pembawa atau kunci API)
• Titik akhir internal atau infrastruktur yang tidak bergantung pada cookie pengguna

Jangan nonaktifkan validasi antiforgery untuk titik akhir yang dapat diakses browser yang mengandalkan cookie untuk autentikasi atau yang memproses data formulir yang dikirim pengguna, karena ini mengekspos aplikasi Anda ke serangan CSRF.

Sebuah POST ke:

• /todo dari formulir yang dihasilkan oleh endpoint / berhasil karena token antiforgery valid.
• /todo dari formulir yang dihasilkan oleh /SkipToken gagal karena antiforgery tidak disertakan.
• /todo2 dari formulir yang dihasilkan oleh /DisableAntiforgery endpoint berhasil karena antiforgery tidak diperlukan.

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

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

Ketika formulir dikirimkan tanpa token antiforgery yang valid:

• Di lingkungan Development, sebuah pengecualian terjadi.
• Di lingkungan Production, sebuah pesan dicatat.

Batasan metode HTTP dan interaksi HttpMethodOverrideMiddleware

Untuk jalur antiforgery berbasis middleware, AntiforgeryMiddleware dan UseAntiforgery() validasi token antiforgery hanya untuk permintaan HTTP POST, PUT, dan PATCH . Metode HTTP lainnya, seperti DELETE, tidak divalidasi secara otomatis.

Untuk memvalidasi token antiforgery untuk metode HTTP lainnya, selesaikan IAntiforgery dari DI dan panggil ValidateRequestAsync atau IsRequestValidAsync secara eksplisit:

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

Peringatan

Ketika HttpMethodOverrideMiddleware dikonfigurasi dengan FormFieldName (mode bidang formulir) dan ditempatkan sebelum AntiforgeryMiddleware, permintaan POST dapat dioverride menjadi DELETE (atau metode lain yang tidak tervalidasi). Karena AntiforgeryMiddleware hanya memvalidasi POST, PUT, dan PATCH, permintaan yang dioverride tidak menjalani validasi antiforgery.

Untuk melindungi titik akhir ini:

• Sebaiknya tempatkan HttpMethodOverrideMiddleware setelah validasi antiforgery jika pipeline Anda memungkinkannya.
• Hindari penimpaan isian formulir untuk endpoint yang mengandalkan validasi anti-pemalsuan.
• Jika override pada field formulir perlu dijalankan terlebih dahulu, validasi token antiforgery secara eksplisit menggunakan IAntiforgery.ValidateRequestAsync.

Untuk detail konfigurasi, lihat ASP.NET Core middleware.

Autentikasi Windows dan kuki anti-pemalsuan

Saat menggunakan Autentikasi Windows, titik akhir aplikasi harus dilindungi dari serangan CSRF dengan cara yang sama seperti yang dilakukan untuk cookie. Browser secara implisit mengirim konteks autentikasi ke server dan titik akhir perlu dilindungi dari serangan CSRF.

Perluas fitur anti-pemalsuan

Jenis ini IAntiforgeryAdditionalDataProvider memungkinkan pengembang untuk memperpanjang fungsi sistem anti-CSRF dengan memutar alihkan data tambahan di setiap token. Metode GetAdditionalData ini dipanggil setiap kali token bidang dihasilkan, dan nilai pengembalian disematkan dalam token yang dihasilkan. Pelaksana dapat mengembalikan tanda waktu, nonce, atau nilai lain lalu memanggil ValidateAdditionalData untuk memvalidasi data ini saat token divalidasi. Nama pengguna klien sudah disematkan dalam token yang dihasilkan, sehingga tidak perlu menyertakan informasi ini. Jika token menyertakan data tambahan tetapi tidak IAntiForgeryAdditionalDataProvider dikonfigurasi, data tambahan tidak divalidasi.

Sumber Daya Tambahan:

• Menghosting ASP.NET Core di sebuah web farm