Panduan mitigasi ancaman untuk ASP.NET Penyajian sisi server statis Inti Blazor

Artikel ini menjelaskan pertimbangan keamanan yang harus diperhitungkan pengembang saat mengembangkan Blazor Web Apps dengan penyajian sisi server statis.

Blazor menggabungkan tiga model berbeda dalam satu untuk menulis aplikasi web interaktif. Penyajian sisi server tradisional, yang merupakan model permintaan/respons berdasarkan HTTP. Penyajian sisi server interaktif, yang merupakan model penyajian berdasarkan SignalR. Terakhir, penyajian sisi klien, yang merupakan model penyajian berdasarkan WebAssembly.

Semua pertimbangan keamanan umum yang ditentukan untuk mode penyajian interaktif berlaku untuk Blazor Web Apps ketika ada komponen interaktif yang dirender di salah satu mode render yang didukung. Bagian berikut menjelaskan pertimbangan keamanan khusus untuk penyajian sisi server non-interaktif di Blazor Web Apps dan aspek spesifik yang berlaku saat mode render berinteraksi satu sama lain.

Pertimbangan umum untuk penyajian sisi server

Model penyajian sisi server (SSR) didasarkan pada model permintaan/respons tradisional HTTP. Dengan demikian, ada area umum yang menjadi perhatian antara SSR dan HTTP permintaan/respons. Pertimbangan keamanan umum dan ancaman tertentu harus berhasil dimitigasi. Kerangka kerja ini menyediakan mekanisme bawaan untuk mengelola beberapa ancaman ini, tetapi ancaman lain khusus untuk kode aplikasi dan harus ditangani oleh aplikasi. Ancaman ini dapat dikategorikan sebagai berikut:

• Autentikasi dan otorisasi: Aplikasi harus memastikan bahwa pengguna diautentikasi dan diotorisasi untuk mengakses aplikasi dan sumber daya yang dieksposnya. Kerangka kerja ini menyediakan mekanisme bawaan untuk autentikasi dan otorisasi, tetapi aplikasi harus memastikan bahwa mekanisme dikonfigurasi dan digunakan dengan benar. Mekanisme bawaan untuk autentikasi dan otorisasi tercakup dalam Blazor simpul keamanan Server dokumentasi dan dalam dokumentasi ASP.NET Core Keamanan dan Identity simpul, sehingga tidak akan tercakup di sini.

• Validasi dan sanitasi input: Semua input yang tiba dari klien harus divalidasi dan dibersihkan sebelum digunakan. Jika tidak, aplikasi mungkin terpapar serangan, seperti injeksi SQL, scripting lintas situs, pemalsuan permintaan lintas situs, pengalihan terbuka, dan bentuk serangan lainnya. Input mungkin berasal dari mana saja dalam permintaan.

• Manajemen sesi: Mengelola sesi pengguna dengan benar sangat penting untuk memastikan bahwa aplikasi tidak terpapar serangan, seperti fiksasi sesi, pembajakan sesi, dan serangan lainnya. Informasi yang disimpan dalam sesi harus dilindungi dan dienkripsi dengan benar, dan kode aplikasi harus mencegah pengguna berbahaya menebak atau memanipulasi sesi.

• Penanganan kesalahan dan pengelogan: Aplikasi harus memastikan bahwa kesalahan ditangani dan dicatat dengan benar. Jika tidak, aplikasi mungkin terpapar serangan, seperti pengungkapan informasi. Ini dapat terjadi ketika aplikasi mengembalikan informasi sensitif dalam respons atau ketika aplikasi mengembalikan pesan kesalahan terperinci dengan data yang dapat digunakan untuk menyerang aplikasi.

• Perlindungan data: Data sensitif harus dilindungi dengan benar, yang mencakup logika aplikasi saat berjalan di WebAssembly, karena dapat dengan mudah direkayasa balik.

• Penolakan layanan: Aplikasi harus memastikan bahwa aplikasi tidak terpapar serangan, seperti penolakan layanan. Ini terjadi misalnya, ketika aplikasi tidak dilindungi dengan benar dari serangan brute force atau ketika tindakan dapat menyebabkan aplikasi mengonsumsi terlalu banyak sumber daya.

Validasi dan sanitasi input

Semua input yang tiba dari klien harus dianggap tidak tepercaya kecuali informasinya dihasilkan dan dilindungi di server, seperti token CSRF, autentikasi cookie, pengidentifikasi sesi, atau payload lain yang dilindungi dengan enkripsi terautentikasi.

Input biasanya tersedia untuk aplikasi melalui proses pengikatan, misalnya melalui [SupplyParameterFromQuery] atribut atau [SupplyParameterFromForm] atribut. Sebelum memproses input ini, aplikasi harus memastikan bahwa data valid. Misalnya, aplikasi harus mengonfirmasi bahwa tidak ada kesalahan pengikatan saat memetakan data formulir ke properti komponen. Jika tidak, aplikasi mungkin memproses data yang tidak valid.

