Audit login, session, dan access control: bagian pentest yang tidak boleh cuma dicek dari UI

Login adalah pintu masuk. Tapi kebocoran aplikasi sering terjadi setelah user berhasil login.

Masalahnya bukan selalu "orang luar bisa masuk tanpa password". Sering kali yang terjadi lebih halus: user biasa bisa melihat invoice user lain, staff bisa menjalankan aksi admin, token tidak pernah expired, reset password bisa disalahgunakan, atau session tetap hidup setelah password diganti.

Karena itu audit login, session, dan access control harus diperlakukan sebagai satu paket. Authentication membuktikan siapa user-nya. Session menjaga status login. Authorization menentukan apa yang boleh dilakukan user itu.

Artikel ini bagian dari seri audit keamanan aplikasi. Untuk peta besar, baca audit keamanan aplikasi dengan standard pentest. Untuk API, baca pentest API aplikasi modern. Untuk celah proses bisnis, baca business logic vulnerability.

Rujukan standard yang paling relevan untuk topik ini adalah OWASP ASVS untuk requirement authentication, session, dan authorization; OWASP WSTG untuk skenario pengujian web; dan OWASP API Security Top 10 2023 untuk isu object authorization di API.

Authentication: cek seluruh flow, bukan hanya form login

Form login hanya satu bagian kecil dari authentication.

Audit harus mencakup:

• registration;
• login;
• logout;
• forgot password;
• reset password;
• change password;
• MFA enrollment;
• MFA reset;
• SSO/OAuth;
• invite user;
• account linking;
• device/session management.

Jika salah satu flow ini lemah, penyerang bisa melewati login utama.

Account enumeration

Account enumeration terjadi ketika aplikasi memberi sinyal apakah email/username terdaftar.

Contoh:

• login menampilkan "email tidak ditemukan" vs "password salah";
• forgot password menampilkan "akun tidak tersedia";
• registration menampilkan "email sudah digunakan";
• API response punya timing berbeda untuk akun valid dan tidak valid.

Tidak semua enumeration otomatis critical. Tapi untuk aplikasi dengan data sensitif, enumeration membantu brute force, phishing, credential stuffing, dan social engineering.

Respons yang lebih sehat: gunakan pesan generik untuk flow publik. Di belakang layar, tetap log event dengan detail yang cukup untuk monitoring.

Brute force dan credential stuffing

Rate limit login tidak boleh hanya per IP.

Credential stuffing sering memakai banyak IP. Audit perlu mengecek limit per akun, per IP, per device fingerprint jika ada, dan per ASN/region jika risk engine tersedia.

Kontrol yang layak:

• progressive delay;
• temporary lock untuk akun tertentu;
• CAPTCHA setelah risiko naik, bukan dari awal;
• alert login gagal berulang;
• deteksi password spraying;
• MFA step-up untuk login mencurigakan.

Jangan membuat lockout yang mudah dipakai untuk DoS akun orang. Balance-nya perlu dipikirkan.

Reset password

Reset password adalah salah satu flow paling penting dalam pentest authentication.

Yang harus diuji:

• token cukup random;
• token punya expiry pendek;
• token single-use;
• token tidak bisa dipakai untuk akun lain;
• token tidak bocor di log, referer, analytics, atau email tracking;
• password lama tidak tetap valid jika policy meminta revoke;
• semua session lama dicabut setelah reset;
• response tidak membocorkan apakah email terdaftar.

Reset password yang buruk bisa membuat password kuat dan MFA jadi tidak relevan.

MFA bukan pajangan

MFA membantu, tapi implementasinya sering punya celah.

Audit perlu mengecek:

• enrollment MFA memerlukan re-authentication;
• reset MFA tidak bisa dilakukan hanya lewat email yang sudah kompromi;
• backup code cukup random dan single-use;
• recovery flow punya kontrol tambahan;
• MFA tidak bisa di-skip lewat endpoint lama;
• remember device punya expiry dan binding yang jelas;
• aksi sensitif memicu step-up authentication.

Untuk admin, finance, owner, dan role yang bisa export data, MFA sebaiknya dianggap baseline.

OAuth dan SSO

OAuth/SSO sering terlihat aman karena memakai provider besar. Tapi bug biasanya ada di integrasi aplikasi.

Cek:

• redirect URI exact match;
• state parameter;
• nonce untuk OpenID Connect;
• issuer dan audience token;
• email verified;
• account linking;
• domain restriction untuk akun perusahaan;
• session creation setelah callback;
• logout behavior.

Jangan menganggap email yang sama dari provider berbeda otomatis orang yang sama tanpa aturan account linking yang jelas.

Session management

Session adalah bukti bahwa user sudah login. Kalau lifecycle-nya buruk, risiko auth tetap tinggi.

Audit harus mengecek:

• cookie HttpOnly;
• cookie Secure;
• SameSite;
• session expiry;
• idle timeout;
• absolute timeout;
• session rotation setelah login;
• session rotation setelah privilege naik;
• logout mencabut session server-side;
• daftar device/session aktif;
• revoke session dari dashboard.

Session fixation perlu diuji. Setelah user login, session ID harus diganti. Kalau tidak, session yang sudah diketahui penyerang bisa menjadi session valid.

JWT dan refresh token

JWT sering dipakai karena praktis. Masalahnya, banyak tim memperlakukannya seperti session biasa tanpa mekanisme revoke.

