Hasil Hunting: Tanpa Akun Bisa Menjadi Administrator

Ringkasan Hasil Hunting

Jalur registrasi publik seharusnya hanya menghasilkan akun biasa. Namun, ketika satu atribut hak akses dikirim dari sisi klien, backend menerimanya sebagai keputusan otorisasi dan membuat identitas administrator.

Ini bukan kesimpulan dari tampilan menu, HTTP 200, atau scanner. Profil server mengonfirmasi role administrator. Sesi yang sama dapat membaca inventaris akun yang terlindungi serta menjalankan operasi terbatas pada record sintetis milik audit. Rantai buktinya adalah aktor anonim → identitas administrator → fungsi administratif yang terlindungi → perubahan state yang terbaca kembali.

Aturan Keamanan

Pengunjung anonim hanya boleh membuat akun dengan role aman yang ditentukan server. Pemberian role administrator harus membutuhkan aktor berwenang, proses khusus, dan audit trail.

Pemetaan Permukaan dan Alur Registrasi

Hunting dimulai dari pemetaan halaman publik, alur registrasi, aset JavaScript, request API yang benar-benar dipanggil, dan perpindahan state sebelum serta sesudah login. Kali Linux digunakan sebagai lingkungan assessment. httpx dan Katana membantu memetakan host dan route tanpa brute force. Analisis JavaScript kemudian memperlihatkan kontrak request dan call site nyata.

Hipotesisnya sempit: backend mungkin mempercayai role yang dikendalikan klien. Falsifier-nya jelas: bila server mengabaikan atau menolak role terlarang, jalur ditutup. Bila server menyimpannya dan fungsi administratif dapat digunakan, keputusan otorisasi gagal.

Dari Hipotesis ke Bukti Runtime

1. Baseline berhasil

Registrasi normal dengan identitas audit menghasilkan akun biasa. Alur dan lingkungan terbukti bekerja, tetapi akun tidak mendapat fungsi administratif.

2. Satu variabel diubah

Request setara dijalankan dengan identitas audit baru. Hanya atribut role yang dimutasi; transport, urutan, dan struktur lainnya dipertahankan. Pembacaan profil server menyatakan akun baru sebagai administrator.

3. Kontrol Pembanding

Registrasi normal tetap menghasilkan pengguna biasa, sedangkan nilai role yang tidak valid tidak memberi fungsi administratif serupa. Kontrol ini menyingkirkan penjelasan cache, tampilan klien, dan dugaan bahwa semua registrasi otomatis menjadi admin.

4. Pembacaan state server

Sesi hasil mutasi dapat membuka inventaris akun yang terlindungi. Untuk membuktikan integritas tanpa menyentuh data nyata, tim membuat, menyunting, membaca ulang, lalu menghapus record sintetis. Marker canary diverifikasi tidak tersisa.

Tool yang Digunakan dan Peran Sebenarnya

• Kali Linux menjadi lingkungan pemetaan dan analisis.
• httpx dan Katana menginventarisasi surface yang terjangkau.
• Caido dipakai untuk Replay, request diff, dan eksperimen satu variabel.
• Codex CLI membantu review JavaScript, call site, dan skrip verifikasi.
• HTTP client dan Python menjalankan eksperimen, parsing, dan pemeriksaan canary.
• Browser dan SHA-256 membantu QA perilaku akhir dan integritas artefak.

Server, bukan tool, yang menentukan kesimpulan. Tool membantu observasi; finding baru confirmed setelah role, fungsi admin, perubahan state, kontrol, reproduksi, dan cleanup diverifikasi langsung dari server.

Dampak Terverifikasi

Kerahasiaan: administrator hasil registrasi anonim dapat membaca inventaris akun yang tidak tersedia bagi akun standar. Integritas: sesi tersebut dapat membuat, mengubah, dan menghapus data sintetis melalui fungsi administratif. Tidak diperlukan akun awal, undangan, atau persetujuan administrator yang sah.

Batas Klaim dan Cleanup

Tidak ada account takeover, dokumen pengguna nyata tidak dibuka, data pihak ketiga tidak diubah, tidak ada RCE, gangguan availability, atau dampak finansial. Artikel tidak mengklaim kompromi penuh.

Semua record sintetis dan marker canary telah dihapus dan dibaca ulang. Akun administrator sintetis diserahkan kepada operator sistem untuk dicabut; kami tidak menyatakan revokasi akun selesai tanpa bukti operator yang baru.

Akar Masalah

