CSRF: apa itu, cara kerjanya, contoh dan pertahanan

Jika Anda bekerja dalam pengembangan web atau keamanan, Anda pasti ingin memahami dengan jelas apa itu pemalsuan permintaan lintas situs. CSRF (Pemalsuan Permintaan Lintas Situs) Ini adalah jenis serangan siluman yang memanfaatkan sesi yang telah dimulai pengguna untuk membuat peramban mereka melakukan tindakan tanpa persetujuan mereka.

Fenomena ini bukanlah hal baru, tetapi tetap relevan karena browser secara otomatis melampirkan kredensial seperti cookie atau header ke permintaan tertentu. Server “mempercayai” pengguna dan memproses permintaan tersebut, bahkan jika permintaan tersebut dimulai oleh halaman berbahaya, iframe, atau tautan tersamar.

Apa itu CSRF dan mengapa masih menimbulkan masalah?

Singkatnya, CSRF terjadi saat situs A menginduksi browser pengguna terautentikasi untuk mengirim permintaan ke situs B tempat pengguna tersebut sudah masuk, sehingga B memproses operasi tersebut sebagai operasi yang valid. Kuncinya adalah kepercayaan situs terhadap pengguna.bukan kepercayaan pengguna terhadap situs tersebut.

Berbeda dengan XSS, yang mengeksploitasi kepercayaan pengguna pada suatu halaman untuk menyuntikkan dan mengeksekusi kode dalam konteksnya, CSRF menyalahgunakan fakta bahwa server menerima setiap permintaan yang datang disertai dengan kredensial yang valid (misalnya, cookie sesi)Kedua masalah tersebut dapat bercampur dan memperburuk dampaknya.

Sedikit sejarah dan kesulitan forensik

Kerentanan jenis ini telah diketahui sejak akhir 90-an, dan istilah CSRF/XSRF diciptakan oleh Peter Watkins pada tahun 2001. Jejak serangan biasanya mengarah ke alamat IP yang sah. dari pengguna, yang mempersulit penetapan tanggung jawab dan memerlukan analisis forensik khusus.

Selama bertahun-tahun hanya ada sedikit eksploitasi publik yang terdokumentasi dengan baik, namun masalah ini terus berulang dan muncul beberapa kali di 10 Teratas OWASP karena dampak dan frekuensinya.

Cara kerja serangan (kondisi dan alur)

Beberapa kondisi harus dipenuhi agar CSRF berhasil. Pengguna mempertahankan sesi login dengan aplikasi target; peramban secara otomatis menghubungkannya cookie, kredensial dasar/intisari, atau konteks autentikasi dalam permintaan; dan aplikasi menerima perubahan status tanpa mekanisme verifikasi tambahan.

Penyerang meyakinkan korban, melalui rekayasa sosial (email, obrolan, atau situs web yang menarik), untuk memuat halaman yang memicu permintaan jahat ke situs yang rentan. Pengguna tidak dapat berbuat apa-apa. lebih dari sekadar mengunjungi halaman: formulir yang dikirimkan sendiri, gambar yang disematkan, atau iframe cukup untuk memicu permintaan.

Vektor tipikal: GET, POST dan bahkan “disimpan”

Sayangnya, beberapa aplikasi mengubah status menggunakan GET. Dalam hal ini, Pada halaman pihak ketiga, tindakan dilakukan saat gambar dimuat. Oleh karena itu, sebagai prinsip dasar, permintaan GET tidak boleh mengubah sumber daya.

Dengan POST, vektor yang biasa adalah formulir HTML tersamar yang dikirimkan sendiri dengan JavaScript, atau yang dikirimkan pengguna karena mengira itu adalah sesuatu yang lain. Browser melampirkan cookie sesi dari domain yang sah dan server memproses perubahan (mentransfer uang, menghapus catatan, mengubah email, dll.).

Kadang-kadang kode serangan dapat disisipkan dalam situs korban sendiri (karena kelemahan tambahan), menghostingnya dalam tag IMG atau iframe. “CSRF tersimpan” ini Ini mengurangi kecurigaan karena interaksi tampak tetap dalam ranah kepercayaan.

Dampak nyata pada akun dan sistem

Konsekuensinya berkisar dari transaksi keuangan yang tidak sah hingga perubahan konfigurasi, penugasan kembali izin, atau penghapusan data. Jika korban memiliki peran administratorPenyerang dapat mengubah logika aplikasi atau mengaktifkan pintu belakang yang memengaruhi lebih banyak pengguna.

Bahkan tindakan yang tampaknya kecil, seperti mengubah alamat email profil, dapat memblokir pemulihan akun atau memfasilitasi penipuan berikutnya. Masalah besarnya adalah bahwa semuanya terjadi “atas nama pengguna” dan sering kali tanpa dia sadari.

Contoh spesifik (dan sangat umum)

Bayangkan panel administrasi yang memungkinkan Anda menghapus pengguna dengan permintaan GET menggunakan URL seperti /users/delete/63. Jika administrator yang terautentikasi mengunjungi halaman pihak ketiga yang berisi Peramban akan membuat permintaan dan akun tersebut akan hilang.

