Sebuah aplikasi dapat lolos dari pengujian kerentanan teknis, tetapi tetap memungkinkan pengguna menyetujui transaksinya sendiri. Sistem dapat terbebas dari SQL injection dan cross-site scripting, tetapi masih membiarkan diskon digunakan berulang kali. API dapat merespons dengan aman terhadap input berbahaya, tetapi tetap mengizinkan pengguna membuka data milik akun lain hanya dengan mengganti nomor identifikasi objek.

Situasi tersebut memperlihatkan satu persoalan penting: aplikasi yang sulit ditembus belum tentu sulit disalahgunakan.

Pentest black box memiliki peran penting dalam mengukur keamanan aplikasi dari perspektif pihak eksternal. Namun, ketika aplikasi memiliki banyak jenis pengguna, tahapan persetujuan, integrasi API, perhitungan transaksi, serta aturan operasional khusus, informasi yang terbatas dapat membuat bagian paling kritis dari sistem tidak teruji secara mendalam.

Masalahnya bukan karena metode black box tidak berguna. Masalah muncul ketika perusahaan menjadikannya sebagai satu-satunya pendekatan untuk menjawab seluruh risiko keamanan aplikasi.

Perspektif Penyerang Eksternal Bukan Gambaran Risiko yang Lengkap

Dalam pentest black box, penguji umumnya menerima informasi yang sangat terbatas mengenai target. Pendekatan ini dirancang untuk mensimulasikan kondisi penyerang eksternal yang belum mengetahui arsitektur sistem, kode sumber, akun internal, maupun alur operasional aplikasi.

Perspektif tersebut sangat relevan untuk mengevaluasi permukaan serangan yang terlihat dari internet. Penguji dapat menilai keamanan halaman publik, mekanisme autentikasi, konfigurasi server, endpoint yang terbuka, layanan jaringan, serta berbagai kerentanan teknis yang dapat ditemukan tanpa akses internal.

Namun, aplikasi bisnis tidak hanya terdiri atas halaman login dan fungsi publik.

Setelah pengguna masuk, aplikasi mulai menjalankan aturan yang jauh lebih kompleks. Sistem menentukan siapa yang boleh melihat data, siapa yang dapat mengubah status transaksi, berapa kali fitur tertentu boleh digunakan, serta tahapan apa saja yang harus diselesaikan sebelum suatu proses dinyatakan sah.

Apabila penguji hanya memperoleh satu akun atau bahkan tidak memperoleh akun sama sekali, cakupan pengujian akan berhenti sebelum sebagian besar keputusan bisnis tersebut dapat dianalisis.

Black box dapat menjawab pertanyaan mengenai cara penyerang mencoba masuk dari luar. Metode ini belum tentu cukup untuk menjawab apa yang dapat dilakukan oleh pengguna setelah berhasil berada di dalam sistem.

Kerentanan Logika Bisnis Tidak Selalu Terlihat seperti Serangan

Sebagian besar perusahaan memahami kerentanan melalui pola yang mudah dikenali. Input berbahaya dimasukkan ke formulir, server memberikan respons yang tidak semestinya, kemudian penyerang memperoleh akses atau data sensitif.

Business logic vulnerability bekerja dengan cara yang berbeda.

Pada banyak kasus, penyerang tidak perlu mengirimkan kode berbahaya. Penyerang cukup menggunakan fitur yang tersedia, tetapi menjalankannya dalam urutan, jumlah, atau konteks yang tidak pernah diperkirakan oleh pengembang.

Sebagai contoh, sebuah aplikasi procurement mungkin mewajibkan staf membuat permintaan pembelian, supervisor memberikan persetujuan, dan bagian keuangan memproses pembayaran. Alur tersebut terlihat aman saat setiap pengguna mengikuti prosedur.

