Materi
Insecure Direct Object Reference (IDOR) terjadi bila pengguna bisa membaca atau mengubah objek orang lain hanya dengan mengganti pengenalnya, misalnya nomor faktur di URL, karena server tidak memeriksa apakah objek itu boleh diaksesnya. OWASP menyebut tiga unsurnya: objek, rujukan ke objek itu, dan pemeriksaan otorisasi per objek yang hilang. Pengenal acak seperti UUID mempersulit tebakan, tetapi tidak menggantikan pemeriksaan: pengenal bisa bocor lewat tautan atau log.
Penangkalnya ditulis di query: cari objek di antara objek yang memang boleh diakses pengguna, misalnya WHERE id = ? AND pemilik_id = ? dengan pemilik dari sesi. Objek milik orang lain dan objek yang tidak ada memberi hasil sama, yaitu tidak ditemukan. Cheat sheet Authorization OWASP menambahkan dua prinsip: tolak secara bawaan (deny by default), sehingga aksi atau peran yang tidak tercantum ditolak, dan periksa izin di setiap permintaan.
IZIN = {"siswa": {"lihat-nilai"}, "guru": {"lihat-nilai", "ubah-nilai"}}
def boleh_akses(peran, aksi):
return aksi in IZIN.get(peran, set()) # peran/aksi tak dikenal → False
def ambil_rapor(conn, sesi, rapor_id):
return conn.execute("SELECT * FROM rapor WHERE id = ? AND siswa_id = ?",
(rapor_id, sesi["user_id"])).fetchone()
Pengujian akses mengikuti pola yang sama. OWASP menyarankan matriks otorisasi, yaitu tabel peran × fungsi berisi boleh atau tidak, yang dijalankan sebagai test pada setiap rilis. Untuk objek, buat data milik dua akun, masuk sebagai akun A, coba baca dan ubah objek milik B, dan pastikan semuanya ditolak.