Audit JWT harus mengecek:

• expiry pendek untuk access token;
• refresh token rotation;
• revoke refresh token saat logout;
• revoke saat password berubah;
• revoke saat MFA reset;
• issuer dan audience;
• signature validation;
• algorithm tidak bisa diubah;
• key rotation;
• token tidak disimpan sembarangan.

JWT yang berlaku terlalu lama dan tidak bisa dicabut adalah liability. Apalagi jika disimpan di localStorage dan aplikasi punya risiko XSS.

CSRF masih relevan

CSRF tidak hilang hanya karena aplikasi memakai frontend modern.

Jika auth berbasis cookie dan endpoint melakukan aksi state-changing, CSRF harus diuji. Contohnya update email, change password, create order, transfer credit, update bank account, atau invite user.

Kontrol bisa berupa SameSite cookie, CSRF token, origin check, dan re-authentication untuk aksi sensitif.

Authorization: jangan berhenti di role

Authorization bukan cuma "admin atau bukan".

Aplikasi nyata punya banyak dimensi:

• user role;
• organization;
• tenant;
• owner object;
• status object;
• approval stage;
• package/subscription;
• feature flag;
• data classification;
• relationship antar user.

Contoh: user mungkin admin di organization A, tapi bukan admin di organization B. Staff mungkin bisa membaca invoice, tapi tidak bisa refund. Customer mungkin bisa melihat order miliknya, tapi tidak bisa mengubah harga.

Audit harus memetakan permission matrix, lalu menguji matrix itu langsung ke endpoint.

IDOR dan BOLA

IDOR atau BOLA adalah bug authorization yang sangat umum.

Pola uji:

1. Buat akun A dan akun B.
2. Buat object di akun A.
3. Login sebagai akun B.
4. Panggil endpoint object akun A.
5. Cek apakah API menolak.

Lakukan untuk read, update, delete, export, attachment, comment, dan nested resource.

Jangan hanya uji ID numeric. UUID, slug, token public, dan file path juga perlu diuji.

Pembahasan API yang lebih detail ada di pentest API aplikasi modern.

Multi-tenant isolation

Untuk SaaS, multi-tenant isolation adalah area critical.

Audit harus mengecek:

• query selalu memfilter tenant;
• object ID tidak cukup tanpa tenant check;
• invite user tidak bisa lintas tenant sembarangan;
• export data hanya berisi tenant sendiri;
• search tidak bocor ke tenant lain;
• background job tidak mencampur data;
• cache key memasukkan tenant;
• analytics/reporting tidak bocor lintas client.

Bug tenant isolation sering tidak terlihat di UI. Ujinya harus langsung ke API dan database behavior.

Object property authorization

User boleh melihat object bukan berarti boleh melihat semua field.

Contoh field sensitif:

• internal note;
• margin;
• payment raw response;
• fraud score;
• admin comment;
• token;
• secret key;
• owner-only metadata;
• deleted_at;
• role;
• tenant_id.

Audit response dan request. Response tidak boleh mengirim field sensitif. Request tidak boleh menerima field yang tidak boleh diubah user.

Mass assignment biasanya muncul di sini.

Approval dan status transition

Access control juga berlaku pada workflow.

Contoh yang perlu diuji:

• user bisa approve request miliknya sendiri;
• status bisa lompat dari draft ke approved;
• refund bisa dipanggil tanpa supervisor;
• order cancelled bisa diaktifkan lagi;
• subscription expired bisa dibuat active;
• invoice unpaid bisa diubah paid dari client;
• role viewer bisa mengirim approval.

Ini mulai masuk business logic. Untuk contoh yang lebih luas, baca business logic vulnerability.

Logging untuk auth dan access control

Event auth harus tercatat, tapi jangan bocorkan secret.

Log yang penting:

• login berhasil/gagal;
• reset password request;
• reset password berhasil;
• MFA enrollment/reset;
• session revoked;
• role changed;
• access denied;
• permission changed;
• admin action;
• export data.

Log tidak boleh menyimpan password, OTP, reset token, refresh token, atau cookie.

Access denied yang berulang dari user/token yang sama bisa menjadi sinyal eksplorasi endpoint.

Risk rating

Untuk area ini, severity biasanya tinggi jika temuan menyentuh:

• account takeover;
• bypass MFA;
• akses data user lain;
• akses data tenant lain;
• akses endpoint admin;
• ability mengubah role;
• session/token yang tidak bisa dicabut;
• reset password takeover.

Temuan seperti cookie flag kurang bisa menjadi medium atau low, tapi naik jika dikombinasikan dengan XSS atau token storage yang buruk.

Cara membaca prioritas ini saya bahas di cara membaca laporan pentest aplikasi.

Kesimpulan

Login yang berhasil bukan bukti aplikasi aman. Yang perlu diuji adalah seluruh lifecycle identitas: daftar, login, reset, MFA, session, token, role, object, tenant, dan workflow.

Kalau authorization hanya ada di UI, aplikasi belum aman. Kalau token tidak bisa dicabut, incident akan lebih mahal. Kalau reset password lemah, password policy hanya jadi formalitas.

Audit auth dan access control yang benar harus memakai beberapa akun, beberapa role, beberapa tenant, dan request langsung ke API. Di situlah banyak celah yang tidak terlihat oleh QA biasa.