Tuesday, 23 January 2018

Memahami dan Menemukan Kerentanan Insecure Direct Object Reference

Memahami dan Menemukan Kerentanan Insecure Direct Object Reference - Kali ini kembali saya membahas tentang security. Yang akan kita bahas kali ini adalah tentang Insecure Direct Object Reference atau IDOR vulnerability. Apa itu IDOR? Seberapa berbahayakah kerentanan ini? Mari kita bahas sama sama.

Pendahuluan
Insecure Direct Object Reference terjadi saat aplikasi menyediakan akses langsung ke objek berdasarkan masukan yang diberikan pengguna. Hal ini memngkinkan hacker untuk mem-bypass autentifikasi standar dan mengakses catatan database maupun sumber daya lain.

Insecure Direct Object References memungkinkan penyerang untuk memotong otorisasi dan mengakses sumber daya secara langsung dengan memodifikasi nilai parameter yang digunakan untuk mengarahkan langsung ke objek. Sumber daya semacam itu bisa menjadi entri database milik pengguna lain, file dalam sistem, dan banyak lagi. Hal ini disebabkan oleh fakta bahwa aplikasi tersebut memasukkan input yang dipasok pengguna dan menggunakannya untuk mengambil objek tanpa melakukan pengecekan otorisasi yang memadai.

Bagaimana Cara Menemukan Kerentanan ini?
Untuk menguji kerentanan ini, pentester perlu memetakan semua lokasi di aplikasi tempat input pengguna untuk mendapatkan referensi objek secara langsung. Misalnya, lokasi tempat input pengguna yang digunakan untuk mengakses baris database, file, halaman aplikasi dan lainnya. Selanjutnya, tester harus memodifikasi nilai parameter yang digunakan untuk referensi objek dan melihat apakah ada kemungkinan untuk melihat atau mengakses data pengguna lain atau sebaliknya melakukan bypass otorisasi.

Contoh Kasus
Anggap saja kamu memiliki akun di Bank A dengan website bank.com. Di website tersebut, kamu memiliki user id 1337.
Nah, data pengguna termasuk jumlah saldo dan lain lain ditampilkan dengan format url
bank.com/userid/data yang berarti datamu akan tampil ketika kamu mengakses bank.com/1337/data .
Nah, ketika kamu mengubah parameter userid misal kamu mengakses bank.com/666/data, website tersebut menampilkan detail data dari pengguna dengan userid 666 tanpa harus login terlebih dahulu. Celah seperti inilah yang disebut IDOR. Hal tersebut tentu berbahaya karena informasi sensitif pengguna lain bisa saja didapatkan.

Terlebih lagi, kerentanan ini tidak hanya mencakup celah untuk mengakses data pengguna lain saja. Bisa saja digunakan untuk memodifikasi data.  Sebagai contoh kasus berikut:
Untuk merubah password, sebuah website memiliki format sebagai berikut:
website.com/resetpassword?api=md5&email=emailmu
Nah, seorang attacker berhasil menemukan bahwa ternyata hash md5 tadi hanya berupa hash email.
website.com/resetpassword?api=f116423fd6c19d4fdb6754a8c7e1f1e8&email=satu@email.com
Lalu untuk pengguna dengan email dua@email.com formatnya adalah
website.com/resetpassword?api=0d57d1eee4605ec44cc1fccd6075de48&email=dua@email.com
Catatan:
f116423fd6c19d4fdb6754a8c7e1f1e8 adalah hash md5 dari satu@email.com
0d57d1eee4605ec44cc1fccd6075de48 adalah hassh md5 dari dua@email.com

Tentu saja kedua contoh diatas hanya contoh sederhana saja agar lebih mudah dipahami. Dalam kasus nyata nya tentu lebih rumit dari itu. Kita harus benar benar jeli memetakan semua lokasi dan juga request.

Intinya, analisa kode adalah cara paling tepat untuk melakukan audit terhadap kerentanan ini. Selain itu, kalian juga harus berpikir apa yang akan kamu lakukan jika kamu berada di pihak hacker. Kerentanan jenis ini sendiri dihargai sangat mahal. Perusahaan perusahaan besar berani membayar hingga ribuan dollar bagi yang dapat menemukan kerentanan IDOR di aplikasinya. So, mulailah menganggap bahwa security adalah bagian yang sangat penting.

Baiklah sekian artikel kali ini, jika ada yang kurang jelas silahkan ditanyakan, dan jika ada kesalahan silahkan dikoreksi.

No comments:

Post a Comment