Skip to main content

Otorisasi

Pengenalan Otorisasi​

Otorisasi dapat didefinisikan sebagai "proses verifikasi bahwa tindakan atau layanan yang diminta disetujui untuk entitas tertentu" (NIST). Otorisasi berbeda dari autentikasi yang merupakan proses verifikasi identitas suatu entitas. Saat merancang dan mengembangkan solusi perangkat lunak, penting untuk mengingat perbedaan ini. Seorang pengguna yang telah diautentikasi (mungkin dengan memberikan nama pengguna dan kata sandi) sering kali tidak diizinkan untuk mengakses setiap sumber daya dan melakukan setiap tindakan yang secara teknis mungkin dilakukan melalui sistem. Misalnya, sebuah aplikasi web mungkin memiliki pengguna biasa dan admin, dengan admin dapat melakukan tindakan yang tidak dapat dilakukan oleh pengguna biasa, meskipun mereka telah diautentikasi. Selain itu, otentikasi tidak selalu diperlukan untuk mengakses sumber daya; pengguna yang tidak terotentikasi mungkin diizinkan untuk mengakses sumber daya publik tertentu, seperti gambar atau halaman login, atau bahkan seluruh aplikasi web.

Lembar contekan ini membantu pengembang membuat logika otorisasi yang kuat, dapat dipelihara, dan dapat diskalakan sesuai dengan kebutuhan bisnis aplikasi. Kekurangan otorisasi, seperti Broken Access Control, adalah masalah utama bagi aplikasi web dan peringkat sebagai masalah keamanan teratas dalam OWASP's 2021 Top 10. Kekurangan ini dapat memungkinkan penyerang untuk mengakses, memodifikasi, atau menghapus sumber daya sensitif, dengan dampak yang bergantung pada pentingnya data yang dikompromikan. Baik pihak luar yang tidak berwenang maupun pengguna yang berwenang dapat mengeksploitasi kelemahan ini, yang dapat mengakibatkan pelanggaran data, penyalahgunaan hak istimewa, atau tindakan tidak sah. Pencatatan yang tepat sangat penting untuk mendeteksi dan melacak pelanggaran semacam itu.

Rekomendasi​

Terapkan Prinsip Hak Akses Minimum​

Sebagai konsep keamanan, Least Privileges mengacu pada prinsip memberikan pengguna hanya hak akses minimum yang diperlukan untuk menyelesaikan pekerjaan mereka. Meskipun mungkin paling umum diterapkan dalam administrasi sistem, prinsip ini juga relevan bagi pengembang perangkat lunak. Prinsip Least Privileges harus diterapkan secara horizontal dan vertikal. Misalnya, meskipun baik akuntan maupun perwakilan penjualan mungkin menempati tingkat yang sama dalam hierarki organisasi, keduanya memerlukan akses ke sumber daya yang berbeda untuk melaksanakan pekerjaan mereka. Akuntan seharusnya tidak diberikan akses ke basis data pelanggan dan perwakilan penjualan seharusnya tidak dapat mengakses data penggajian. Demikian pula, kepala departemen penjualan kemungkinan memerlukan akses yang lebih istimewa daripada bawahan mereka.

Kegagalan untuk menerapkan prinsip hak akses minimum dalam sebuah aplikasi dapat membahayakan kerahasiaan sumber daya sensitif. Strategi mitigasi diterapkan terutama selama fase Arsitektur dan Desain (lihat CWE-272); namun, prinsip ini harus diterapkan sepanjang SDLC.

Pertimbangkan poin-poin dan praktik terbaik berikut:

  • Selama fase desain, pastikan batasan kepercayaan didefinisikan. Enumerasikan jenis pengguna yang akan mengakses sistem, sumber daya yang diekspos, dan operasi (seperti baca, tulis, perbarui, dll) yang mungkin dilakukan pada sumber daya tersebut. Untuk setiap kombinasi jenis pengguna dan sumber daya, tentukan operasi apa, jika ada, yang harus dapat dilakukan pengguna (berdasarkan peran dan/atau atribut lainnya) pada sumber daya tersebut. Untuk sistem ABAC, pastikan semua kategori atribut dipertimbangkan. Misalnya, seorang Perwakilan Penjualan mungkin perlu mengakses basis data pelanggan dari jaringan internal selama jam kerja, tetapi tidak dari rumah pada tengah malam.
  • Buat tes yang memvalidasi bahwa izin yang dipetakan pada fase desain diterapkan dengan benar. Buat tes yang memvalidasi bahwa izin yang dipetakan dalam fase desain diterapkan dengan benar.
  • Setelah aplikasi diluncurkan, secara berkala tinjau izin dalam sistem untuk "privilege creep"; yaitu, pastikan hak istimewa pengguna di lingkungan saat ini tidak melebihi yang ditentukan selama fase desain. Setelah aplikasi diluncurkan, secara berkala tinjau izin dalam sistem untuk "privilege creep"; yaitu, pastikan hak istimewa pengguna di lingkungan saat ini tidak melebihi yang ditentukan selama fase desain. (plus or minus any formally approved changes).
  • Ingat, lebih mudah untuk memberikan izin tambahan kepada pengguna daripada mencabut beberapa izin yang sebelumnya mereka nikmati. Perencanaan dan penerapan yang hati-hati dari Prinsip Hak Istimewa Terendah pada tahap awal SDLC dapat membantu mengurangi risiko perlu mencabut izin yang kemudian dianggap terlalu luas.