Risiko muncul ketika aplikasi tidak benar-benar memeriksa pemisahan kewenangan. Seorang staf mungkin dapat mengubah parameter permintaan dan menyetujui transaksi yang dibuatnya sendiri. Pada kasus lain, pengguna dapat langsung memanggil endpoint persetujuan tanpa melewati tahapan verifikasi sebelumnya.

Secara teknis, setiap fungsi dapat berjalan sesuai desain. Akan tetapi, kombinasi antarfungsi menghasilkan tindakan yang seharusnya tidak diperbolehkan.

Kerentanan serupa dapat muncul dalam berbagai bentuk:

• Kupon promosi dapat digunakan lebih dari satu kali.
• Harga produk dapat diubah melalui request sebelum pembayaran.
• Status pesanan dapat diperbarui tanpa bukti pembayaran.
• Pengguna dapat membatalkan transaksi setelah manfaat diterima.
• Limit transaksi dapat dilewati melalui beberapa permintaan paralel.
• Dokumen yang telah kedaluwarsa masih dapat digunakan.
• Pengguna dapat mengubah data milik pengguna lain.
• Pembuat transaksi dapat bertindak sebagai pemberi persetujuan.
• Proses verifikasi dapat dilewati dengan memanggil tahapan akhir secara langsung.

Tidak semua kondisi tersebut akan terdeteksi hanya dengan mencari pola serangan teknis. Penguji perlu memahami tujuan fitur, hubungan antar-role, serta batasan bisnis yang seharusnya diterapkan.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Kompleksitas Role Memperluas Permukaan Serangan

Aplikasi sederhana mungkin hanya membedakan pengguna umum dan administrator. Sebaliknya, aplikasi bisnis dapat memiliki staf, supervisor, manajer, auditor, vendor, mitra, pelanggan, operator, dan administrator dengan hak akses yang berbeda.

Semakin banyak role yang tersedia, semakin banyak pula hubungan akses yang perlu diuji.

Pengujian tidak cukup dilakukan dengan memastikan setiap pengguna dapat membuka menu yang sesuai. Kontrol akses juga harus diterapkan pada sisi server, objek data, endpoint API, fungsi administratif, serta setiap perubahan status yang dilakukan pengguna.

Kelemahan akses biasanya muncul dalam tiga pola utama.

Pengguna Mengakses Data Pengguna Lain

Pengguna dapat melihat atau mengubah objek milik pengguna lain meskipun keduanya memiliki tingkat kewenangan yang sama.

Contohnya, seorang vendor hanya diperbolehkan mengakses dokumen perusahaannya sendiri. Namun, dengan mengganti nomor dokumen pada request, vendor tersebut dapat membuka dokumen perusahaan lain.

Antarmuka mungkin tidak pernah menampilkan dokumen tersebut. Meskipun demikian, endpoint backend tetap mengirimkan data karena tidak memeriksa kepemilikan objek secara memadai.

Pengguna Menjalankan Fungsi dengan Kewenangan Lebih Tinggi

Pengguna biasa dapat mengakses fungsi yang seharusnya hanya tersedia bagi administrator, supervisor, atau pihak yang memiliki otorisasi khusus.

Tombol untuk menjalankan fungsi mungkin telah disembunyikan dari antarmuka. Akan tetapi, menyembunyikan tombol tidak sama dengan menerapkan kontrol akses.

Apabila endpoint masih menerima request dari akun biasa, pembatasan hanya terjadi pada tampilan, bukan pada sistem yang memproses tindakan tersebut.

Pemisahan Tugas Tidak Berjalan

Aplikasi bisnis sering menggunakan segregation of duties untuk mencegah satu pihak mengendalikan seluruh proses. Pengguna yang membuat transaksi seharusnya tidak dapat menyetujui transaksi yang sama. Pihak yang memasukkan data pembayaran juga tidak seharusnya menjadi satu-satunya pihak yang memverifikasinya.

Kelemahan seperti ini hanya dapat ditemukan apabila pengujian mencakup beberapa role dan hubungan di antara role tersebut.

