Memahami Serangan CSRF dan Mengunci Kerentanan CSRF

Kerentanan web merajalela dan terus meningkat. Menjaga keamanan dan privasi pengguna Anda menjadi lebih penting dari sebelumnya. Tidak menangani kerentanan web dapat menyebabkan reputasi rusak dan denda besar dari regulator, dan Anda juga akan kehilangan kepercayaan pengguna.

Situs web dan aplikasi web rentan terhadap malware, spam, dan serangan lainnya — artikel ini berfokus pada salah satu vektor serangan tersebut — serangan Cross-Site Request Forgery (CSRF). Serangan CSRF sangat meresahkan karena dapat terjadi tanpa sepengetahuan pengguna. Mereka juga sulit untuk dideteksi oleh pengembang atau pemilik situs web karena permintaan jahat tampak sangat mirip dengan permintaan asli.

Artikel ini mengeksplorasi serangan CSRF, cara kerjanya, dan langkah-langkah yang dapat Anda ambil untuk mempersiapkannya.

Apa Itu Serangan CSRF?

Serangan Pemalsuan Permintaan Lintas Situs, juga dikenal sebagai serangan CSRF, mengelabui pengguna yang diautentikasi untuk melakukan tindakan yang tidak diinginkan dengan mengirimkan permintaan berbahaya tanpa mereka sadari.

Biasanya, serangan CSRF melibatkan permintaan perubahan status karena penyerang tidak menerima respons. Contoh permintaan tersebut termasuk menghapus catatan, mengubah kata sandi, membeli produk, atau mengirim pesan. Ini semua dapat terjadi tanpa sepengetahuan pengguna.

Penyerang jahat biasanya menggunakan rekayasa sosial untuk mengirim tautan kepada pengguna yang tidak menaruh curiga melalui obrolan atau email.

Saat pengguna mengklik tautan, itu mengeksekusi perintah yang ditetapkan penyerang.

Misalnya, mengklik tautan dapat mentransfer dana dari akun pengguna. Atau, itu dapat mengubah alamat email pengguna yang mencegah mereka mendapatkan kembali akses akun.

Bagaimana Cara Kerja Serangan CSRF?

Membuat pengguna memulai permintaan perubahan keadaan saat masuk adalah langkah pertama dan paling penting dalam serangan CSRF. Dengan serangan CSRF, penyerang bertujuan untuk mendapatkan pengguna yang diautentikasi untuk tanpa sadar mengirimkan permintaan web berbahaya ke situs web atau aplikasi web. Permintaan ini dapat terdiri dari cookie, parameter URL, dan tipe data lain yang tampak normal bagi pengguna.

Agar serangan CSRF berhasil, kondisi berikut harus terjadi:

• Pengguna yang diautentikasi harus masuk ke aplikasi web yang menggunakan cookie untuk manajemen sesi.
• Penyerang harus membuat permintaan palsu yang mengubah status.
• Permintaan asli yang ditangani oleh server target tidak boleh berisi parameter yang tidak dapat diprediksi. Misalnya, permintaan tidak boleh mengharapkan kata sandi sebagai parameter untuk tujuan verifikasi sebelum memulai permintaan perubahan status.

Metode paling umum untuk menyelesaikan serangan CSRF adalah menggunakan cookie di aplikasi dengan kebijakan cookie SameSite yang lemah. Browser web menyertakan cookie secara otomatis dan seringkali secara anonim, dan mereka menyimpan cookie yang digunakan oleh domain dalam permintaan web apa pun yang dikirim pengguna ke domain tersebut.

Kebijakan cookie SameSite menentukan bagaimana browser dalam konteks penjelajahan lintas situs memperlakukan cookie. Jika disetel ketat, cookie tidak dibagikan dalam konteks penjelajahan lintas situs, mencegah serangan CSRF. Browser melampirkan cookie di semua konteks lintas situs jika disetel ke none. Ini membuat aplikasi rentan terhadap serangan CSRF.