Backend menjadikan input role dari klien sebagai sumber keputusan hak akses. Aplikasi tidak memaksakan default aman dan tidak memeriksa apakah aktor yang meminta role itu berwenang memberikannya. Ini kegagalan server-side authorization, bukan sekadar field tersembunyi di UI.

Remediasi untuk Developer

1. Hapus role dari kontrak registrasi publik. Hidden input dan validasi browser bukan kontrol keamanan.
2. Tetapkan role aman di server. Seluruh self-registration harus memperoleh role standar.
3. Pisahkan provisioning administrator. Wajibkan sesi admin sah dan audit log.
4. Validasi ulang pada titik penggunaan. Periksa role dan scope dari state server.
5. Audit akun yang sudah terbentuk. Cari admin dari jalur self-registration dan cabut secara terkontrol.
6. Tambahkan regression test. Uji web, API, mobile, endpoint lama, dan worker terkait.

Regression Test yang Wajib Ada

Jalankan baseline pengguna biasa, mutasi yang meminta role admin, dan kontrol malformed. Assertion harus membaca profil server dan memastikan fungsi administratif ditolak, bukan hanya mencocokkan status code. Gunakan identitas dan sesi baru, teardown, serta pemeriksaan state sisa.

Pelajaran untuk Tim Engineering

Developer tidak boleh memperlakukan nilai dari browser sebagai keputusan otorisasi. Pengguna mengendalikan request-nya sendiri. Batas kepercayaan berada di server, tempat aktor, role, operasi, objek, dan lifecycle diperiksa bersama.

Mengapa HTTP 200 Belum Cukup?

Respons sukses hanya membuktikan server memproses sebuah request. Respons itu belum menjawab role apa yang tersimpan, pemeriksaan izin apa yang dilewati, atau apakah operasi berikutnya benar-benar diterima. Karena itu setiap tahap diperiksa melalui pembacaan profil, akses ke fungsi yang seharusnya terbatas, serta state record sebelum dan sesudah eksperimen.

Pemisahan tersebut penting bagi developer saat melakukan retest. Patch yang hanya mengganti pesan respons atau menyembunyikan menu belum memperbaiki akar masalah apabila backend masih menyimpan role dari klien. Sebaliknya, penolakan role oleh server harus terlihat pada state akhir dan tetap konsisten ketika request dikirim melalui antarmuka lain.

Model Ancaman yang Relevan

Precondition kasus ini sangat rendah: aktor berada di internet dan dapat membuka registrasi publik. Mekanismenya adalah atribut hak akses yang dapat ditambahkan atau diubah pada request. Keputusan kepercayaan server gagal ketika backend memperlakukan atribut itu sebagai kewenangan. Batas otorisasi terbukti dilewati saat identitas anonim berubah menjadi administrator dan fungsi terbatas menerima sesi tersebut.

Dua penjelasan benign diuji. Pertama, role mungkin hanya label tampilan tanpa otoritas nyata. Penjelasan ini gugur setelah fungsi inventaris dan operasi data sintetis berhasil. Kedua, akun mungkin telah mendapat izin dari sesi lama. Identitas baru dan sesi baru menutup jalur tersebut, sementara akun baseline tetap menjadi pengguna biasa.

Mengapa Temuan Ini Penting bagi Bisnis?

Role administrator biasanya menjadi pintu ke pengelolaan identitas, konfigurasi, dan data operasional. Pada kasus ini kami hanya menjalankan bukti minimum yang aman, tetapi organisasi tetap perlu memperlakukan jalur registrasi sebagai insiden kontrol akses: audit akun yang terbentuk, periksa log provisioning, cabut sesi yang relevan, lalu retest seluruh transport yang menggunakan layanan identitas yang sama.

Bagi manajemen, prioritasnya bukan menambah captcha atau memperumit formulir. Captcha dapat mengurangi otomasi tetapi tidak memperbaiki keputusan otorisasi. Perbaikan harus memastikan server sendiri memilih role aman dan hanya workflow administratif terpisah yang dapat menaikkan privilege.

Kesimpulan

Hasil hunting ini menunjukkan bagaimana satu keputusan backend yang teledor dapat mengubah pengunjung anonim menjadi administrator. Temuan dinyatakan High Confirmed karena fungsi administratif yang terlindungi dan perubahan data sintetis dapat direproduksi serta diverifikasi. Detail eksploitasi tetap privat; pelajaran desain dan remediasinya dipublikasikan untuk developer.