Satu akun pengujian tidak cukup untuk membuktikan bahwa pemisahan kewenangan telah berjalan dengan benar.

Login Seharusnya Menjadi Awal Pengujian

Pada aplikasi bisnis, autentikasi bukan garis akhir keamanan. Login justru menjadi pintu masuk menuju area yang menyimpan proses, data, dan kewenangan paling sensitif.

Setelah berhasil login, penguji perlu memeriksa lebih dari sekadar kemampuan pengguna membuka halaman tertentu. Pengujian perlu melihat cara aplikasi membuat keputusan pada setiap tindakan.

Beberapa pertanyaan yang perlu dijawab antara lain:

• Apakah pengguna hanya dapat mengakses data yang menjadi kewenangannya?
• Apakah perubahan role langsung mencabut hak akses sebelumnya?
• Apakah proses persetujuan dapat dilewati?
• Apakah request lama dapat digunakan kembali?
• Apakah status transaksi dapat diubah secara langsung?
• Apakah pengguna dapat memanggil fungsi yang tidak tersedia pada menunya?
• Apakah objek yang telah dibatalkan masih dapat diproses?
• Apakah akun yang dinonaktifkan masih memiliki sesi aktif?
• Apakah data sensitif tetap terlindungi ketika diekspor?
• Apakah pengguna dapat menjalankan tindakan yang saling bertentangan?

Pertanyaan-pertanyaan tersebut tidak selalu dapat dijawab melalui pengujian tanpa kredensial. Penguji membutuhkan akun, konteks, dan skenario yang cukup untuk mengevaluasi keputusan aplikasi setelah autentikasi.

API Dapat Mengabaikan Pembatasan pada Antarmuka

Banyak aplikasi modern memisahkan tampilan dari proses backend. Web dan mobile application berfungsi sebagai antarmuka, sedangkan sebagian besar keputusan serta pertukaran data berjalan melalui API.

Pemisahan ini memberikan fleksibilitas bagi pengembangan sistem. Namun, API juga dapat menjadi jalur untuk melewati pembatasan yang hanya diterapkan pada antarmuka pengguna.

Sebuah formulir mungkin membatasi jumlah pembelian maksimal lima unit. Pengguna tidak dapat mengetikkan angka yang lebih besar melalui tampilan. Namun, batas tersebut tidak berarti aman apabila endpoint API tetap menerima jumlah seratus unit.

Hal serupa dapat terjadi pada proses approval. Antarmuka hanya menampilkan tombol persetujuan kepada supervisor. Akan tetapi, pengguna biasa dapat mencoba mengirimkan request yang sama secara langsung.

Risiko lainnya muncul ketika API menggunakan identifier untuk menentukan objek. Tanpa pemeriksaan otorisasi pada setiap request, pengguna cukup mengganti identifier untuk membaca atau memodifikasi data yang bukan miliknya.

Karena itu, pengujian aplikasi tidak seharusnya berhenti pada tampilan web. API perlu diuji sebagai bagian dari alur bisnis yang utuh, termasuk hubungan antara identitas pengguna, objek yang diakses, fungsi yang dijalankan, dan status proses yang sedang berlangsung.

Automated Scanning Tidak Memahami Tujuan Sebuah Fitur

Automated vulnerability scanner sangat berguna untuk menemukan pola teknis, konfigurasi yang lemah, komponen rentan, input tidak aman, serta berbagai masalah yang memiliki indikator terukur.

Namun, perangkat otomatis tidak selalu mengetahui tujuan bisnis dari sebuah fitur.

Scanner mungkin mengetahui bahwa endpoint memberikan respons berhasil. Scanner belum tentu memahami bahwa endpoint tersebut hanya boleh digunakan satu kali. Scanner dapat membaca bahwa pengguna menerima data, tetapi belum tentu mengetahui bahwa data tersebut seharusnya hanya dapat dilihat oleh divisi lain.