Saat pengguna tanpa sadar mengirimkan permintaan jahat melalui browser web, cookie yang disimpan menyebabkan permintaan tampak sah ke server. Server kemudian menanggapi permintaan tersebut dengan mengubah akun pengguna, mengubah status sesi, atau mengembalikan data yang diminta.

Mari kita lihat lebih dekat dua contoh jalan serangan CSRF, satu dengan permintaan GET dan yang lainnya dengan permintaan POST.

CSRF untuk Permintaan GET

Pertama, pertimbangkan permintaan GET yang digunakan oleh aplikasi web perbankan keuangan, di mana serangan mengeksploitasi permintaan GET dan pengiriman hyperlink.

Misalkan permintaan GET untuk mentransfer uang terlihat seperti ini:

 GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1

Dalam permintaan asli di atas, pengguna meminta untuk mentransfer $1.000 ke akun dengan 547895 sebagai pembayaran untuk produk yang dibeli.

Meskipun permintaan ini eksplisit, sederhana, dan praktis, ini membuat pemilik akun terkena serangan CSRF. Itu karena permintaan tidak memerlukan detail yang mungkin tidak diketahui penyerang. Jadi, untuk memulai serangan, penyerang hanya perlu mengubah parameter permintaan ini (jumlah dan nomor akun) untuk membuat permintaan palsu yang dapat dieksekusi.

Permintaan jahat akan efektif pada pengguna bank mana pun selama mereka memiliki sesi yang dikelola cookie yang sedang berlangsung.

Begini tampilan permintaan palsu untuk mentransfer $500 ke akun peretas (di sini, nomor 654585 ). Perhatikan bahwa contoh di bawah ini adalah versi yang sangat disederhanakan dari langkah-langkah yang terlibat dalam serangan CSRF untuk penjelasannya.

 GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1

Setelah selesai, penyerang harus mencari cara untuk mengelabui pengguna agar mengirimkan permintaan ini saat masuk ke aplikasi perbankan online mereka. Salah satu cara untuk melakukannya adalah dengan membuat hyperlink yang tidak berbahaya yang menarik perhatian pengguna. Tautannya mungkin terlihat seperti ini:

 <a href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>.

Mengingat penyerang telah menemukan alamat email yang benar dari target mereka, mereka dapat mengirimkannya melalui email ke banyak pelanggan bank. Mereka yang mengeklik tautan saat masuk akan memicu permintaan untuk mengirim penyerang $500 dari akun yang masuk.

CSRF untuk Permintaan POST

Mari kita lihat bagaimana lembaga keuangan yang sama akan mengalami CSRF jika mereka hanya menerima permintaan POST. Dalam hal ini, pengiriman hyperlink yang digunakan dalam contoh permintaan GET tidak akan berfungsi. Oleh karena itu, serangan CSRF yang berhasil akan membutuhkan penyerang untuk membuat formulir HTML. Permintaan asli untuk mengirim $1.000 untuk produk yang dibeli akan terlihat seperti ini:

 POST /online/transfer HTTP/1.1 Host: xymbank.com Content-Type: application/x-www-form-urlencoded Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg amount=1000 account=547895

Permintaan POST ini membutuhkan cookie untuk menentukan identitas pengguna, jumlah yang ingin mereka kirim, dan akun yang ingin mereka kirim. Penyerang dapat mengubah permintaan ini untuk melakukan serangan CSRF.

Penyerang hanya boleh menambahkan cookie asli ke permintaan palsu agar server memproses transfer. Mereka dapat melakukannya dengan membuat hyperlink yang tampak tidak berbahaya yang membawa pengguna ke halaman web pemicu yang terlihat seperti ini:

 <html> <body> <form action="https://xymbank.com/online/transfer" method="POST"> <input type="hidden" name="amount" value="500"/> <input type="hidden" name="account" value="654585" /> </form> <script> document.forms[0].submit(); </script> </body> </html>

