Mengamankan ASP.NET Core Blazor WebAssembly

Aplikasi Blazor WebAssembly diamankan dengan cara yang sama seperti aplikasi satu halaman (SPA). Ada beberapa pendekatan untuk mengautentikasi pengguna ke SPA, tetapi pendekatan yang paling umum dan komprehensif adalah menggunakan penerapan berdasarkan protokol OAuth 2.0, seperti OpenID Connect (OIDC).

Dokumentasi Blazor WebAssembly keamanan terutama berfokus pada cara menyelesaikan tugas autentikasi dan otorisasi pengguna. Untuk cakupan konsep umum OAuth 2.0/OIDC, lihat sumber daya di bagian Gambaran umum utama Sumber daya tambahan.

Keamanan sisi klien/SPA dari data dan kredensial sensitif

Basis Blazor WebAssembly kode .NET/C# aplikasi disajikan kepada klien, dan kode aplikasi tidak dapat dilindungi dari inspeksi dan perubahan oleh pengguna. Jangan pernah menempatkan data sensitif ke dalam aplikasi Blazor WebAssembly, seperti rahasia aplikasi, string koneksi, kata sandi, kunci keamanan, dan kode .NET/C# privat.

Teknologi berikut berguna untuk menyimpan data sensitif, yang dapat digunakan bersama-sama dalam aplikasi yang sama untuk membagi tanggung jawab untuk menyimpan data antara lingkungan Pengembangan dan Penahapan/Produksi:

• alat Secret Manager: Hanya digunakan pada sistem pengembangan lokal.
• Azure Key Vault: Dapat digunakan untuk aplikasi yang berjalan secara lokal di lingkungan dari Pengembangan dan untuk penyebaran Tahap/Produksi.

Untuk contoh pendekatan sebelumnya, lihat konfirmasi Akun dan pemulihan kata sandi di ASP.NET Core Blazor WebAssembly dengan ASP.NET Core Identity.

Permintaan API Web

Untuk melindungi kode dan data .NET/C#, gunakan fitur ASP.NET Core Data Protection dengan API web backend ASP.NET Core sisi server. Aplikasi Blazor WebAssembly sisi klien memanggil API web sisi server untuk fitur aplikasi yang aman dan pemrosesan data. Untuk informasi selengkapnya, lihat Memanggil API web dari aplikasi Blazor ASP.NET Core serta artikel dan contoh dalam node dokumentasi ini.

Aplikasi Blazor WebAssembly sering dicegah untuk melakukan panggilan langsung lintas asal ke API web karena kebijakan keamanan Cross-Origin Resource Sharing (CORS) . Pengecualian umum terlihat seperti berikut ini:

Akses untuk mengambil data di '{URL}' dari asal 'https://localhost:{PORT}'' telah diblokir oleh kebijakan CORS: Tidak ada header 'Access-Control-Allow-Origin' pada sumber daya yang diakses. Jika respons buram memenuhi kebutuhan Anda, atur mode permintaan ke 'no-cors' untuk mengambil sumber daya dengan CORS dinonaktifkan.

Bahkan jika Anda memanggil SetBrowserRequestMode dengan bidang BrowserRequestMode sebesar NoCors (1) yang mencoba menghindari pengecualian sebelumnya, permintaan biasanya gagal karena larangan CORS terhadap asal API web, seperti larangan yang hanya mengizinkan panggilan dari asal tertentu atau larangan yang mencegah permintaan JavaScript fetch dari browser. Satu-satunya cara agar panggilan tersebut berhasil adalah jika API web yang Anda panggil mengizinkan asal Anda untuk memanggil asalnya dengan konfigurasi CORS yang benar. Sebagian besar API web eksternal tidak memungkinkan Anda mengonfigurasi kebijakan CORS mereka. Untuk menangani pembatasan ini, adopsi salah satu strategi berikut:

• Pertahankan API web backend ASP.NET Core sisi server Anda sendiri. Aplikasi Blazor WebAssembly sisi klien memanggil API web sisi server Anda, dan API web Anda membuat permintaan dari kode C# berbasis server (bukan browser) ke API web eksternal dengan header CORS yang benar, mengembalikan hasilnya ke aplikasi Blazor WebAssembly sisi klien Anda.