Pemahaman tersebut membutuhkan konteks.

Untuk menilai logika bisnis, penguji harus mengetahui kondisi yang dianggap normal, tindakan yang seharusnya ditolak, serta dampak yang muncul ketika pengguna melakukan proses di luar skenario yang dirancang.

Sebagai contoh, sistem dapat mengizinkan pengguna mengajukan refund. Fungsi tersebut bukan kerentanan. Masalah baru muncul apabila refund dapat diajukan beberapa kali untuk transaksi yang sama, tetap diproses setelah layanan dikonsumsi, atau dibayarkan ke rekening yang berbeda tanpa verifikasi tambahan.

Perangkat otomatis dapat membantu menemukan pintu masuk. Namun, penilaian manual tetap dibutuhkan untuk memahami apakah fungsi yang sah dapat diubah menjadi sarana penyalahgunaan.

Grey Box Memberikan Konteks yang Dibutuhkan

Pengujian grey box memberikan informasi dan akses terbatas kepada penguji. Informasi tersebut dapat berupa akun untuk beberapa role, dokumentasi API, gambaran workflow, aturan hak akses, data uji, atau daftar proses bisnis yang dianggap kritis.

Pemberian informasi bukan berarti pengujian menjadi kurang objektif.

Sebaliknya, konteks yang memadai membuat waktu pengujian dapat diarahkan pada bagian aplikasi yang paling berpengaruh terhadap bisnis. Penguji tidak perlu menghabiskan sebagian besar waktu hanya untuk menemukan alur penggunaan dasar yang sebenarnya dapat dijelaskan sejak awal.

Dengan akun dari beberapa role, penguji dapat membandingkan akses horizontal dan vertikal. Dengan dokumentasi workflow, penguji dapat mencoba melewati, mengulang, membalik, atau menjalankan proses dalam urutan yang berbeda.

Grey box sangat relevan ketika aplikasi memiliki karakteristik berikut:

• Memiliki banyak jenis pengguna.
• Menjalankan approval bertingkat.
• Mengelola saldo atau transaksi.
• Menyimpan data milik beberapa organisasi.
• Menggunakan API untuk fungsi utama.
• Memiliki portal khusus vendor atau mitra.
• Menggunakan workflow berdasarkan status.
• Menerapkan kuota, limit, promo, atau entitlement.
• Menangani dokumen dan data sensitif.
• Mengintegrasikan beberapa sistem internal.

Pendekatan ini bukan pengganti black box. Keduanya dapat digunakan secara berlapis untuk menjawab tujuan pengujian yang berbeda.

White Box Dibutuhkan untuk Menemukan Akar Masalah

Pada sistem yang sangat kritis atau memiliki arsitektur kompleks, pengujian dari permukaan mungkin belum cukup untuk menjelaskan penyebab kelemahan.

White box penetration testing memberikan akses yang lebih luas, seperti kode sumber, dokumentasi arsitektur, konfigurasi, serta informasi implementasi kontrol keamanan.

Pendekatan ini memungkinkan penguji memeriksa apakah otorisasi diterapkan secara konsisten pada setiap layanan. Penguji juga dapat menilai apakah validasi hanya dilakukan pada sisi klien, apakah satu fungsi keamanan digunakan oleh seluruh modul, atau apakah terdapat jalur kode tertentu yang melewati pemeriksaan utama.

White box dapat dipertimbangkan ketika:

• Aplikasi memproses transaksi kritis.
• Sistem menggunakan microservices dalam jumlah besar.
• Kontrol akses dikembangkan secara khusus.
• Terdapat banyak integrasi internal dan eksternal.
• Kesalahan desain berpotensi menyebar ke banyak modul.
• Perusahaan membutuhkan analisis akar masalah.
• Temuan sebelumnya menunjukkan kelemahan yang sistemis.
• Aplikasi mendukung proses operasional utama perusahaan.