Kami telah menetapkan jumlah dan parameter akun dalam formulir di atas. Setelah pengguna terotentikasi mengunjungi halaman, browser menambahkan cookie sesi sebelum meneruskan permintaan ke server. Server kemudian meneruskan $500 ke akun peretas.

3 Cara Untuk Meredakan Serangan CSRF

Ada beberapa metode untuk mencegah dan secara drastis mengurangi potensi serangan CSRF di situs web atau aplikasi web Anda, antara lain:

• Menggunakan token CSRF
• Menggunakan tajuk perujuk
• Memilih solusi hosting yang berfokus pada keamanan, seperti Kinsta

Cara Mencegah Serangan CSRF Menggunakan Token CSRF

Situs web aman CSRF memberikan setiap sesi token unik dan membagikannya dengan sisi server dan browser klien. Setiap kali browser mengirim permintaan sensitif, server mengharapkannya berisi token CSRF yang ditetapkan. Jika memiliki token yang salah, server menjatuhkannya. Token CSRF tidak disimpan dalam cookie sesi di browser klien untuk tujuan keamanan.

Potensi Kerentanan Token CSRF

Meskipun token CSRF adalah ukuran keamanan yang sangat baik, metode ini tidak tahan serangan. Beberapa kerentanan yang menyertai token CSRF meliputi:

• Bypass validasi — Beberapa aplikasi melewati langkah verifikasi jika tidak menemukan token. Jika penyerang mendapatkan akses ke kode yang berisi token, mereka dapat menghapus token tersebut dan berhasil mengeksekusi serangan CSRF. Jadi, jika permintaan yang valid ke server terlihat seperti ini:

 POST /change_password POST body: password=pass123&csrf_token=93j9d8eckke20d433

Penyerang hanya perlu menghapus token dan mengirimkannya seperti ini untuk mengeksekusi serangan:

 POST /change_password POST body: password=pass123

• Token yang dikumpulkan — Beberapa aplikasi mempertahankan kumpulan token untuk memvalidasi sesi pengguna alih-alih menunjuk token tertentu ke sesi. Penyerang hanya perlu mendapatkan salah satu token yang sudah ada di kumpulan untuk menyamar sebagai salah satu pengguna situs.

Penyerang dapat masuk ke aplikasi menggunakan akun mereka untuk mendapatkan token, seperti:

 [application_url].com?csrf_token=93j9d8eckke20d433

Dan karena token dikumpulkan, penyerang dapat menyalin dan menggunakan token yang sama untuk masuk ke akun pengguna lain, karena Anda akan menggunakannya lagi:

• CSRF dapat disalin token ke cookie — Beberapa aplikasi akan menyalin parameter yang terkait dengan token ke dalam cookie pengguna. Jika penyerang mendapatkan akses ke cookie tersebut, mereka dapat dengan mudah membuat cookie lain, menempatkannya di browser, dan menjalankan serangan CSRF.

Jadi penyerang dapat masuk ke aplikasi menggunakan akun mereka dan membuka file cookie untuk melihat hal berikut:

 Csrf_token:93j9d8eckke20d433

Mereka kemudian dapat menggunakan informasi ini untuk membuat cookie lain guna menyelesaikan serangan

• Token tidak valid — Beberapa aplikasi tidak mencocokkan token CSRF dengan sesi pengguna. Dalam kasus seperti itu, penyerang dapat benar-benar masuk ke dalam sesi, mendapatkan token CSRF yang mirip dengan yang di atas, dan menggunakannya untuk mengatur serangan CSRF pada sesi korban.

Cara Mencegah Serangan CSRF dengan Referrer Header

Strategi lain untuk mencegah serangan CSRF adalah menggunakan header pengarah. Di HTTP, header perujuk menunjukkan asal permintaan. Mereka biasanya digunakan untuk melakukan analitik, pengoptimalan, dan pencatatan.

