BOOK THIS SPACE FOR AD
ARTICLE ADUntuk melindungi privasi dari website target, kita sebut saja website tersebut dengan target.com. Singkatnya, 2 cara yang saya gunakan untuk melakukan bypass CSRF Token adalah:
Mengganti HTTP Request Method: POST -> GET, dan menghapus CSRF Token pada Cookie Header dan Request Body.Menggunakan CSRF Token milik pengguna lain, maupun Token yang sudah expired.Sebelum saya menjelaskan lebih detail tentang cara-cara untuk melewati proteksi CSRF tersebut, kita harus memahami…
Bagaimana Proteksi CSRF Token Pada Website target.com Bekerja?
Website target.com menggunakan 2 CSRF Token, dimana 1 berada pada Cookie Header, dan 1 berada pada Request Body. Pada tiap request, kedua CSRF Token tersebut akan dicheck dan dipastikan bahwa mereka berpasangan.
Karena kita sudah tahu bagaimana proteksi CSRF pada website target.com bekerja, kita akan membahas kelemahan yang ada dan cara melewatinya.
Pada metode ini, yang saya lakukan pada saat testing:
Mengganti HTTP Request Method: POST -> GETMenghapus CSRF Token pada Cookie Header & Request BodyMengirimkan Request Body (tanpa parameter _csrf-backend)Berhasil mengirimkan request untuk mengganti nama pengguna, tanpa menggunakan CSRF TokenBerdasarkan pengamatan dan dugaan saya, celah ini terjadi karena:
Website tidak memeriksa keberadaan & kebenaran CSRF Token pada Request Method selain POST, misal pada GET method.Meskipun menggunakan Request GET, dimana pada umumnya tidak menggunakan Request Body, website target.com menerima request tersebut, bahkan seakan-akan memperlakukan request dengan GET method tersebut sebagai request POST method.Metode ini lumayan menarik, karena ternyata walaupun target.com memeriksa bahwa CSRF Token yang ada pada Cookie Header & Request Body berpasangan (sebuah pair) dan cocok, namun tidak melakukan pemeriksaan kepemilikan dan masa ekspirasi (expiration) dari CSRF Token tersebut.
Pada metode ini, yang saya lakukan pada saat testing:
Log-in pada akun Attacker, dan ambil CSRF Token (_csrf-backend) yang ada pada Cookie Header & Request Body.Log-out.Log-in pada akun Victim, dan ganti value CSRF Token (_csrf-backend) menjadi value yang dimiliki oleh akun Attacker.Berhasil mengirimkan request untuk mengganti nama pengguna, dengan menggunakan CSRF Token milik pengguna lain.Note: Dalam kasus ini, saya juga bisa menggunakan CSRF Token yang sudah expired, baik milik Attacker, maupun Victim.
Berdasarkan pengamatan dan dugaan saya, celah ini terjadi karena:
Website target.com hanya memeriksa jika CSRF Token valid (berpasangan), tapi tidak memeriksa kepemilikkan dan masa ekspirasi (expiration) dari Token.Sekian dari saya, terimakasih telah meluangkan waktu untuk membaca artikel ini… Semoga bisa bermanfaat dalam membantu kalian menemukan celah pada proteksi CSRF Token yang ada pada website.
Lesson learned: Keberadaan CSRF Token tidak memastikan bahwa website tersebut aman dari serangan CSRF. Selalu coba menguji keamanan dari sebuah proteksi yang diimplementasikan.