White box bukan metode yang secara otomatis lebih baik untuk semua kondisi. Pendekatan ini menjawab pertanyaan yang berbeda dari black box.

Black box menilai apa yang dapat dilakukan penyerang tanpa informasi internal. Grey box menguji penyalahgunaan oleh pihak yang telah memiliki akses tertentu. White box membantu menjelaskan mengapa kontrol keamanan gagal pada tingkat desain dan implementasi.

Black Box Tetap Tepat untuk Tujuan Tertentu

Menyatakan bahwa black box tidak selalu cukup bukan berarti metode tersebut harus ditinggalkan.

Pentest black box tetap tepat untuk menilai eksposur eksternal, menguji aplikasi publik, mengevaluasi mekanisme autentikasi awal, menemukan layanan yang terbuka, serta mengukur kemampuan kontrol perimeter menghadapi serangan tanpa kredensial.

Metode ini juga relevan untuk menjawab beberapa pertanyaan penting:

• Informasi apa yang dapat dikumpulkan penyerang dari internet?
• Endpoint mana yang dapat ditemukan tanpa dokumentasi?
• Apakah mekanisme login dapat diserang?
• Apakah terdapat kesalahan konfigurasi yang terlihat dari luar?
• Apakah layanan yang seharusnya tertutup dapat diakses?
• Apakah aplikasi membocorkan informasi sensitif sebelum autentikasi?

Black box menjadi tidak memadai ketika hasilnya digunakan untuk menyimpulkan bahwa seluruh alur bisnis aplikasi telah aman, padahal sebagian besar fungsi internal belum pernah diuji.

Dengan kata lain, keterbatasan bukan terletak pada metode, melainkan pada ketidaksesuaian antara metode dan tujuan pengujian.

Scope Pentest Tidak Seharusnya Hanya Berisi Daftar URL

Perusahaan sering menentukan scope penetration testing berdasarkan jumlah domain, alamat IP, aplikasi, atau endpoint. Informasi tersebut memang diperlukan untuk menghitung luas target teknis.

Namun, kompleksitas keamanan aplikasi tidak selalu sebanding dengan jumlah URL.

Satu aplikasi dapat memiliki satu domain, tetapi menjalankan puluhan role, ratusan endpoint API, proses approval bertingkat, serta integrasi dengan berbagai sistem. Sebaliknya, beberapa domain dapat hanya menyajikan fungsi publik yang sederhana.

Scope yang hanya mencantumkan alamat target berisiko mengabaikan bagian penting, seperti:

• Jumlah dan jenis role pengguna.
• Proses bisnis yang paling kritis.
• Objek data yang harus dipisahkan.
• Hubungan antara web, mobile, dan API.
• Tahapan perubahan status.
• Mekanisme approval.
• Aturan limit dan kuota.
• Fungsi administratif.
• Integrasi pihak ketiga.
• Skenario penyalahgunaan.
• Dampak terhadap operasional bisnis.

Scope yang baik seharusnya dibangun dari risiko, bukan hanya inventaris teknis.

Sebelum pengujian dimulai, perusahaan dan penyedia penetration testing perlu menyepakati proses mana yang harus diuji, akun apa saja yang tersedia, tindakan apa yang diperbolehkan, serta skenario apa yang dapat menimbulkan dampak paling besar.

Tanda Aplikasi Membutuhkan Lebih dari Pentest Black Box

Perusahaan perlu mempertimbangkan grey box, white box, atau kombinasi beberapa pendekatan apabila aplikasi:

1. Memiliki lebih dari dua role pengguna.
2. Mengelola transaksi, saldo, atau pembayaran.
3. Memiliki proses persetujuan bertingkat.
4. Menyimpan data dari banyak cabang atau organisasi.
5. Menggunakan API sebagai penghubung fungsi utama.
6. Memiliki fitur yang bergantung pada urutan proses.
7. Menggunakan limit, kuota, promo, atau hak penggunaan.
8. Menangani dokumen rahasia.
9. Memiliki portal vendor, mitra, atau pelanggan.
10. Menjalankan proses yang berdampak hukum atau finansial.
11. Menggunakan single sign-on atau sistem identitas terpusat.
12. Terhubung dengan sistem internal lain.
13. Memiliki fungsi administratif yang luas.
14. Menjadi bagian penting dari operasional perusahaan.

