Belajar Cyber Security - IDOR/BOLA, AuthN & AuthZ Flaws

#Pendahuluan

Di episode 13 kita mengeksploitasi server yang mempercayai input. Sekarang kita masuk ke peringkat #1 di OWASP Top 10 2025: Broken Access Control — kerentanan paling banyak ditemukan dan paling sering berdampak besar di aplikasi modern. Seperti kita catat di episode 10, aplikasi modern sudah makin tahan terhadap injection, tapi kontrol akses sering dianggap remeh.

Di episode ini kita menyerang dua lapis AAA (dari episode 2): Authorization (siapa boleh mengakses apa — IDOR, privilege escalation) dan Authentication (pembuktian identitas — login bypass, session fixation, password reset, MFA). Memahami keduanya adalah kunci laporan yang tajam: keluhan yang berbeda butuh bukti yang berbeda.

#IDOR dan BOLA

#Apa Itu IDOR

IDOR (Insecure Direct Object Reference) terjadi ketika aplikasi memakai identifier langsung (ID) untuk mengambil object tanpa memverifikasi apakah user berhak atas object itu. Contoh paling sederhana:

Endpoint rentan IDOR

GET /api/v1/users/1001/profile
GET /api/v1/users/1002/profile   <- ubah ID saja

Jika akun user A bisa membaca profil user B hanya dengan mengganti angka di URL, itu IDOR. Uji dengan Burp Repeater: buka endpoint sebagai user sendiri, lalu ganti parameter identifier.

#BOLA: Versi Modern

BOLA (Broken Object Level Authorization) adalah nama yang dipakai dalam konteks API (OWASP API Security Top 10). Secara konsep sama dengan IDOR: objek diakses tanpa pengecekan otorisasi di level objek. Di dunia API-first, BOLA konsisten berada di peringkat #1 kerentanan API.

#Enumeration vs IDOR

Kunci membedakannya: IDOR adalah penggantian identifier tanpa pengecekan, bukan sekadar menebak. Kalau parameter memakai UUID yang tidak bisa ditebak tapi akses tetap tanpa cek, tetap IDOR — cukup cek apakah ID lain bisa diakses langsung.

#Privilege Escalation: Horizontal dan Vertikal

Privilege escalation adalah langkah setelah menemukan akses:

Horizontal: user A mengakses resource user B dengan level yang sama (IDOR adalah bentuk horizontal paling umum).
Vertikal: user biasa mengakses fungsi admin — mengubah parameter seperti role=user menjadi role=admin, atau memanggil endpoint admin tanpa cek.

Vertical privilege escalation

GET /api/v1/admin/users      -> 403 (ditutup)
POST /api/v1/user/profile    -> ubah parameter role menjadi "admin"

Uji yang sistematis: daftar semua fungsi yang bisa dipanggil user biasa, lalu cek apakah ada endpoint admin yang bisa diakses langsung (via URL guessing atau dari JS bundle).

#Authentication Flaws

Variasi klasik: query yang bisa di-inject (episode 11), logika if (user) return true yang cacat, atau respons yang membocorkan apakah username valid (username enumeration) — bahan untuk brute force terarah:

Uji brute force dengan hydra

hydra -l admin -P /usr/share/wordlists/rockyou.txt target.com http-post-form \
  "/login:username=^USER^&password=^PASS^:Invalid"

#Session Fixation

Penyerang menentukan session ID korban sebelum login, lalu memaksa korban login dengan ID itu. Setelah login, session ID yang sama digunakan penyerang. Mitigasi: rotasi session ID setelah autentikasi — periksa apakah aplikasi mengganti PHPSESSID/session setelah login.

#Insecure Password Reset

Password reset adalah target empuk:

Reset link yang bisa ditebak (token=12345).
Host header injection: curl -H "Host: attacker.com" .../reset membuat link reset mengarah ke server penyerang.
Token yang ter-broadcast di log/response.

Uji host header injection

curl -X POST http://target.com/api/reset -H "Host: attacker.com" \
  -d "email=victim@example.com"

Jika email korban berisi link http://attacker.com/reset?token=..., penyerang tinggal menunggu token.

#MFA Bypass

MFA bukan tembok — ada beberapa pola bypass:

Enrollment pertama: MFA belum di-wajibkan untuk akun tertentu.
Backup codes yang statis dan bisa ditebak.
Session tidak di-invalidasi: token lama tetap valid setelah MFA ditambahkan.
Merusak login pertama saja: beberapa aplikasi hanya minta MFA sekali per session, tanpa memvalidasi perangkat.

Tip

Saat menguji kontrol akses, buat dua akun user di aplikasi (user A dan user B). Uji akses A ke resource B secara sistematis: profile, order, file, message. Ini metode yang paling banyak menemukan IDOR/BOLA di engagement nyata — dan paling mudah direplikasi saat demo ke client.

#Mitigasi Ringkas

Kerentanan	Mitigasi
IDOR/BOLA	Validasi otorisasi object secara server-side; gunakan identifier acak (UUID) sebagai tambahan
Privilege escalation	RBAC yang tegas; deny by default; jangan percaya parameter client
Login bypass	Parameterized query; rate limiting; pesan error yang netral
Session fixation	Rotasi session ID saat login; cookie `SameSite`
Password reset	Token acak + short-lived; validasi host header
MFA bypass	MFA konsisten; invalidasi session lama; validasi perangkat

Warning

Mengubah parameter seperti role=admin di lab adalah latihan yang bagus, tapi di sistem produksi bisa mengubah data nyata. Selalu gunakan data dummy, dan pastikan setiap uji di lab/platform resmi — bukan aplikasi milik orang lain. Untuk uji password reset/MFA, gunakan email yang kalian kendalikan sendiri.

#Penutup

Pada episode 14 ini, kalian telah menguasai kelas kerentanan peringkat #1 OWASP.

Inti yang harus dibawa pulang:

IDOR/BOLA: akses object dengan mengganti identifier tanpa cek otorisasi.
Horizontal/vertical privesc: level sama vs level lebih tinggi — uji keduanya secara sistematis.
Auth flaws: login bypass, session fixation, insecure password reset, MFA bypass.
Metode dua akun adalah cara paling efektif menemukan broken access control.

Di episode 15 selanjutnya kita membahas JWT attacks & HTTP request smuggling — alg confusion, weak secret brute force, token leakage, dan CL.TE/TE.CL desync attack terhadap backend. Sampai jumpa di episode 15!