Validasi Izin pada Setiap Permintaan​

Izin harus divalidasi dengan benar pada setiap permintaan, terlepas dari apakah permintaan tersebut diinisiasi oleh skrip AJAX, sisi server, atau sumber lainnya. Teknologi yang digunakan untuk melakukan pemeriksaan semacam itu harus memungkinkan konfigurasi global di seluruh aplikasi daripada harus diterapkan secara individu pada setiap metode atau kelas. Ingat, seorang penyerang hanya perlu menemukan satu cara untuk masuk. Bahkan jika hanya satu pemeriksaan kontrol akses yang "terlewat", kerahasiaan dan/atau integritas suatu sumber daya dapat terancam. Memvalidasi izin dengan benar hanya pada sebagian besar permintaan tidaklah cukup. Teknologi spesifik yang dapat membantu pengembang dalam melakukan pemeriksaan izin yang konsisten termasuk hal-hal berikut:

Tinjau Secara Menyeluruh Logika Otorisasi dari Alat dan Teknologi yang Dipilih, Terapkan Logika Kustom jika Diperlukan​

Pengembang masa kini memiliki akses ke sejumlah besar pustaka, platform, dan kerangka kerja yang memungkinkan mereka untuk menggabungkan logika yang kuat dan kompleks ke dalam aplikasi mereka dengan usaha minimal. Namun, kerangka kerja dan pustaka ini tidak boleh dipandang sebagai solusi cepat untuk semua masalah pengembangan; pengembang memiliki kewajiban untuk menggunakan kerangka kerja tersebut secara bertanggung jawab dan bijaksana. Dua kekhawatiran umum yang relevan dengan pemilihan framework/perpustakaan terkait kontrol akses yang tepat adalah kesalahan konfigurasi/kekurangan konfigurasi dari pihak pengembang dan kerentanan dalam komponen itu sendiri (lihat A6 dan A9 untuk panduan umum tentang topik-topik ini).

Bahkan dalam aplikasi yang dikembangkan dengan aman, kerentanan pada komponen pihak ketiga dapat memungkinkan penyerang untuk melewati kontrol otorisasi normal. Kekhawatiran semacam itu tidak perlu dibatasi pada proyek yang belum terbukti atau yang kurang terawat, tetapi juga mempengaruhi pustaka dan kerangka kerja yang paling kuat dan populer. Menulis perangkat lunak yang kompleks dan aman itu sulit. Bahkan pengembang yang paling kompeten, yang bekerja pada pustaka dan kerangka kerja berkualitas tinggi, akan membuat kesalahan. Anggaplah setiap komponen pihak ketiga yang Anda masukkan ke dalam aplikasi dapat atau menjadi rentan terhadap kerentanan otorisasi. Pertimbangan penting meliputi:

  • Buat, pertahankan, dan ikuti proses untuk mendeteksi dan merespons komponen yang rentan.
  • Menggabungkan alat seperti Dependency Check ke dalam SDLC dan mempertimbangkan untuk berlangganan umpan data dari vendor, NVD, atau sumber relevan lainnya.
  • Terapkan pertahanan berlapis. Jangan bergantung pada satu kerangka kerja, pustaka, teknologi, atau kontrol tunggal untuk menjadi satu-satunya yang menegakkan kontrol akses yang tepat.