Jika input digunakan untuk melakukan pengalihan, aplikasi harus memastikan bahwa input valid dan tidak menunjuk ke domain yang dianggap tidak valid atau ke subpath yang tidak valid dalam jalur dasar aplikasi. Jika tidak, aplikasi mungkin terkena serangan pengalihan terbuka, di mana penyerang dapat membuat tautan yang mengarahkan pengguna ke situs berbahaya.

Jika input digunakan untuk melakukan kueri database, aplikasi harus mengonfirmasi bahwa input valid dan tidak mengekspos aplikasi ke serangan injeksi SQL. Jika tidak, penyerang mungkin dapat membuat kueri berbahaya yang dapat digunakan untuk mengekstrak informasi dari database atau untuk mengubah database.

Data yang mungkin berasal dari input pengguna juga harus dibersihkan sebelum disertakan dalam respons. Misalnya, input mungkin berisi HTML atau JavaScript yang dapat digunakan untuk melakukan serangan scripting lintas situs, yang dapat digunakan untuk mengekstrak informasi dari pengguna atau untuk melakukan tindakan atas nama pengguna.

Kerangka kerja ini menyediakan mekanisme berikut untuk membantu validasi input dan sanitasi:

• Semua data formulir terikat divalidasi untuk kebenaran dasar. Jika input tidak dapat diurai, proses pengikatan melaporkan kesalahan yang dapat ditemukan aplikasi sebelum mengambil tindakan apa pun dengan data. Komponen bawaan EditForm memperhitungkan ini sebelum memanggil OnValidSubmit panggilan balik formulir. Blazor menghindari menjalankan panggilan balik jika ada satu atau beberapa kesalahan pengikatan.
• Kerangka kerja menggunakan token antiforgery untuk melindungi dari serangan pemalsuan permintaan lintas situs. Untuk informasi selengkapnya, lihat ringkasan autentikasi dan otorisasi core ASP.NET Blazor Core dan formulir ASP.NET CoreBlazor.

Semua input dan izin harus divalidasi di server pada saat melakukan tindakan tertentu untuk memastikan bahwa data valid dan akurat pada saat itu dan bahwa pengguna diizinkan untuk melakukan tindakan. Pendekatan ini konsisten dengan panduan keamanan yang disediakan untuk penyajian sisi server interaktif.

Manajemen sesi

Manajemen sesi ditangani oleh kerangka kerja. Kerangka kerja menggunakan sesi cookie untuk mengidentifikasi sesi pengguna. Sesi cookie dilindungi menggunakan API Perlindungan Data Inti ASP.NET. Sesi cookie tidak dapat diakses oleh kode JavaScript yang berjalan di browser dan tidak dapat dengan mudah ditebak atau dimanipulasi oleh pengguna.

Sehubungan dengan data sesi lain, seperti data yang disimpan dalam layanan, data sesi harus disimpan dalam layanan terlingkup, karena layanan terlingkup unik per sesi pengguna tertentu, dibandingkan dengan layanan singleton yang dibagikan di semua sesi pengguna dalam instans proses tertentu.

Ketika datang ke SSR, tidak ada banyak perbedaan antara layanan terlingkup dan sementara dalam kebanyakan kasus, karena masa pakai layanan terbatas pada satu permintaan. Ada perbedaan dalam dua skenario:

• Jika layanan disuntikkan di lebih dari satu lokasi atau pada waktu yang berbeda selama permintaan.
• Jika layanan mungkin digunakan dalam konteks server interaktif, di mana layanan bertahan dari beberapa render dan dasarnya bahwa layanan dicakup ke sesi pengguna.

Penanganan kesalahan dan pengelogan

Kerangka kerja ini menyediakan pengelogan bawaan untuk aplikasi di tingkat kerangka kerja. Kerangka kerja mencatat peristiwa penting, seperti ketika token antiforgery untuk formulir gagal divalidasi, ketika komponen root mulai dirender, dan ketika tindakan dikirim. Aplikasi ini bertanggung jawab untuk mencatat peristiwa lain yang mungkin penting untuk direkam.

Kerangka kerja ini menyediakan penanganan kesalahan bawaan untuk aplikasi di tingkat kerangka kerja. Kerangka kerja menangani kesalahan yang terjadi selama penyajian komponen dan menggunakan mekanisme batas kesalahan untuk menampilkan pesan kesalahan yang ramah atau memungkinkan kesalahan untuk menggelegak hingga middleware penanganan pengecualian, yang dikonfigurasi untuk merender halaman kesalahan.

Kesalahan yang terjadi selama penyajian streaming setelah respons mulai dikirim ke klien ditampilkan dalam respons akhir sebagai pesan kesalahan generik. Detail tentang penyebab kesalahan hanya disertakan selama pengembangan.

Perlindungan data

Kerangka kerja ini menawarkan mekanisme untuk melindungi informasi sensitif untuk sesi pengguna tertentu dan memastikan bahwa komponen bawaan menggunakan mekanisme ini untuk melindungi informasi sensitif, seperti melindungi identitas pengguna saat menggunakan cookie autentikasi. Di luar skenario yang ditangani oleh kerangka kerja, kode pengembang bertanggung jawab untuk melindungi informasi khusus aplikasi lainnya. Cara paling umum untuk melakukan ini adalah melalui API Perlindungan Data Inti ASP.NET atau bentuk enkripsi lainnya. Sebagai aturan umum, aplikasi bertanggung jawab untuk:

• Memastikan bahwa pengguna tidak dapat memeriksa atau memodifikasi informasi privat pengguna lain.
• Memastikan bahwa pengguna tidak dapat memodifikasi data pengguna lain, seperti pengidentifikasi internal.

Sehubungan dengan perlindungan data, Anda harus memahami dengan jelas di mana kode dijalankan. Untuk penyajian sisi server statis (SSR statis) dan penyajian sisi server interaktif (SSR interaktif), kode disimpan di server dan tidak pernah mencapai klien. Untuk mode render Interactive WebAssembly, kode aplikasi selalu menjangkau klien, yang berarti bahwa informasi sensitif apa pun yang disimpan dalam kode aplikasi tersedia untuk siapa saja yang memiliki akses ke aplikasi. Obfuscation dan teknik serupa lainnya untuk "melindungi" kode tidak efektif. Setelah kode mencapai klien, kode dapat direkayasa balik untuk mengekstrak informasi sensitif.

Penolakan layanan

Pada tingkat server, kerangka kerja menyediakan batasan parameter permintaan/respons, seperti ukuran maksimum permintaan dan ukuran header. Sehubungan dengan kode aplikasi, Blazorsistem pemetaan formulir mendefinisikan batas yang mirip dengan yang ditentukan oleh sistem pengikatan model MVC:

• Batasi jumlah maksimum kesalahan.
• Batasi kedalaman rekursi maksimum untuk pengikat.
• Batasi jumlah maksimum elemen yang terikat dalam koleksi.

Selain itu, ada batasan yang ditentukan untuk formulir, seperti ukuran kunci formulir maksimum dan ukuran nilai dan jumlah maksimum entri.

Secara umum, aplikasi harus mengevaluasi ketika ada kemungkinan permintaan memicu jumlah pekerjaan asimetris oleh server. Contohnya termasuk ketika pengguna mengirim permintaan yang diparameterkan oleh N dan server melakukan operasi sebagai respons yang N kali lebih mahal, di mana N adalah parameter yang dikontrol pengguna dan dapat tumbuh tanpa batas waktu. Biasanya, aplikasi harus memberlakukan batas pada N maksimum yang bersedia diproses atau memastikan bahwa operasi apa pun kurang, sama, atau lebih mahal daripada permintaan dengan faktor konstan.

Aspek ini lebih berkaitan dengan perbedaan pertumbuhan antara pekerjaan yang dilakukan klien dan pekerjaan yang dilakukan server daripada dengan perbandingan 1→N tertentu. Misalnya, klien mungkin mengirimkan item kerja (memasukkan elemen ke dalam daftar) yang membutuhkan waktu N unit untuk melakukan, tetapi server membutuhkan N^2^ untuk memproses (karena mungkin melakukan sesuatu yang sangat naif). Ini adalah perbedaan antara N dan N^2^ yang penting.

Dengan demikian, ada batasan berapa banyak pekerjaan yang harus dilakukan server, yang khusus untuk aplikasi. Aspek ini berlaku untuk beban kerja sisi server, karena sumber daya ada di server, tetapi tidak selalu berlaku untuk beban kerja WebAssembly pada klien dalam banyak kasus.

Aspek penting lainnya adalah bahwa ini tidak hanya dicadangkan untuk waktu CPU. Ini juga berlaku untuk sumber daya apa pun, seperti memori, jaringan, dan ruang pada disk.

Untuk beban kerja WebAssembly, biasanya ada sedikit kekhawatiran atas jumlah pekerjaan yang dilakukan klien, karena klien biasanya dibatasi oleh sumber daya yang tersedia pada klien. Namun, ada beberapa skenario di mana klien mungkin terpengaruh, jika misalnya, aplikasi menampilkan data dari pengguna lain dan satu pengguna mampu menambahkan data ke sistem yang memaksa klien yang menampilkan data untuk melakukan sejumlah pekerjaan yang tidak sebanding dengan jumlah data yang ditambahkan oleh pengguna.

Daftar pemeriksaan yang direkomendasikan (tidak lengkap)

• Pastikan bahwa pengguna diautentikasi dan diotorisasi untuk mengakses aplikasi dan sumber daya yang dieksposnya.
• Validasi dan bersihkan semua input yang berasal dari klien sebelum menggunakannya.
• Kelola sesi pengguna dengan benar untuk memastikan bahwa status tidak salah dibagikan di seluruh pengguna.
• Menangani dan mencatat kesalahan dengan benar untuk menghindari mengekspos informasi sensitif.
• Catat peristiwa penting di aplikasi untuk mengidentifikasi potensi masalah dan tindakan audit yang dilakukan oleh pengguna.
• Lindungi informasi sensitif menggunakan API Perlindungan Data Inti ASP.NET atau salah satu komponen yang tersedia (Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage, PersistentComponentState).
• Pastikan bahwa aplikasi memahami sumber daya yang dapat dikonsumsi oleh permintaan tertentu dan memiliki batasan untuk menghindari penolakan serangan layanan.