• Gunakan layanan proksi untuk mem-proksi permintaan dari aplikasi Blazor WebAssembly sisi klien ke API web eksternal. Layanan proksi menggunakan aplikasi sisi server untuk membuat permintaan atas nama klien dan mengembalikan hasilnya setelah panggilan berhasil. Dalam contoh berikut yang berdasarkan CORS PROXYdari CloudFlare, placeholder {REQUEST URI} adalah URI permintaan:

  @using System.Net
  @inject IHttpClientFactory ClientFactory
  
  ...
  
  @code {
      public async Task CallApi()
      {
          var client = ClientFactory.CreateClient();
  
          var urlEncodedRequestUri = WebUtility.UrlEncode("{REQUEST URI}");
  
          using var request = new HttpRequestMessage(HttpMethod.Get, 
              $"https://corsproxy.io/?{urlEncodedRequestUri}");
  
          using var response = await client.SendAsync(request);
  
          ...
      }
  }
  

Pustaka autentikasi

Blazor WebAssembly mendukung autentikasi dan otorisasi aplikasi menggunakan OIDC melalui pustaka Microsoft.AspNetCore.Components.WebAssembly.Authentication menggunakan platform identitas Microsoft . Pustaka menyediakan satu set primitif untuk mengautentikasi backend ASP.NET Core dengan lancar. Pustaka dapat mengautentikasi Penyedia (IP) pihak ketiga Identity mana pun yang mendukung OIDC, yang disebut Penyedia OpenID (OP).

Dukungan autentikasi di Blazor WebAssembly Pustaka (Authentication.js) dibangun di atas Microsoft Authentication Library (MSAL, msal.js), yang digunakan untuk menangani detail protokol autentikasi yang mendasar. Blazor WebAssembly Pustaka hanya mendukung alur kode otorisasi Proof Key for Code Exchange (PKCE). Pemberian implisit tidak didukung.

Opsi lain untuk mengautentikasi SPAs ada, seperti penggunaan cookie SameSite. Namun, desain Blazor WebAssembly rekayasa menggunakan OAuth dan OIDC sebagai opsi terbaik untuk autentikasi di Blazor WebAssembly aplikasi. Autentikasi berbasis token berdasarkan JSON Web Tokens (JWTs) dipilih melalui cookieautentikasi berbasis karena alasan fungsional dan keamanan:

• Menggunakan protokol berbasis token menawarkan lebih sedikit kerentanan, karena token tidak dikirim di semua permintaan.
• Token secara eksplisit dikirim ke server, sehingga titik akhir server tidak memerlukan perlindungan terhadap Pemalsuan Permintaan Lintas Situs (CSRF). Hal ini memungkinkan Anda menghosting aplikasi Blazor WebAssembly bersama MVC atau aplikasi halaman Razor.
• Token memiliki izin yang lebih sempit daripada cookie. Misalnya, token tidak dapat digunakan untuk mengelola akun pengguna atau mengubah kata sandi pengguna kecuali fungsi tersebut diterapkan secara eksplisit.
• Token memiliki masa pakai yang singkat, satu jam, yang membatasi jendela serangan. Token juga dapat dicabut kapan saja.
• JWT mandiri menawarkan jaminan kepada klien dan server tentang proses autentikasi. Misalnya, klien memiliki sarana untuk mendeteksi dan memvalidasi bahwa token yang diterimanya sah dan dikeluarkan sebagai bagian dari proses autentikasi yang diberikan. Jika pihak ketiga mencoba untuk mengganti token di tengah proses autentikasi, klien dapat mendeteksi token yang dialihkan dan menghindari menggunakannya.
• Token dengan OAuth dan OIDC tidak bergantung pada agen pengguna yang berperilaku benar untuk memastikan bahwa aplikasi tersebut aman.
• Protokol berbasis token, seperti OAuth dan OIDC, memungkinkan untuk mengautentikasi dan mengotorisasi pengguna di aplikasi Webassembly mandiri Blazor dengan serangkaian karakteristik keamanan yang sama.

Penting