Anda juga dapat mengaktifkan pemeriksaan tajuk perujuk di sisi server untuk mencegah serangan CSRF. Sisi server memeriksa asal sumber permintaan dan menentukan asal target permintaan. Jika cocok, maka permintaan diperbolehkan. Jika ada ketidakcocokan, server membatalkan permintaan.

Menggunakan header pengarah jauh lebih mudah daripada menggunakan token karena tidak memerlukan identifikasi pengguna individual.

Kerentanan Potensial dari Referrer Header

Seperti token CSRF, header perujuk memiliki beberapa kerentanan yang signifikan.

Pertama, tajuk perujuk tidak wajib, dan beberapa situs akan mengirimkan permintaan tanpa tajuk tersebut. Jika CSRF tidak memiliki kebijakan untuk menangani permintaan tanpa header, penyerang dapat menggunakan permintaan tanpa header untuk mengeksekusi serangan yang mengubah status.

Selain itu, metode ini menjadi kurang efektif dengan diperkenalkannya kebijakan perujuk baru-baru ini. Spesifikasi ini mencegah kebocoran URL ke domain lain, memberi pengguna lebih banyak kontrol atas informasi di header perujuk. Mereka dapat memilih untuk mengekspos bagian dari informasi header perujuk atau menonaktifkannya dengan menambahkan tag metadata pada halaman HTML, seperti yang ditunjukkan di bawah ini:

 <meta name="referrer" content="no-referrer">

Kode di atas menghapus tajuk perujuk untuk semua permintaan dari halaman ini. Melakukannya mempersulit aplikasi yang mengandalkan header perujuk untuk mencegah serangan CSRF dari halaman tersebut.

Bagaimana Kinsta Melindungi Terhadap Serangan CSRF

Selain menggunakan header pengarah dan token CSRF, ada opsi ketiga dan lebih mudah: memilih layanan hosting yang aman seperti Kinsta untuk situs web dan aplikasi web Anda memberikan penghalang yang jauh lebih kuat dan lebih aman antara penyerang dan pengguna Anda.

Selain fitur keamanan penting seperti pencadangan otomatis, autentikasi dua faktor, dan SFTP melalui protokol SSH, integrasi Cloudflare Kinsta memberikan perlindungan tingkat perusahaan dengan perlindungan firewall dan berbasis IP.

Secara khusus, Kinsta saat ini memiliki sekitar 60 aturan firewall khusus untuk membantu mencegah serangan jahat dan menangani kerentanan parah yang tidak diautentikasi dalam plugin dan tema, termasuk yang spesifik yang mencari kerentanan CSRF.

Ringkasan

Pemalsuan permintaan lintas situs (CSRF) adalah serangan yang mengelabui pengguna yang diautentikasi untuk memulai permintaan yang mengubah status secara tidak sengaja. Mereka menargetkan aplikasi yang tidak dapat membedakan antara permintaan perubahan status yang valid dan palsu.

CSRF hanya dapat berhasil pada aplikasi yang mengandalkan cookie sesi untuk mengidentifikasi pengguna yang dicatat dan memiliki kebijakan cookie SameSite yang lemah. Mereka juga membutuhkan server yang menerima permintaan yang tidak mengandung parameter yang tidak diketahui seperti kata sandi. Peretas dapat mengirim serangan jahat menggunakan GET atau POST.

Meskipun menggunakan token CSRF atau menerapkan verifikasi tajuk pengarah dapat mencegah beberapa serangan CSRF, kedua tindakan tersebut memiliki potensi kerentanan yang dapat membuat tindakan pencegahan Anda tidak berguna jika Anda tidak berhati-hati.

Bermigrasi ke platform hosting yang aman seperti Kinsta mengamankan situs web atau aplikasi web Anda dari serangan CSRF. Selain itu, integrasi Kinsta dengan Cloudflare mencegah serangan CSRF tertentu.