Semakin banyak kondisi yang terpenuhi, semakin besar kemungkinan pengujian tanpa konteks akan melewatkan risiko penting.

Pertanyaan yang Perlu Diajukan kepada Penyedia Pentest

Sebelum menentukan metode pengujian, perusahaan sebaiknya tidak hanya menanyakan harga dan durasi. Pertanyaan yang lebih penting adalah apakah pendekatan yang ditawarkan sesuai dengan karakter aplikasi.

Beberapa pertanyaan yang perlu diajukan antara lain:

• Apakah pengujian mencakup seluruh role utama?
• Apakah API termasuk dalam scope?
• Apakah penguji akan melakukan pengujian otorisasi antaruser?
• Apakah workflow dan proses approval akan diuji?
• Apakah pengujian mencakup penyalahgunaan fungsi yang sah?
• Apakah terdapat pengujian terhadap perubahan status transaksi?
• Apakah proses hanya menggunakan automated scanner?
• Apakah laporan menjelaskan dampak bisnis dari temuan?
• Apakah rekomendasi remediasi disesuaikan dengan akar masalah?
• Apakah tersedia retest setelah perbaikan dilakukan?

Jawaban atas pertanyaan tersebut membantu perusahaan membedakan pengujian yang hanya mencari kerentanan umum dengan pengujian yang benar-benar menilai ketahanan aplikasi.

Aplikasi yang Aman Harus Sulit Disalahgunakan

Keamanan aplikasi tidak cukup dinilai dari seberapa sulit pihak eksternal menembus halaman login. Perusahaan juga perlu membuktikan bahwa pengguna yang telah memiliki akses tidak dapat melampaui kewenangan, memanipulasi transaksi, melewati tahapan proses, atau menggunakan fungsi yang sah untuk tujuan yang merugikan.

Pentest black box tetap menjadi bagian penting dari strategi pengujian. Namun, aplikasi dengan logika bisnis kompleks membutuhkan konteks yang lebih lengkap, akun yang lebih beragam, dan skenario pengujian yang dibangun berdasarkan proses bisnis.

Metode pengujian seharusnya dipilih setelah perusahaan memahami risiko yang ingin dibuktikan. Bukan sebaliknya, yaitu memilih satu metode terlebih dahulu, kemudian memaksakan seluruh risiko aplikasi masuk ke dalam keterbatasan metode tersebut.

Tujuan penetration testing bukan hanya memastikan penyerang dari luar mengalami kesulitan untuk masuk. Pengujian juga harus memastikan bahwa pihak yang telah berada di dalam aplikasi tidak dapat mengubah fungsi yang sah menjadi jalur penyalahgunaan.

Pastikan Scope Pentest Sesuai dengan Risiko Aplikasi

Fourtrezz merupakan perusahaan cybersecurity dan IT development di Indonesia yang menyediakan layanan penetration testing, vulnerability assessment, pengujian keamanan aplikasi dan API, serta konsultasi keamanan siber. Fourtrezz membantu perusahaan menyusun pengujian berdasarkan karakter target, role pengguna, integrasi sistem, dan risiko bisnis yang perlu divalidasi.

Melalui pendekatan pengujian yang terukur, perusahaan dapat memperoleh gambaran yang lebih relevan mengenai kerentanan teknis, kelemahan kontrol akses, serta potensi penyalahgunaan logika bisnis.

Jangan hanya menguji apakah aplikasi dapat ditembus. Pastikan pula proses bisnis di dalamnya tidak dapat disalahgunakan.

Hubungi Fourtrezz:

Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]