Untuk versi ASP.NET Core yang mengadopsi Duende Identity Server dalam Blazor templat proyek, Duende Software mungkin mengharuskan Anda membayar biaya lisensi untuk penggunaan produksi Duende Identity Server. Untuk informasi selengkapnya, lihat Migrasi dari ASP.NET Core di .NET 5 ke .NET 6.

Proses autentikasi dengan OIDC

Pustaka Microsoft.AspNetCore.Components.WebAssembly.Authentication menawarkan beberapa primitif untuk menerapkan autentikasi dan otorisasi menggunakan OIDC. Secara umum, autentikasi berfungsi sebagai berikut:

• Saat pengguna anonim memilih tombol masuk atau meminta Razor komponen atau halaman dengan [Authorize] atribut yang diterapkan, pengguna dialihkan ke halaman masuk aplikasi (/authentication/login).
• Di halaman masuk, pustaka autentikasi mempersiapkan pengalihan ke titik akhir otorisasi. Titik akhir otorisasi berada di luar aplikasi Blazor WebAssembly dan dapat dihosting di asal yang terpisah. Titik akhir bertanggung jawab untuk menentukan apakah pengguna diautentikasi dan untuk mengeluarkan satu atau beberapa token sebagai respons. Pustaka autentikasi menyediakan panggilan balik masuk untuk menerima respons autentikasi.
  • Jika pengguna tidak diautentikasi, pengguna akan diarahkan ke sistem autentikasi yang mendasarinya, yang biasanya adalah ASP.NET Core Identity.
  • Jika pengguna telah diautentikasi, titik akhir otorisasi akan menghasilkan token yang sesuai dan mengalihkan browser kembali ke titik akhir panggilan balik masuk (/authentication/login-callback).
• Saat aplikasi Blazor WebAssembly memuat titik akhir panggilan balik masuk (/authentication/login-callback), respons autentikasi diproses.
  • Jika proses autentikasi berhasil diselesaikan, pengguna diautentikasi dan secara opsional dikirim kembali ke URL asli yang dilindungi yang diminta pengguna.
  • Jika proses autentikasi gagal karena alasan apa pun, pengguna dikirim ke halaman gagal masuk (/authentication/login-failed), tempat kesalahan ditampilkan.

Authentication komponen

Komponen Authentication (Authentication.razor) menangani operasi autentikasi jarak jauh dan mengizinkan aplikasi untuk:

• Mengonfigurasi rute aplikasi untuk status autentikasi.
• Mengatur konten UI untuk status autentikasi.
• Mengelola status autentikasi.

Tindakan autentikasi, seperti mendaftarkan atau memasukkan pengguna, diteruskan ke komponen Blazor kerangka kerja RemoteAuthenticatorViewCore<TAuthenticationState>, yang tetap ada dan mengontrol status di seluruh operasi autentikasi.

Untuk informasi dan contoh selengkapnya, lihat skenario keamanan tambahan Blazor WebAssembly ASP.NET Core.

Otorisasi

Di aplikasi Blazor WebAssembly, pemeriksaan otorisasi dapat dilewati karena semua kode sisi klien dapat dimodifikasi oleh pengguna. Hal yang sama berlaku untuk semua teknologi aplikasi sisi klien, termasuk kerangka kerja SPA JavaScript atau aplikasi native untuk sistem operasi apa pun.

Selalu lakukan pemeriksaan otorisasi pada server dalam setiap titik akhir API yang diakses oleh aplikasi sisi klien Anda.

Menyesuaikan autentikasi

Blazor WebAssembly menyediakan metode untuk menambahkan dan mengambil parameter tambahan untuk pustaka Autentikasi yang mendasar untuk melakukan operasi autentikasi jarak jauh dengan penyedia identitas eksternal.

Untuk meneruskan parameter tambahan, NavigationManager mendukung melewati dan mengambil status entri riwayat saat melakukan perubahan lokasi eksternal. Untuk informasi selengkapnya, lihat sumber daya berikut:

• Blazor >Artikel Perutean dan navigasi Dasar
  • Status riwayat navigasi
  • Opsi navigasi
• Dokumentasi MDN: API Riwayat

Status yang disimpan oleh API Riwayat memberikan manfaat berikut untuk autentikasi jarak jauh:

• Status yang diteruskan ke titik akhir aplikasi yang diamankan terkait dengan navigasi yang dilakukan untuk mengautentikasi pengguna di titik akhir authentication/login.
• Pengodean dan pendekodean data kerja tambahan dihindari.
• Kerentanan berkurang. Tidak seperti menggunakan string kueri untuk menyimpan status navigasi, navigasi tingkat atas atau pengaruh dari asal yang berbeda tidak dapat mengatur status yang disimpan oleh API Riwayat.
• Entri riwayat diganti setelah autentikasi berhasil, sehingga status yang dilampirkan ke entri riwayat dihapus dan tidak memerlukan pembersihan.

InteractiveRequestOptions mewakili permintaan kepada Penyedia Identitas untuk masuk atau menyediakan token akses.

NavigationManagerExtensions menyediakan metode NavigateToLogin untuk operasi masuk dan NavigateToLogout untuk operasi keluar. Metode memanggil NavigationManager.NavigateTo, mengatur status entri riwayat dengan InteractiveRequestOptions yang diteruskan atau instans InteractiveRequestOptions baru yang dibuat oleh metode untuk:

• Pengguna yang masuk (InteractionType.SignIn) dengan URI saat ini untuk URL pengembalian.
• Pengguna yang keluar (InteractionType.SignOut) dengan URL pengembalian.

Skenario autentikasi berikut dibahas dalam artikel Blazor WebAssemblyskenario keamanan tambahan ASP.NET Core:

• Menyesuaikan proses masuk
• Keluar dengan URL pengembalian kustom
• Menyesuaikan opsi sebelum mendapatkan token secara interaktif
• Menyesuaikan opsi saat menggunakan IAccessTokenProvider
• Mendapatkan jalur masuk dari opsi autentikasi

Memerlukan otorisasi untuk seluruh aplikasi