Klasik lainnya: perbankan online. Jika transfer dapat diatur dengan GET—misalnya, /transfer?jumlah=500&akun=XXXX—tautan yang tampaknya tidak berbahaya sudah cukup bagi pengguna yang masuk untuk memicu transfer uang ke akun penyerang.

Dengan POST polanya serupa: formulir tersembunyi dengan kolom “jumlah” dan “akun” secara otomatis dikirimkan saat halaman dimuat. cookie sesi bank dari domain yang sah dan server memproses transfer.

Faktor browser dan protokol

Menggunakan HTTPS tidak mencegah serangan itu sendiri: situs berbahaya dapat dengan mudah mengarahkan browser untuk membuat permintaan yang aman. Otentikasi Dasar dan Digest juga rentanSetelah pengguna diautentikasi, browser secara otomatis meneruskan kredensial hingga sesi berakhir.

Kebijakan cookie SameSite memang membantu, tetapi ada beberapa nuansa. Dengan SameSite=Strict, browser tidak akan mengirimkan cookie dalam konteks lintas situs dan Sebagian besar CSRF terpotong di akarnya.Namun, dengan SameSite=None (dan Aman), cookie berpindah antar situs dan meningkatkan permukaan serangan.

Praktik baik bagi pengguna

Meskipun masalahnya pada dasarnya terletak pada aplikasi, ada kebiasaan yang dapat mengurangi risiko tersebut. Keluar ketika selesaiMenghapus cookie dari waktu ke waktu, dan menghindari opsi "biarkan saya tetap masuk" akan meminimalkan jendela paparan.

Ini juga membantu untuk memisahkan tugas: gunakan satu browser untuk tugas sensitif dan yang lain untuk penelusuran umum, atau gunakan mode penyamaran untuk menghindari kredensial yang bertahan lamaEkstensi yang memblokir skrip membatasi otomatisasi (meskipun itu bukan solusi lengkap).

Langkah-langkah pertahanan aplikasi

Aturan emas pertama: jangan mengubah status dengan GETMemesan POST/PUT/DELETE untuk operasi yang mengubah sumber daya mengurangi vektor sepele seperti gambar atau tautan tersembunyi.

Pendekatan yang paling umum untuk mengurangi CSRF adalah pola token sinkronisasi: server mengeluarkan token acak unik yang ditautkan ke identitas pengguna, dan klien mengembalikannya dalam permintaan perubahan status berikutnya. Jika token tidak cocok Permintaan ditolak berdasarkan identitas dan informasi cookie.

Lapisan lain yang berguna adalah memvalidasi asal: memeriksa header Asal/Referer jika ada. Jika permintaan tidak berasal dari domain yang diharapkan, pemrosesan diblokirCatatan: Beberapa klien menyembunyikan Referrer karena kebijakan privasi, jadi verifikasi ini harus dilaksanakan dengan hati-hati.

WAF juga membantu. Solusi perusahaan, seperti F5 BIG-IP ASM atau layanan perlindungan yang terintegrasi ke dalam platform hosting, menambahkan aturan untuk mengidentifikasi dan menghentikan pola yang mencurigakan sebelum mencapai aplikasi Anda.

Batasan dan kesalahan umum dengan token

Token memberikan perlindungan jika diterapkan dengan benar. Jika aplikasi melewati proses verifikasi saat token hilang, penyerang hanya perlu mengirimkan token kosong. Menggunakan kolam renang yang dapat digunakan kembali sama berbahayanya. Daripada satu token per pengguna: cukup curi satu token yang valid untuk menyamar sebagai sesi orang lain.

Menyimpan token dalam cookie yang dapat diakses oleh JavaScript juga merupakan ide yang buruk jika tidak ada pemeriksaan dan keseimbangan: Serangan XSS dapat membacanya. dan menggunakannya kembali. Ketahanan berasal dari penggabungan cookie sesi + token dalam formulir atau header terpisah, dan memvalidasi keduanya.

Hubungan dengan SPA, token dan XSS

Dalam aplikasi dengan autentikasi berbasis token (misalnya, JWT), kirim token di header Otorisasi sebagai Pembawa dan tidak ada dalam kue Hal ini mengurangi risiko CSRF karena peramban tidak secara otomatis melampirkannya. Namun, jika terjadi serangan XSS, penyerang dapat mencurinya dari peramban. penyimpanan lokal

Oleh karena itu, selain CSRF, perlu mengamankan titik keluar server dan mencegah render HTML yang tidak lolos dan terapkan CSP. CSRF dan XSS saling memperkuat jika Anda meninggalkan celah di kedua sisi.

CSRF di ASP.NET Core: hal-hal penting bagi pengembang

ASP.NET Core menyertakan mitigasi bawaan. Formulir dengan metode="post" dapat secara otomatis menyertakan token anti-pemalsuan dalam tampilan Razor (TagHelper dan helper seperti BeginForm menyisipkannya secara default). Anda juga dapat menyuntikkannya secara eksplisit. dan validasi di server dengan filter.

