Referensi objek langsung tidak aman (IDOR)

Apa Referensi Obyek Langsung Tidak Aman
(IDOR)

Referensi objek langsung tidak aman (IDOR) adalah masalah keamanan siber yang terjadi ketika pengembang aplikasi web menggunakan pengidentifikasi untuk akses langsung ke objek implementasi internal tetapi tidak memberikan kontrol akses tambahan dan / atau pemeriksaan otorisasi. Misalnya, kerentanan IDOR akan terjadi jika URL transaksi dapat diubah melalui input pengguna sisi klien untuk menampilkan data tidak sah dari transaksi lain.

Dalam OWASP (Proyek Keamanan Aplikasi Web Terbuka) daftar 10 Besar pada tahun 2013, referensi objek langsung tidak aman diperlakukan sebagai masalah terpisah peringkat di nomor 4 (lihat OWASP Top 10 2013 A4). Namun, dalam OWASP Top 10 terakhir di 2017, kategori ini digabungkan ke dalam kategori A5: Kontrol akses rusak.

Bagaimana Kerentanan IDOR Terjadi

Sebagian besar aplikasi web menggunakan ID sederhana untuk referensi objek. Misalnya, pengguna dalam basis data biasanya akan dirujuk melalui ID pengguna. ID pengguna yang sama adalah kunci utama ke kolom database yang berisi informasi pengguna dan dihasilkan secara otomatis. Algoritma pembuatan kunci basis data sangat sederhana: biasanya menggunakan integer berikutnya yang tersedia. Basis data ID mekanisme pembuatan yang sama digunakan untuk semua jenis catatan database lainnya.

Pendekatan yang dijelaskan di atas adalah sah tetapi tidak direkomendasikan karena dapat memungkinkan penyerang untuk menghitung semua pengguna. Jika perlu untuk mempertahankan pendekatan ini, pengembang setidaknya harus memastikan sepenuhnya bahwa lebih dari sekadar referensi diperlukan untuk mengakses sumber daya. Misalnya, katakanlah aplikasi web menampilkan detail transaksi menggunakan URL berikut:

https://www.example.com/transaction.php?id=74656

Peretas jahat dapat mencoba mengganti nilai parameter id 74656 dengan nilai lain yang serupa, misalnya:

https://www.example.com/transaction.php?id=74657

Transaksi 74657 bisa menjadi transaksi yang sah milik pengguna lain. Peretas jahat seharusnya tidak diizinkan untuk melihatnya. Namun, jika pengembang membuat kesalahan, penyerang akan melihat transaksi ini dan karenanya kami akan memiliki kerentanan referensi objek langsung tidak aman.

Skenario Referensi Objek Langsung Tidak Aman yang umum

Kerentanan IDOR dapat terjadi dalam kasus formulir perubahan kata sandi. URL formulir perubahan kata sandi yang dirancang dengan buruk mungkin adalah:

https://www.example.com/change_password.php?userid=1701

URL ini akan dikirim melalui email pada saat pertama memberikan alamat email menggunakan formulir yang berbeda. Jika tidak ada pemeriksaan tambahan, peretas jahat dapat mencoba URL di atas dengan userid = 1, sehingga mungkin mendapatkan akses ke akun administrator.

Kerentanan IDOR mungkin juga melibatkan nama file, bukan ID objek. Misalnya, salah satu kerentanan IDOR paling umum adalah direktori traversal (jalur traversal). Dalam kasus khusus ini, pengguna dapat menampilkan file yang tidak sah. Sebagai contoh:

https://www.example.com/display_file.php?file.txt

Jika ada kerentanan IDOR yang terkait dengan skrip display_file.php, peretas jahat dapat memperoleh akses ke sumber daya sistem file sensitif seperti file / etc / passwd:

https://www.example.com/display_file.php?../../../etc/passwd

Pencegahan Referensi Langsung Tidak Aman

Panduan Pengujian OWASP berisi paragraf tentang cara menguji kerentanan referensi objek langsung tidak aman: OTG-AUTHZ-004. Solusi otomatis belum dapat mendeteksi kerentanan IDOR.

Satu-satunya cara untuk melindungi terhadap IDOR adalah dengan menerapkan pemeriksaan kontrol akses yang ketat. Untungnya, kerangka kerja web modern seperti Ruby on Rails atau Django tidak memiliki masalah dengan IDOR (kecuali pengembang memutuskan untuk menggunakan mekanisme mereka sendiri daripada yang disediakan). Kontrol akses diimplementasikan dalam kerangka kerja seperti itu dengan desain. Karena itu, kami menyarankan Anda menggunakan kerangka kerja terkenal untuk mengembangkan aplikasi web Anda dan mengikuti praktik terbaik.

Perhatikan bahwa beberapa sumber merekomendasikan pencegahan kerentanan IDOR dengan menggunakan pengidentifikasi objek yang panjang dan sulit ditebak, seperti yang digunakan untuk ID sesi. Solusi serupa lainnya yang diusulkan adalah dengan menggunakan peta referensi objek tidak langsung dengan ID eksternal yang sulit ditebak. Namun, kami sangat menyarankan menentang pendekatan seperti itu karena mereka memberikan rasa aman palsu dan membuat serangan lebih sulit tetapi bukan tidak mungkin.

https://www.acunetix .com/blog/web-security-zone/what-are-insecure-direct-object-references/

https://www.business2community .com/cybersecurity/insecure-direct-object-reference-idor-web-based-application-security-part-6-02287025