Terapkan atribut (dokumentasi[Authorize]

• Dalam file Impor aplikasi, tambahkan arahan @using untuk namespace Microsoft.AspNetCore.Authorization dengan arahan @attribute untuk atribut [Authorize].

  _Imports.razor:

  @using Microsoft.AspNetCore.Authorization
  @attribute [Authorize]
  

  Izinkan akses anonim ke komponen Authentication untuk memungkinkan pengalihan ke penyedia identitas. Tambahkan kode Razor berikut ke komponen Authentication di bagian arahan @page-nya.

  Authentication.razor:

  @using Microsoft.AspNetCore.Components.WebAssembly.Authentication
  @attribute [AllowAnonymous]
  

• Tambahkan atribut ke setiap Razor komponen di bawah arahan @page :

  @using Microsoft.AspNetCore.Authorization
  @attribute [Authorize]
  

Catatan

Mengatur AuthorizationOptions.FallbackPolicy ke kebijakan dengan RequireAuthenticatedUsertidak didukung.

Terapkan satu pendaftaran penyedia identitas per aplikasi

Beberapa artikel di bawah Gambaran Umum ini berkaitan dengan Blazor skenario hosting yang melibatkan dua aplikasi atau lebih. Aplikasi mandiri Blazor WebAssembly menggunakan API web dengan pengguna terautentikasi untuk mengakses sumber daya server dan data yang disediakan oleh aplikasi server.

Ketika skenario ini diterapkan dalam contoh dokumentasi, dua pendaftaran penyedia identitas digunakan, satu untuk aplikasi klien dan satu untuk aplikasi server. Menggunakan pendaftaran terpisah, misalnya di ID Microsoft Entra, tidak diperlukan secara ketat. Namun, menggunakan dua pendaftaran adalah praktik terbaik keamanan karena mengisolasi pendaftaran berdasarkan aplikasi. Menggunakan pendaftaran terpisah juga memungkinkan konfigurasi independen pendaftaran klien dan server.

Token refresh

Meskipun token refresh tidak dapat diamankan di Blazor WebAssembly aplikasi, token tersebut dapat digunakan jika Anda menerapkannya dengan strategi keamanan yang sesuai.

Untuk aplikasi mandiri Blazor WebAssembly di ASP.NET Core di .NET 6 atau yang lebih baru, sebaiknya gunakan:

• Alur Kode Otorisasi (Kode) OAuth 2.0 dengan Proof Key for Code Exchange (PKCE).
• Token refresh yang memiliki kedaluwarsa singkat.
• Token refresh yang diputar .
• Token refresh dengan kedaluwarsa setelah alur otorisasi interaktif baru diperlukan untuk me-refresh kredensial pengguna.

Untuk informasi selengkapnya, lihat sumber daya berikut:

• Platform identitas Microsoft token pembaruan: Masa berlaku pembaruan token
• OAuth 2.0 untuk Aplikasi Berbasis Browser (spesifikasi IETF)

Menetapkan klaim untuk pengguna

Aplikasi sering memerlukan klaim untuk pengguna berdasarkan panggilan API web ke server. Misalnya, klaim sering digunakan untuk membuat otorisasi dalam aplikasi. Dalam skenario ini, aplikasi meminta token akses untuk mengakses layanan dan menggunakan token untuk mendapatkan data pengguna untuk membuat klaim.

Sebagai contoh, lihat sumber daya berikut:

• Skenario tambahan: Menyesuaikan pengguna
• ASP.NET Core Blazor WebAssembly dengan grup dan peran ID Microsoft Entra

Dukungan pra-penyajian

Prarendering tidak didukung untuk titik akhir autentikasi (segmen jalur /authentication/).

Untuk informasi lebih lanjut, lihat skenario keamanan tambahan Blazor WebAssembly ASP.NET Core.

Azure App Service di Linux dengan Server Identity

Tentukan penerbit secara eksplisit saat menyebarkan Azure App Service di Linux dengan Server Identity.

Untuk informasi selengkapnya, lihat Menggunakan Identity untuk mengamankan backend API Web untuk SPAs.

Otentikasi Windows

Kami tidak menyarankan menggunakan Autentikasi Windows dengan Webassembly Blazor atau dengan kerangka kerja SPA lainnya. Sebaiknya gunakan protokol berbasis token, bukan Autentikasi Windows, seperti OIDC dengan Active Directory Federation Services (ADFS).

Jika Autentikasi Windows digunakan dengan Webassembly Blazor atau dengan kerangka kerja SPA lainnya, tindakan tambahan diperlukan untuk melindungi aplikasi dari token pemalsuan permintaan antar situs (CSRF). Masalah yang sama yang berlaku untuk cookie berlaku untuk Autentikasi Windows dengan penambahan bahwa Autentikasi Windows tidak menawarkan mekanisme untuk mencegah berbagi konteks autentikasi di seluruh asal. Aplikasi yang menggunakan Autentikasi Windows tanpa perlindungan tambahan dari CSRF setidaknya harus dibatasi untuk intranet organisasi dan tidak digunakan di Internet terbuka.

Untuk informasi selengkapnya, lihat Mencegah serangan Pemalsuan Permintaan Antar Situs (XSRF/CSRF) di ASP.NET Core.

Mengamankan hub SignalR

Untuk mengamankan SignalR hub dalam proyek API server, terapkan [Authorize] atribut ke kelas hub atau ke metode kelas hub.

Dalam proyek klien dengan pra-penyajian, seperti yang dihosting Blazor WebAssembly (ASP.NET Core di .NET 7 atau yang lebih lama) atau Blazor Web App (ASP.NET Core di .NET 8 atau yang lebih baru), lihat panduan dalam Blazor ASP.NET CoreSignalR.

Dalam komponen proyek klien tanpa prarender, seperti aplikasi mandiri Blazor WebAssembly, atau non-browser, berikan token akses ke koneksi hub, seperti yang ditunjukkan contoh berikut. Untuk informasi selengkapnya, lihat Autentikasi dan otorisasi di ASP.NET Core SignalR.

@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@inject IAccessTokenProvider TokenProvider
@inject NavigationManager Navigation

...

var tokenResult = await TokenProvider.RequestAccessToken();

if (tokenResult.TryGetToken(out var token))
{
    hubConnection = new HubConnectionBuilder()
        .WithUrl(Navigation.ToAbsoluteUri("/chathub"), 
            options => { options.AccessTokenProvider = () => Task.FromResult(token?.Value); })
        .Build();

  ...
}

Pencatatan

Bagian ini berlaku untuk Blazor WebAssembly aplikasi di ASP.NET Core di .NET 7 atau yang lebih baru.

Untuk mengaktifkan pembuatan log debug atau pelacakan, lihat bagian Pengelogan autentikasi (Blazor WebAssembly) di .NET 7 atau versi yang lebih baru dari artikel pengelogan ASP.NET CoreBlazor.

Kotak pasir WebAssembly

Kotak pasir WebAssembly membatasi akses ke lingkungan sistem yang menjalankan kode WebAssembly, termasuk akses ke subsistem I/O, penyimpanan sistem dan sumber daya, dan sistem operasi. Isolasi antara kode WebAssembly dan sistem yang menjalankan kode menjadikan WebAssembly kerangka kerja pengkodean yang aman untuk sistem. Namun, WebAssembly rentan terhadap serangan saluran samping di tingkat perangkat keras. Tindakan pencegahan normal dan uji tanggap dalam sumber perangkat keras dan menempatkan batasan dalam mengakses perangkat keras berlaku.

WebAssembly tidak dimiliki atau dikelola oleh Microsoft.

Untuk informasi selengkapnya, lihat sumber daya W3C berikut ini:

• WebAssembly: Keamanan
• Spesifikasi WebAssembly: Pertimbangan Keamanan
• W3C WebAssembly Community Group: Umpan balik dan masalah: Tautan Grup Komunitas W3C WebAssembly hanya disediakan untuk referensi, sehingga jelas bahwa kerentanan dan bug keamanan WebAssembly di-patch secara berkelanjutan, sering dilaporkan dan ditangani oleh browser. Blazor umpan balik harus dilaporkan Blazor ke unit produk Microsoft ASP.NET Core. Jika unit produk Microsoft menentukan bahwa masalah yang mendasar dengan WebAssembly ada, mereka mengambil langkah-langkah yang sesuai untuk melaporkan masalah ke Grup Komunitas W3C WebAssembly.

Panduan implementasi

Artikel di bagian Ringkasan ini memberikan informasi tentang mengautentikasi pengguna di aplikasi Blazor WebAssembly terhadap penyedia tertentu.

Aplikasi Blazor WebAssembly mandiri:

• Panduan umum untuk penyedia OIDC dan Pustaka Autentikasi WebAssembly
• Akun Microsoft
• ID Microsoft Entra (ME-ID)
• Azure Active Directory (AAD) B2C

Panduan konfigurasi lebih lanjut dapat ditemukan di artikel berikut:

• Skenario keamanan tambahan Blazor WebAssembly ASP.NET Core
• Menggunakan API Graph dengan ASP.NET Core Blazor WebAssembly

Menggunakan alur Kode Otorisasi dengan PKCE

Microsoft Authentication Library for JavaScript (MSAL) platform identitas Microsoft v2.0 atau yang lebih baru menyediakan dukungan untuk alur Kode Otorisasi dengan Proof Key for Code Exchange (PKCE) dan Cross-Origin Resource Sharing (CORS) untuk aplikasi satu halaman, termasuk Blazor.

Microsoft tidak merekomendasikan penggunaan pemberian implisit.

Untuk informasi selengkapnya, lihat sumber daya berikut:

• Dukungan alur autentikasi di MSAL: Pemberian implisit
• Platform identitas Microsoft dan alur grant implisit: Lebih mengutamakan alur kode otentikasi
• platform identitas Microsoft dan alur kode otorisasi OAuth 2.0

Sumber Daya Tambahan:

• Dokumentasi platform identitas Microsoft
  • Dokumentasi umum
  • Token akses
• Konfigurasikan ASP.NET Core agar berfungsi dengan server proksi dan penyeimbang beban
  • Menggunakan Forwarded Headers Middleware untuk mempertahankan informasi skema HTTPS di seluruh server proksi dan jaringan internal.
  • Skenario tambahan dan kasus penggunaan, termasuk konfigurasi skema manual, perubahan jalur permintaan untuk perutean permintaan yang benar, dan meneruskan skema permintaan untuk proksi terbalik Linux dan non-IIS.
• Pra-penyajian dengan autentikasi
• WebAssembly: Keamanan
• Spesifikasi WebAssembly: Pertimbangan Keamanan