Mohon tunggu...
Red Among Us
Red Among Us Mohon Tunggu... Lainnya - Impostor in Skeld Ship

Random people on the Internet

Selanjutnya

Tutup

Gadget

Pentingnya Menambahkan Otorisasi dan Otentikasi Dalam Pengembangan Sistem Aplikasi

10 Januari 2022   21:42 Diperbarui: 21 Januari 2022   08:18 1622
+
Laporkan Konten
Laporkan Akun
Kompasiana adalah platform blog. Konten ini menjadi tanggung jawab bloger dan tidak mewakili pandangan redaksi Kompas.
Lihat foto
Memanipulasi Parameter id=4 Menjadi id=1 melalui HTTP Request Header | Sumber: Dokumentasi Penulis

Perancangan dan pembangunan sebuah sistem aplikasi memerlukan suatu manajemen pengelolaan data yang dapat menjamin kerahasiaan data milik penggunanya. Dalam ranah kemanan siber terdapat konsep tiga serangkai CIA, berdasarkan pemaparan dari OWASP Foundation (2016), konsep tiga serangkai CIA merupakan sebuah konsep yang terdiri dari:

  1. Confidentaly atau Keamanan Data;
  2. Integrity atau Keutuhan Data, dan;
  3. Availability atau Ketersediaan Data.

Konsep ini tidak dapat dipisahkan karena konsep ini merupakan fondasi dari keamanan suatu sistem aplikasi dan ketiga istilah tadi saling berhubungan satu dengan lainnya. Konsep ini seringnya juga diperpanjang oleh Otorisasi (Authorization), Otentikasi (Authentication), dan Auditing. Perpanjangan konsep ini dikarenakan Otorisasi dan Otentikasi akan saling melengkapi konsep tersebut, sedangkan Auditing memiliki fungsi untuk menyediakan kepastian berupa bukti interaksi pada sebuah sistem aplikasi .

Sebagaimana dikutip dari OWASP Foundation (2016), Otorisasi dan Otentikasi merupakan dua hal yang berbeda, sederhananya Otorisasi merupakan mekanisme pemberian hak istimewa (privileges), ataupun peranan pengguna dalam sebuah aplikasi untuk mengakses, merubah, atau memodifikasi data, maupun fungsi dalam suatu aplikasi, sebelum dijalankannya proses Otorisasi biasanya aplikasi akan terlebih dahulu melakukan proses Otentikasi. Sedangkan Otentikasi adalah sebuah mekanisme yang dapat memverifikasi berdasarkan identitas yang otentik pada suatu pengguna. Dengan demikian secara mekanisme, Otentikasi dan Otorisasi akan saling melengkapi dalam mengelola peranan pengguna dalam mengakses, merubah, ataupun memodifkasi suatu fungsi ataupun data dalam sebuah aplikasi.

Meskipun pada akhirnya terdapat juga kerentanan-kerentanan yang menargetkan mekanisme Otorisasi dan Otentikasi seperti Broken Authentication, namun penerapan Otorisasi dan Otentikasi dalam suatu sistem aplikasi tentu akan meminimalisir adanya kebocoran data, misalkan berupa kerentanan Referensi Objek Tidak Langsung atau IDOR (Insecure Direct Object References). Sebagai contoh penulis akan mempraktikannya secara legal dalam aplikasi CTF (Capture the Flag) Postbook milik Hackerone.com. Tujuan dari praktik ini adalah untuk merubah konten seorang Administrator Website melalui kerentanan IDOR (Insecure Direct Object References).

Penulis akan membuat terlebih dahulu sebuah akun dummy dengan username @testakun, dan membuat sebuah konten pada aplikasi. Dalam proses ini diketahui bahwa akun @testakun memiliki parameter id (id=4) dalam url konten tersebut, hal ini menandakan bahwa akun yang penulis buat secara tidak langsung menandakan bahwa penulis telah membuat akun keempat setelah tiga akun sudah dibuat oleh pengguna lain. Untuk memastikan bahwa penulis merupakan pengguna keempat dalam aplikasi, dapat dilihat pada id milik pengguna lain yang dapat dilihat dalam gambar berikut.

Parameter id=4 pada user @testakun | Sumber: Dokumentasi Penulis
Parameter id=4 pada user @testakun | Sumber: Dokumentasi Penulis

Parameter id=1 pada user @admin | Sumber: Dokumentasi Penulis
Parameter id=1 pada user @admin | Sumber: Dokumentasi Penulis

Parameter id juga digunakan bila akan mengedit konten yang akan diunggah pada aplikasi Postbook. Untuk mendeteksi adanya kerentanan IDOR, penulis akan merubah konten  Administrator Website. Menggunakan Burp Suite, penulis akan melakukan penyadapan HTTP Request Header pada bagian edit konten milik penulis dan memanipulasi parameter id penulis (id=4) seolah-olah parameter id tersebut merupakan parameter id milik Administrator Website (id=1), proses manipulasi dapat dilihat pada gambar berikut.

Memanipulasi Parameter id=4 Menjadi id=1 melalui HTTP Request Header | Sumber: Dokumentasi Penulis
Memanipulasi Parameter id=4 Menjadi id=1 melalui HTTP Request Header | Sumber: Dokumentasi Penulis

Hasil dari manipulasi parameter ini menunjukan bahwa tidak adanya mekanisme Otorisasi serta Otentikasi dalam Aplikasi Postbook. Penyerang dapat memanfaatkan kerentanan IDOR yang disebabkan tidak terfilternya parameter id dan bisa digunakan untuk tujuan memanipulasi, ataupun mengakses secara leluasa sistem aplikasi. Hal ini dapat dilihat dari potensi penulis untuk merubah unggahan seorang Administrator Website melalui manipulasi parameter id tanpa adanya proses Otentikasi untuk memverifikasi siapa penulis, dan tidak adanya Otorisasi sebagai mekanisme pemberian akses bagi penulis untuk mengakses parameter id=1 didalam url edit konten aplikasi Postbook.

HALAMAN :
  1. 1
  2. 2
Mohon tunggu...

Lihat Konten Gadget Selengkapnya
Lihat Gadget Selengkapnya
Beri Komentar
Berkomentarlah secara bijaksana dan bertanggung jawab. Komentar sepenuhnya menjadi tanggung jawab komentator seperti diatur dalam UU ITE

Belum ada komentar. Jadilah yang pertama untuk memberikan komentar!
LAPORKAN KONTEN
Alasan
Laporkan Konten
Laporkan Akun