Kesalahan konfigurasi (atau kurangnya konfigurasi sama sekali) adalah area utama lain di mana komponen yang dibangun oleh pengembang dapat menyebabkan otorisasi yang rusak. Komponen-komponen ini biasanya dimaksudkan sebagai alat yang relatif umum dan dirancang untuk menarik perhatian khalayak yang luas. Untuk semua kasus penggunaan kecuali yang paling sederhana, kerangka kerja dan pustaka ini harus disesuaikan atau dilengkapi dengan logika tambahan untuk memenuhi persyaratan unik dari aplikasi atau lingkungan tertentu. Pertimbangan ini sangat penting ketika persyaratan keamanan, termasuk otorisasi, menjadi perhatian. Pertimbangan konfigurasi yang penting untuk otorisasi meliputi hal-hal berikut:

  • Luangkan waktu untuk memahami secara menyeluruh teknologi apa pun yang Anda bangun logika otorisasi di atasnya. Analisis kemampuan teknologi dengan pemahaman bahwa logika otorisasi yang disediakan oleh komponen mungkin tidak memadai untuk kebutuhan keamanan spesifik aplikasi Anda. Mengandalkan logika yang sudah dibangun sebelumnya mungkin nyaman, tetapi ini tidak berarti cukup. Pahami bahwa logika otorisasi kustom mungkin sangat diperlukan untuk memenuhi persyaratan keamanan aplikasi.
  • Jangan biarkan kemampuan dari pustaka, platform, atau kerangka kerja mana pun memandu persyaratan otorisasi Anda. Sebaliknya, persyaratan otorisasi harus ditentukan terlebih dahulu dan kemudian komponen pihak ketiga dapat dianalisis berdasarkan persyaratan ini.
  • Jangan bergantung pada konfigurasi default.
  • Uji konfigurasi. Jangan hanya menganggap bahwa konfigurasi apa pun yang dilakukan pada komponen pihak ketiga akan berfungsi persis seperti yang diinginkan di lingkungan Anda. Dokumentasi dapat disalahartikan, samar, usang, atau bahkan tidak akurat.

Pastikan ID Pencarian Tidak Dapat Diakses Meskipun Ditebak atau Tidak Dapat Dimanipulasi​

Aplikasi sering mengekspos pengidentifikasi objek internal (seperti nomor akun atau Primary Key dalam basis data) yang digunakan untuk menemukan dan mereferensikan sebuah objek. ID ini dapat diekspos sebagai parameter kueri, variabel jalur, bidang formulir "tersembunyi" atau di tempat lain. Misalnya:

https://mybank.com/accountTransactions?acct_id=901

Berdasarkan URL ini, seseorang dapat dengan wajar berasumsi bahwa aplikasi akan mengembalikan daftar transaksi dan bahwa transaksi yang dikembalikan akan dibatasi pada akun tertentu - akun yang ditunjukkan dalam parameter acct_id. Tapi apa yang akan terjadi jika pengguna mengubah nilai parameter acct_id ke nilai lain seperti 523. Apakah pengguna akan dapat melihat transaksi yang terkait dengan akun lain meskipun akun tersebut bukan miliknya? Jika tidak, apakah kegagalan tersebut hanya disebabkan oleh akun "523" yang tidak ada/tidak ditemukan atau karena gagal dalam pemeriksaan kontrol akses? Meskipun contoh ini mungkin merupakan penyederhanaan berlebihan, ini menggambarkan kelemahan keamanan yang sangat umum dalam pengembangan aplikasi - CWE 639: Authorization Bypass Through User-Controlled Key. Ketika dieksploitasi, kelemahan ini dapat mengakibatkan pengabaian otorisasi, eskalasi hak istimewa horizontal, dan, lebih jarang, eskalasi hak istimewa vertikal (lihat CWE-639). Jenis kerentanan ini juga merupakan bentuk Referensi Objek Langsung yang Tidak Aman. (IDOR). Paragraf-paragraf berikut akan menjelaskan kelemahan dan kemungkinan mitigasinya.

Dalam contoh di atas, ID pencarian tidak hanya terekspos kepada pengguna dan mudah dimanipulasi, tetapi juga tampaknya memiliki nilai yang cukup dapat diprediksi, mungkin berurutan. Meskipun seseorang dapat menggunakan berbagai teknik untuk menyembunyikan atau mengacak ID ini dan membuatnya sulit untuk ditebak, pendekatan semacam itu umumnya tidak cukup dengan sendirinya. Seorang pengguna tidak boleh dapat mengakses sumber daya yang tidak mereka miliki izinnya hanya karena mereka dapat menebak dan memanipulasi pengenal objek tersebut dalam parameter kueri atau di tempat lain. Alih-alih bergantung pada bentuk keamanan melalui ketidakjelasan, fokus harus pada mengontrol akses ke objek dasar dan/atau pengidentifikasi itu sendiri. Mitigasi yang disarankan untuk kelemahan ini meliputi hal-hal berikut:

  • Hindari mengekspos pengenal kepada pengguna jika memungkinkan. Misalnya, harus memungkinkan untuk mengambil beberapa objek, seperti detail akun, hanya berdasarkan identitas dan atribut pengguna yang saat ini terautentikasi (misalnya, melalui informasi yang terkandung dalam JSON Web Token (JWT) yang diimplementasikan dengan aman atau sesi sisi server).
  • Terapkan referensi tidak langsung yang spesifik untuk pengguna/sesi menggunakan alat seperti OWASP ESAPI (lihat OWASP 2013 Top 10 - A4 Insecure Direct Object References)
  • Lakukan pemeriksaan kontrol akses pada setiap permintaan untuk objek atau fungsionalitas spesifik yang diakses. Hanya karena seorang pengguna memiliki akses ke objek dari jenis tertentu tidak berarti mereka harus memiliki akses ke setiap objek dari jenis tertentu tersebut.