Validasi diaktifkan dengan atribut seperti ValidateAntiForgeryToken atau, lebih mudahnya, AutoValidateAntiforgeryToken, yang memerlukan token dalam metode yang tidak aman (POST/PUT/DELETE) dan menghindari persyaratannya dalam GET/HEAD/OPTIONS/TRACE. Jika Anda membutuhkan pengecualian, IgnoreAntiforgeryToken membatalkan persyaratan untuk tindakan konkret.

Untuk API dan SPA, layanan IAntiforgery memungkinkan Anda untuk menghasilkan dan menyimpan token, dan menerimanya dalam header khusus (misalnya, Token X-XSRFKerangka kerja seperti Angular secara konvensional membaca cookie “XSRF-TOKEN” dan mengirimkan nilainya di header tersebut, yang harus divalidasi oleh server.

API minimal dapat memvalidasi token secara eksplisit (dari middleware atau filter titik akhir), dan disarankan untuk menjalankan middleware anti-pemalsuan. setelah otentikasi dan otorisasimenghindari pembacaan yang tidak perlu terhadap isi permintaan jika tidak sesuai.

Konfigurasi halus: AntiforgeryOptions memungkinkan Anda menyesuaikan nama bidang tersembunyi, header yang diharapkan, dan apakah header X-Frame-Options dipancarkan (SAMEORIGIN secara default). Selama pengembangan, merek Secure terkadang menjadi kurang menonjol. cookie; dalam lingkungan dunia nyata, disarankan untuk memaksakan HTTPS.

Perlu diingat bahwa dengan pola token sinkronisasi, membuka banyak tab dan menavigasi melalui alur yang berbeda dapat membatalkan token sebelumnya: hanya halaman terbaru Biasanya memiliki token yang valid. Pertimbangkan alternatif jika UX Anda bergantung pada beberapa tab yang dibuka bersamaan.

Area lain yang perlu diwaspadai adalah hosting bersama di bawah domain atau subdomain yang sama. Bagikan *.domain.com Hal ini dapat memungkinkan satu aplikasi mengganggu kuki aplikasi lain, sehingga memisahkan aplikasi berdasarkan domain yang berbeda akan meningkatkan isolasi.

Terakhir, otentikasi Windows (NTLM/Kerberos) tidak mengecualikan Anda: browser secara implisit mengirimkan konteks autentikasi dan, tanpa token atau pemeriksaan asal, CSRF juga mungkin hadir.

CDN, cross-loading, dan mengapa Anda perlu berhati-hati

Merupakan hal yang umum bagi suatu situs untuk meminta konten dari pihak ketiga (video YouTube, pustaka CDN, dll.). Jika pertukaran tersebut tidak dikontrol dengan baikSeorang penyerang dapat memanfaatkan rute lintas situs untuk memaksakan permintaan yang akan diselesaikan oleh browser dengan kredensial terlampir.

Selain kebijakan cookie yang ketat, tinjau penggunaan iframe dan objek yang disematkan, dan terapkan SRI saat menggunakan CDN. batas asal usul yang diterima dengan CSP dan CORS yang terdefinisi dengan baik.

Praktik ekstra baik untuk tim

Tetapkan tinjauan keamanan untuk perubahan formulir dan titik akhir yang mengubah status. Otomatisasi pengujian yang memverifikasi keberadaan dan validasi token yang benar, dan menandai sebagai “memblokir” setiap regresi yang memperkenalkan kembali GET dengan efek samping.

Ini menggunakan pencatatan untuk mendeteksi pola yang tidak biasa (misalnya, pengiriman formulir tanpa token, atau dengan header sumber yang tidak terduga) dan Dukungan dengan WAF yang mengurangi kebisingan dan memblokir praktik eksploitatif yang diketahui.

Pengingat utama: apa yang tidak dapat diselesaikan hanya dengan CSRF

Token anti-pemalsuan tidak memperbaiki injeksi skrip; juga tidak menggantikan kontrol otorisasi. Pertama, verifikasi bahwa pengguna dapat melakukan tindakan tersebutKemudian validasi token dan, jika perlu, periksa Asal/Referor. Pertahanan berlapis adalah prioritas.

Dan jangan lupa untuk mengomunikasikan “mengapa” kepada tim produk: menghindari permintaan GET yang mengubah status atau memerlukan token tambahan dalam operasi tertentu bukanlah keinginan teknis, Ini adalah perlindungan langsung terhadap bisnis terhadap penipuan dan manipulasi.

Yang membuat CSRF berbahaya adalah sifatnya yang tersembunyi: permintaan berasal dari peramban korban, menggunakan kredensial mereka, dan tampak sah. token yang diimplementasikan dengan baikValidasi asal, kebijakan cookie yang tepat, desain REST yang bertanggung jawab dan, jika sesuai, perlindungan WAF, secara drastis mengurangi jendela serangan tanpa mengorbankan pengalaman pengguna.