Authentic HackerOne Access Control Vulnerability Earning $5000 - Complete Analysis Included

Blog mendetail ini membahas eksploitasi nyata kerentanan Broken Access Control yang dilaporkan di HackerOne dan menghasilkan hadiah sebesar $5000. Blog ini membahas secara mendalam bagaimana peneliti menemukan eskalasi hak istimewa yang tidak aman, menggunakan permintaan yang dibuat-buat untuk mengakses sumber daya yang tidak sah, melewati batasan peran, dan mengungkapkan masalah tersebut secara bertanggung jawab. Pelajari bagaimana kontrol akses modern dapat gagal, bagaimana penyerang memanipulasi titik akhir, dan bagaimana pengembang dapat mengamankan API dan aplikasi dari ancaman ini.

Table of Contents

1. Apa Itu Kontrol Akses yang Rusak dalam Keamanan Web?
2. Tinjauan Umum Aplikasi Target
3. Bagaimana Saya Menemukan Kerentanan
4. Melewati Mekanisme Kontrol Akses
5. Pelaporan dan Triase di HackerOne
6. Pembayaran dan Pengakuan
7. Pelajaran yang Dipetik
8. Ringkasan Singkat Eksploitasi Bug
9. Relevansi Dunia Nyata
10. Pertanyaan yang Sering Diajukan (FAQ)

Apa Itu Kontrol Akses yang Rusak dalam Keamanan Web?

Kontrol Akses Rusak (Break Access Control/BAC) terjadi ketika pengguna dapat mengakses data atau melakukan tindakan di luar hak akses yang seharusnya. Hal ini termasuk dalam 10 kerentanan teratas OWASP, dan sering kali menyebabkan paparan data yang serius atau pengambilalihan akun. Blog ini memandu Anda melalui hadiah bug dunia nyata tempat saya menemukan kerentanan Broken Access Control yang kritis pada program pribadi HackerOne, yang membuat saya mendapat hadiah sebesar $5000.

Tinjauan Umum Aplikasi Target

Targetnya adalah platform fintech perbankan yang dihosting di AWS, dengan backend REST API yang bersih. Platform ini mencakup dasbor pengguna, riwayat transaksi, dan tiket dukungan.

Alat yang digunakan:

Alat	Tujuan
Burp Suite	Menyadap dan mengubah permintaan
Postman	Menguji titik akhir API
Alat Pengembang Chrome	Men-debug perilaku frontend
Python (permintaan)	Otomatisasi dan skrip muatan

Bagaimana Saya Menemukan Kerentanan

Langkah 1: Memahami Alur API

Saya mulai dengan pengintaian dasar. Setelah masuk ke akun pengguna dengan hak istimewa rendah, saya melihat titik akhir API seperti:

GET /api/v1/user/12345/tickets

ID numerik tersebut sepertinya merupakan referensi objek langsung. Saya mengubah 12345 menjadi 12344 dan mendapatkan 403 Forbidden. Sejauh ini bagus.

Langkah 2: Menemukan Pemeriksaan Akses yang Tidak Konsisten

Namun saya menemukan rute API yang berbeda:

GET /api/v1/tickets/view?ticket_id=8765

Titik akhir ini tidak memverifikasi kepemilikan tiket oleh pengguna. Dengan mengubah ID tiket, saya dapat melihat permintaan dukungan yang diajukan oleh pengguna lain, termasuk keluhan rekening bank. Ini mengonfirmasi kombinasi IDOR + BAC klasik.

Melewati Mekanisme Kontrol Akses

Saya mengotomatiskan serangan menggunakan Python:

import requests

headers = {
    'Authorization': 'Bearer ',
}

for i in range(8700, 8800):
    url = f'https://bankingapp.com/api/v1/tickets/view?ticket_id={i}'
    r = requests.get(url, headers=headers)
    if "user_email" in r.text:
        print(f"[+] Ticket {i} exposed!")

Server merespons dengan PII lengkap (nama, email, nomor akun) tanpa memvalidasi kepemilikan sesi.

Pelaporan dan Triase di HackerOne

Saya menyerahkan laporan dengan:

• Detail titik akhir
• Langkah-langkah untuk mereproduksi
• Skrip Python POC
• Tangkapan layar data yang terpengaruh

Dalam waktu 3 jam, tim triase merespons dan mengonfirmasi masalah tersebut. Tiket tersebut ditandai sebagai Tingkat Keparahan Tinggi, dan tim memperbaiki API dalam waktu 24 jam.

Pembayaran dan Pengakuan

Beberapa hari kemudian, saya menerima hadiah $5000 dan tempat di hall of fame pribadi mereka.

Klasifikasi HackerOne:

• Jenis Kerentanan: Kontrol Akses Rusak (IDOR)
• Dampak: Pengungkapan PII
• Tingkat Keparahan: Tinggi

Pelajaran yang Dipetik

• Selalu uji rute atau versi alternatif dari suatu titik akhir.
• Hanya karena satu titik akhir aman, tidak berarti semuanya aman.
• Banyak IDOR masih bersembunyi di balik ketidakjelasan sisi klien atau inkonsistensi API.
• Alat seperti Burp Repeater, Postman, dan Python adalah kunci untuk meningkatkan skala pemeriksaan Anda.

Ringkasan Singkat Eksploitasi Bug

Aspek	Rincian
Kerentanan	Kontrol Akses Rusak melalui IDOR
Titik Akhir yang Dieksploitasi	/api/v1/tickets/view
Alat yang digunakan	Burp, Postman, Python
Kerasnya	Tinggi
Karunia	$5000
Waktu Respons	<3 jam
Memperbaiki Waktu	24 jam

Relevansi Dunia Nyata

Serangan ini mencerminkan ancaman dunia nyata yang masih ada dalam aplikasi tingkat perusahaan. Meskipun kontrol akses merupakan masalah yang diketahui, banyak API masih belum memiliki verifikasi otorisasi yang tepat. Perusahaan harus menerapkan pemeriksaan akses sisi server, tidak bergantung pada logika klien atau ID yang dikaburkan. Melalui tulisan ini, saya berharap dapat menunjukkan pentingnya pengujian manual, perhatian terhadap detail, dan pemahaman perilaku backend di luar logika UI. Jika Anda seorang calon pemburu bug bounty atau peneliti keamanan, selalu uji akses di luar apa yang Anda lihat. Terkadang, hanya dengan mengubah parameter saja dapat menghasilkan keuntungan besar.

Pertanyaan yang Sering Diajukan (FAQ)

Apa itu Kontrol Akses Rusak?

Kontrol Akses yang Rusak terjadi ketika pengguna dapat bertindak di luar izin yang seharusnya, seperti mengakses data yang tidak sah atau melakukan tindakan admin.

Bagaimana peneliti menemukan kerentanan kontrol akses yang rusak?

Mereka menguji titik akhir yang dibatasi peran dan memperhatikan bahwa modifikasi ID pengguna atau token memungkinkan akses ke data pengguna yang sensitif dan fungsi istimewa.

Berapa besar hadiah yang diberikan?

Peneliti menerima $5000 karena secara bertanggung jawab mengungkapkan kelemahan kontrol akses yang kritis ini.

Alat apa yang digunakan untuk menemukan kerentanan?

Burp Suite, alat pengembangan browser, Postman, dan skrip Python khusus untuk mengotomatiskan pengujian titik akhir digunakan.

Apa perbedaan antara kontrol akses vertikal dan horizontal?

Vertikal melibatkan perolehan akses ke peran yang lebih tinggi, sementara horizontal berarti mengakses data pengguna lain pada tingkat yang sama.

Bagaimana kontrol akses yang rusak dapat diatasi?

Gunakan validasi akses sisi server, terapkan prinsip hak istimewa paling sedikit, dan terapkan kontrol akses berbasis peran (RBAC).

Apakah Kontrol Akses yang Rusak termasuk dalam 10 Teratas OWASP?

Ya, ini salah satu risiko teratas dalam OWASP Top 10 (A01:2021).

Pelajaran apa yang dapat dipelajari pengembang dari hal ini?

Jangan pernah memercayai input pengguna untuk otorisasi. Selalu validasi tindakan di server menggunakan pemeriksaan identitas dan kepemilikan pengguna.