9
Otentikasi, Sesi, dan Token
Halaman ini menyatukan catatan repository tentang otentikasi: siklus reset password, penerbitan dan verifikasi token, kredensial yang dipakai ulang, serta salah konfigurasi OAuth. Enam berkas menjadi sumbernya. Misc/Account Takeover.md menutup rantainya dengan definisi Account Takeover sebagai pencurian identitas ketika pihak lain memperoleh akses tidak sah ke akun orang lain Misc/Account Takeover.md:41.
Siklus reset password dan penerbitan token
Semua contoh reset password memakai verb dan path yang sama, POST /reset dengan Host: target.com dan satu parameter email Checklist/Forgot Password.md:7-142. Perbedaan antar teknik terletak pada bentuk nilai email, bukan pada verb atau path. Diagram berikut merangkai perjalanan satu request dari pengiriman email sampai sesi baru terbit.
stateDiagram-v2
[*] --> ResetRequested
ResetRequested --> ResetRequested: duplicate email parameter
ResetRequested --> ResetRequested: separator inside the email value
ResetRequested --> LinkSent: server resolves the victim account
ResetRequested --> PoisonedLink: X-Forwarded-Host set to evil.com
LinkSent --> LinkSent: OTP brute force without rate limit
LinkSent --> PasswordChanged: code or reset token accepted
PoisonedLink --> PasswordChanged: victim opens the attacker link
PasswordChanged --> TokenIssued
TokenIssued --> SessionIssued: timestamp / user ID / email / name based
SessionIssued --> [*]
style ResetRequested fill:#f59e0b,color:#000
style LinkSent fill:#2d7d46,color:#fff
style PoisonedLink fill:#dc2626,color:#fff
style TokenIssued fill:#8b5cf6,color:#fff
style SessionIssued fill:#336791,color:#fff
%% fig: Siklus reset password sampai sesi terbit
%% desc: Satu request ke POST /reset berujung pada tautan reset, tebakan OTP, atau tautan yang teracuni header, lalu memicu penerbitan token dan sesi baru.Checklist membuka berkasnya sebagai kumpulan bug umum pada fungsi forgot password Checklist/Forgot Password.md:3-43, lalu menaruh parameter pollution dan brute force OTP sebagai dua butir pertama. Basis pembentukan token juga dicatat terpisah: token dapat diturunkan dari TimeStamp, dari ID user, dari email user, atau dari nama user Checklist/Forgot Password.md:110-1144. Keempat basis itu mudah ditebak, sehingga token yang hanya bergantung padanya dapat direproduksi tanpa membaca secret apa pun.
Parameter pollution dan brute force OTP
| Vektor | Nilai yang dikirim | Isi catatan |
|---|---|---|
| Parameter pollution | [email protected]&[email protected] | satu nama parameter dikirim dua kali pada POST /reset Checklist/Forgot Password.md:7-142 |
| Brute force OTP | [email protected]&code=$123456$ | kode OTP ditebak berulang pada endpoint yang sama Checklist/Forgot Password.md:16-235 |
Varian yang sama juga dicoba pada body JSON, kali ini pada POST /newaccount, dengan menambah elemen kedua tanpa kunci: {"email":"[email protected]","[email protected]","token":"xxxxxxxxxx"} Checklist/Forgot Password.md:101-1086.
⚠️ Brute force kode di halaman ini hanya menyangkut reset password. Varian kode 2FA, termasuk
code=nulldan000000, dibahas di Teknik Bypass Kontrol, dan pencurian sesi lewat parameter terduplikasi pada request lain dibahas di Injeksi Query dan Header.
Separator dan email tidak lengkap
Selain menduplikasi parameter, checklist menyelipkan alamat kedua ke dalam satu nilai. Empat separator dicoba, semuanya pada POST /reset dengan Host: target.com Checklist/Forgot Password.md:44-727.
[email protected],[email protected]
[email protected]%[email protected]
[email protected]|[email protected]
[email protected]%[email protected]
Dua butir berikut menguji validasi bentuk email, bukan pemisah: nilai tanpa domain Checklist/Forgot Password.md:74-818 dan nilai tanpa TLD Checklist/Forgot Password.md:83-909. Keduanya menguji apakah backend memakai pencocokan longgar saat memilih akun tujuan.
| Nilai | Bentuk yang diuji | Rujukan |
|---|---|---|
email=victim | tanpa domain | Checklist/Forgot Password.md:74-818 |
email=victim@mail | tanpa TLD | Checklist/Forgot Password.md:83-909 |
⚠️ Butir terakhir menyisipkan alamat kedua lewat header email:
[email protected]%0a%0dcc:[email protected]Checklist/Forgot Password.md:92-9910. Teknik ini hanya bekerja bila lapisan pengirim email membangun header dari nilai parameter tanpa sanitasi, sehingga%0a%0dberubah menjadi baris baru.
Checklist juga mengganti Host menjadi X-Forwarded-Host: evil.com agar tautan reset yang diterima korban menunjuk domain penyerang Checklist/Forgot Password.md:25-4211. Keluarga payload header tersebut dibahas di Injeksi Query dan Header. Butir terakhir memakai payload XSS pada nilai email karena alamat itu kadang direfleksikan di halaman forgot password Checklist/Forgot Password.md:116-12112; mekanismenya ada di Kerentanan Sisi Klien dan Pengalihan URL.
Verifikasi token dan kelemahan algoritma
JWT didefinisikan sebagai standar terbuka RFC 7519 untuk mengirimkan informasi antar pihak sebagai objek JSON Misc/JWT Vulnerabilities.md:413. Catatan JWT menyerang sisi verifikasi, bukan sisi penerbitan, dan menyisakan tiga jalur.
graph LR
Token[JWT dari client] --> Verify{Verifikasi signature}
Verify -->|alg none| Skip[signature tidak diperiksa]
Verify -->|RS256 diganti HS256| PubKey[public key dipakai sebagai secret]
Verify -->|HS256 secret lemah| Brute[brute force secret]
Skip --> Forged[token palsu diterima backend]
PubKey --> Forged
Brute --> Forged
style Token fill:#8b5cf6,color:#fff
style Verify fill:#f59e0b,color:#000
style Forged fill:#dc2626,color:#fff
%% fig: Tiga jalur pelemahan verifikasi JWT
%% desc: Verifikasi signature dilewati dengan alg none, dengan menukar RS256 ke HS256, atau dengan menebak secret HS256 lemah; ketiganya berujung pada token palsu.| Perubahan | Kondisi yang dicatat | Rujukan |
|---|---|---|
"alg": "none" pada header | algoritma diubah menjadi none | Misc/JWT Vulnerabilities.md:7-1314 |
| RS256 menjadi HS256 | public key dipakai sebagai secret | Misc/JWT Vulnerabilities.md:14-1615 |
| Brute force HS256 | secret HS256 lemah, contohnya pada sampel PyJWT | Misc/JWT Vulnerabilities.md:18-2016 |
If you change the algorithm from RS256 to HS256, the backend code uses the public key as the secret key and then uses the HS256 algorithm to verify the signature.
Untuk jalur ketiga, catatan menyebut kekuatan kunci HS256 yang lemah sehingga dapat di-brute force langsung, termasuk memakai string secret seperti pada contoh kode pustaka PyJWT Misc/JWT Vulnerabilities.md:18-2016. Alat yang dirujuk adalah jwt-hack Misc/JWT Vulnerabilities.md:22-2317.
Kredensial bawaan dan kunci yang bocor
Kredensial bawaan adalah kredensial administratif yang dipasang pabrik untuk mengakses seluruh pengaturan konfigurasi Misc/Default Credentials.md:418. Pencariannya bertahap: kenali CMS atau software yang dipakai (contohnya grafana), temukan halaman login admin, lalu cocokkan dengan daftar kredensial dari repositori rujukan Misc/Default Credentials.md:7-919.
Kunci yang bocor dicari di dua tempat: kode JavaScript pada situs dan header request atau response Misc/Exposed API keys.md:6-820. Temuan itu berbahaya karena dapat menimbulkan kerugian finansial bagi pemilik program Misc/Exposed API keys.md:421.
| Sumber | Objek yang dicari | Rujukan |
|---|---|---|
| CMS atau software yang teridentifikasi | kredensial admin pre-set | Misc/Default Credentials.md:7-919 |
DefaultCreds-cheat-sheet (@ihebski) | daftar kredensial bawaan | Misc/Default Credentials.md:11-1322 |
many-passwords (@many-passwords) | daftar kredensial bawaan | Misc/Default Credentials.md:11-1322 |
| Kode JavaScript situs | API key dan token | Misc/Exposed API keys.md:6-820 |
| Header request dan response | API key dan token | Misc/Exposed API keys.md:6-820 |
Key-Checker | validasi key hasil temuan | Misc/Exposed API keys.md:10-1123 |
Setelah key ditemukan, validitasnya diperiksa dengan keyhacks yang memuat 79 cara pemeriksaan Misc/Exposed API keys.md:13-1524, dan detail tiap key atau token OAuth dilihat di all-about-apikey yang memuat deskripsi, HTTP request, response valid atau tidak, regex, serta contoh Misc/Exposed API keys.md:13-1524.
⚠️ Kredensial bawaan yang belum diganti dan API key yang tertinggal di bundle JavaScript tidak menimbulkan error apa pun. Keduanya hanya terlihat lewat pencocokan daftar dan pembacaan kode, jadi tidak ada sinyal dari sisi server.
Salah konfigurasi OAuth dan redirect_uri
Bentuk paling terkenal dari celah OAuth adalah konfigurasi layanan yang memungkinkan penyerang mencuri authorization code atau access token milik akun lain, sehingga akun korban dapat diakses OAuth Misconfiguration.md:425. Titik periksaannya adalah fitur SSO, yang URL signin-nya membawa response_type=code, redirect_uri, client_id, state, dan scope dalam satu query string OAuth Misconfiguration.md:6-1026.
https://example/signin?response_type=code&redirect_uri=https://callback_url/auth&client_id=FQ9RGtMkztAgmAApKOqACrBNq&state=7tvPJiv8StrAqo9IQE9xsJaDso4&scope=+profile+email+phone+group+role+resource
| Teknik | Nilai atau kondisi yang dicatat | Rujukan |
|---|---|---|
IDN homograph pada redirect_uri | &redirect_uri=https://еxamplе.com, memakai huruf non-ASCII | OAuth Misconfiguration.md:12-2227 |
Open redirect pada redirect_uri | &redirect_uri=https://evil.com dan &redirect_uri=https://example.com.evil.com | OAuth Misconfiguration.md:33-4328 |
state tidak ditangani | tautan authorize dikirim ke korban yang sudah login, menjadi CSRF | OAuth Misconfiguration.md:25-3129 |
| Tidak ada pemeriksaan origin | klaim tanpa payload khusus | OAuth Misconfiguration.md:3230 |
| OAuth token re-use | token yang sama dipakai ulang | OAuth Misconfiguration.md:2431 |
email setelah signin | nilai diubah menjadi email korban | OAuth Misconfiguration.md:44-4532 |
email dihapus dari scope | email korban ditambahkan manual | OAuth Misconfiguration.md:44-4532 |
client_secret bocor | secret terlihat pada alur atau response | OAuth Misconfiguration.md:4633 |
⚠️ Redirect ke
https://example.com.evil.comlolos dari pemeriksaan naif yang hanya mencari stringexample.comdi dalam URL. Periksa pencocokan host secara utuh, bukan pencarian substring.
Rantai menuju account takeover
Berkas ATO mengurutkan lima jalur, dan halaman ini hanya memuat bagian yang menyentuh otentikasi; sisanya dibahas di halaman lain.
| Butir | Isi | Halaman terkait |
|---|---|---|
| Pre-account takeover lewat OAuth | penyerang mendaftar dengan OAuth memakai email korban, lalu mengganti email akunnya menjadi email korban sehingga pendaftaran korban ditolak karena email sudah ada Misc/Account Takeover.md:7-1134 | halaman ini |
| Re-sign up dengan email yang sama | pendaftaran ulang memakai email korban dan password berbeda: [email protected]&password=hacked Misc/Account Takeover.md:13-2435 | halaman ini |
| Penggantian email lewat CSRF | form POST https://evil.com/user/change-email dengan nilai email korban Misc/Account Takeover.md:26-4036 | Kerentanan Sisi Klien dan Pengalihan URL |
Chaining dengan IDOR pada changepassword.php | userid=500 milik penyerang diganti menjadi ID korban Misc/Account Takeover.md:42-4937 | Kontrol Akses dan Request Server Side |
| Tidak ada rate limit pada 2FA | kode 2FA dapat ditebak berulang Misc/Account Takeover.md:5138 | Teknik Bypass Kontrol |
Dua jalur pertama bertumpu pada satu asumsi yang sama: identitas ditentukan oleh alamat email, dan alur pendaftaran tidak memverifikasi kepemilikan alamat itu. Jalur OAuth bahkan tidak memerlukan perubahan kode di sisi target, hanya konfigurasi redirect_uri dan pemetaan email yang longgar Misc/Account Takeover.md:7-1134. Karena itu, saat menguji fitur otentikasi, urutkan pemeriksaan dari alur yang paling murah: reset password, lalu penerbitan token, lalu SSO, dan terakhir daftar kredensial bawaan.