Terapkan Pemeriksaan Otorisasi pada Sumber Daya Statis​

Pentingnya mengamankan sumber daya statis sering kali diabaikan atau setidaknya tersisihkan oleh kekhawatiran keamanan lainnya. Meskipun mengamankan basis data dan penyimpanan data serupa sering kali mendapat perhatian signifikan dari tim yang sadar keamanan, sumber daya statis juga harus diamankan dengan tepat. Meskipun sumber daya statis yang tidak terlindungi tentu saja menjadi masalah bagi situs web dan aplikasi web dalam segala bentuk, dalam beberapa tahun terakhir, sumber daya yang kurang terlindungi dalam penawaran penyimpanan awan (seperti Amazon S3 Buckets) telah menjadi perhatian utama. Saat mengamankan sumber daya statis, pertimbangkan hal-hal berikut:

  • Pastikan bahwa sumber daya statis dimasukkan ke dalam kebijakan kontrol akses. Jenis perlindungan yang diperlukan untuk sumber daya statis akan sangat bergantung pada konteks. Mungkin sepenuhnya dapat diterima bagi beberapa sumber daya statis untuk dapat diakses publik, sementara yang lain hanya boleh diakses ketika atribut pengguna dan lingkungan yang sangat ketat hadir. Memahami jenis data yang diekspos dalam sumber daya tertentu yang sedang dipertimbangkan sangatlah penting. Pertimbangkan apakah skema Klasifikasi Data formal harus dibuat dan dimasukkan ke dalam logika kontrol akses aplikasi (lihat di sini untuk gambaran umum klasifikasi data).
  • Pastikan layanan berbasis cloud yang digunakan untuk menyimpan sumber daya statis diamankan menggunakan opsi konfigurasi dan alat yang disediakan oleh vendor. Tinjau dokumentasi penyedia cloud (lihat panduan dari AWS, Google Cloud dan Azure untuk detail implementasi spesifik).
  • Jika memungkinkan, lindungi sumber daya statis menggunakan logika dan mekanisme kontrol akses yang sama yang digunakan untuk mengamankan sumber daya dan fungsionalitas aplikasi lainnya.

Verifikasi bahwa Pemeriksaan Otorisasi Dilakukan di Lokasi yang Tepat​

Pengembang tidak boleh mengandalkan pemeriksaan kontrol akses sisi klien. Meskipun pemeriksaan semacam itu mungkin diperbolehkan untuk meningkatkan pengalaman pengguna, mereka tidak boleh menjadi faktor penentu dalam memberikan atau menolak akses ke suatu sumber daya; logika sisi klien seringkali mudah untuk dilewati. Pemeriksaan kontrol akses harus dilakukan di sisi server, di gerbang, atau menggunakan fungsi tanpa server (lihat OWASP ASVS 4.0.3, V1.4.1 dan V4.1.1).

Keluar dengan Aman ketika Pemeriksaan Otorisasi Gagal​

Pemeriksaan kontrol akses yang gagal adalah kejadian normal dalam aplikasi yang aman; oleh karena itu, pengembang harus merencanakan kegagalan semacam itu dan menanganinya dengan aman. Penanganan yang tidak tepat terhadap kegagalan semacam itu dapat menyebabkan aplikasi berada dalam keadaan yang tidak dapat diprediksi (CWE-280: Penanganan yang Tidak Tepat terhadap Izin atau Hak Akses yang Tidak Memadai). Rekomendasi spesifik termasuk yang berikut:

  • Pastikan semua pengecualian dan pemeriksaan kontrol akses yang gagal ditangani tidak peduli seberapa kecil kemungkinannya (OWASP Top Ten Proactive Controls C10: Tangani semua kesalahan dan pengecualian). Ini tidak berarti bahwa sebuah aplikasi harus selalu mencoba untuk "memperbaiki" kesalahan; seringkali sebuah pesan sederhana atau kode status HTTP sudah cukup.
  • Sentralisasikan logika untuk menangani pemeriksaan kontrol akses yang gagal.
  • Verifikasi penanganan kegagalan pengecualian dan otorisasi. Pastikan bahwa kegagalan semacam itu, tidak peduli seberapa kecil kemungkinannya, tidak membuat perangkat lunak berada dalam keadaan tidak stabil yang dapat menyebabkan bypass otorisasi.
Copyright © - This cheat sheet was created from the OWASP CheatSheetSeries reference - Source :https://cheatsheetseries.owasp.org/​