Lompat ke konten
dokumentasi.id
Commit 0a16c9d
v2
Star6,9 rb

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:4.

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-14. 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.
Fig. 1: Siklus reset password sampai sesi terbitSatu 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-4, 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-114. Keempat basis itu mudah ditebak, sehingga token yang hanya bergantung padanya dapat direproduksi tanpa membaca secret apa pun.

Parameter pollution dan brute force OTP

VektorNilai yang dikirimIsi catatan
Parameter pollution[email protected]&[email protected]satu nama parameter dikirim dua kali pada POST /reset Checklist/Forgot Password.md:7-14
Brute force OTP[email protected]&code=$123456$kode OTP ditebak berulang pada endpoint yang sama Checklist/Forgot Password.md:16-23

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-108.

⚠️ Brute force kode di halaman ini hanya menyangkut reset password. Varian kode 2FA, termasuk code=null dan 000000, 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-72.

[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-81 dan nilai tanpa TLD Checklist/Forgot Password.md:83-90. Keduanya menguji apakah backend memakai pencocokan longgar saat memilih akun tujuan.

NilaiBentuk yang diujiRujukan
email=victimtanpa domainChecklist/Forgot Password.md:74-81
email=victim@mailtanpa TLDChecklist/Forgot Password.md:83-90

⚠️ Butir terakhir menyisipkan alamat kedua lewat header email: [email protected]%0a%0dcc:[email protected] Checklist/Forgot Password.md:92-99. Teknik ini hanya bekerja bila lapisan pengirim email membangun header dari nilai parameter tanpa sanitasi, sehingga %0a%0d berubah 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-42. 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-121; 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:4. 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.
Fig. 2: Tiga jalur pelemahan verifikasi JWTVerifikasi signature dilewati dengan alg none, dengan menukar RS256 ke HS256, atau dengan menebak secret HS256 lemah; ketiganya berujung pada token palsu.
PerubahanKondisi yang dicatatRujukan
"alg": "none" pada headeralgoritma diubah menjadi noneMisc/JWT Vulnerabilities.md:7-13
RS256 menjadi HS256public key dipakai sebagai secretMisc/JWT Vulnerabilities.md:14-16
Brute force HS256secret HS256 lemah, contohnya pada sampel PyJWTMisc/JWT Vulnerabilities.md:18-20

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-20. Alat yang dirujuk adalah jwt-hack Misc/JWT Vulnerabilities.md:22-23.

Kredensial bawaan dan kunci yang bocor

Kredensial bawaan adalah kredensial administratif yang dipasang pabrik untuk mengakses seluruh pengaturan konfigurasi Misc/Default Credentials.md:4. 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-9.

Kunci yang bocor dicari di dua tempat: kode JavaScript pada situs dan header request atau response Misc/Exposed API keys.md:6-8. Temuan itu berbahaya karena dapat menimbulkan kerugian finansial bagi pemilik program Misc/Exposed API keys.md:4.

SumberObjek yang dicariRujukan
CMS atau software yang teridentifikasikredensial admin pre-setMisc/Default Credentials.md:7-9
DefaultCreds-cheat-sheet (@ihebski)daftar kredensial bawaanMisc/Default Credentials.md:11-13
many-passwords (@many-passwords)daftar kredensial bawaanMisc/Default Credentials.md:11-13
Kode JavaScript situsAPI key dan tokenMisc/Exposed API keys.md:6-8
Header request dan responseAPI key dan tokenMisc/Exposed API keys.md:6-8
Key-Checkervalidasi key hasil temuanMisc/Exposed API keys.md:10-11

Setelah key ditemukan, validitasnya diperiksa dengan keyhacks yang memuat 79 cara pemeriksaan Misc/Exposed API keys.md:13-15, 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-15.

⚠️ 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:4. 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-10.

https://example/signin?response_type=code&redirect_uri=https://callback_url/auth&client_id=FQ9RGtMkztAgmAApKOqACrBNq&state=7tvPJiv8StrAqo9IQE9xsJaDso4&scope=+profile+email+phone+group+role+resource
TeknikNilai atau kondisi yang dicatatRujukan
IDN homograph pada redirect_uri&redirect_uri=https://еxamplе.com, memakai huruf non-ASCIIOAuth Misconfiguration.md:12-22
Open redirect pada redirect_uri&redirect_uri=https://evil.com dan &redirect_uri=https://example.com.evil.comOAuth Misconfiguration.md:33-43
state tidak ditanganitautan authorize dikirim ke korban yang sudah login, menjadi CSRFOAuth Misconfiguration.md:25-31
Tidak ada pemeriksaan originklaim tanpa payload khususOAuth Misconfiguration.md:32
OAuth token re-usetoken yang sama dipakai ulangOAuth Misconfiguration.md:24
email setelah signinnilai diubah menjadi email korbanOAuth Misconfiguration.md:44-45
email dihapus dari scopeemail korban ditambahkan manualOAuth Misconfiguration.md:44-45
client_secret bocorsecret terlihat pada alur atau responseOAuth Misconfiguration.md:46

⚠️ Redirect ke https://example.com.evil.com lolos dari pemeriksaan naif yang hanya mencari string example.com di 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.

ButirIsiHalaman terkait
Pre-account takeover lewat OAuthpenyerang 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-11halaman ini
Re-sign up dengan email yang samapendaftaran ulang memakai email korban dan password berbeda: [email protected]&password=hacked Misc/Account Takeover.md:13-24halaman ini
Penggantian email lewat CSRFform POST https://evil.com/user/change-email dengan nilai email korban Misc/Account Takeover.md:26-40Kerentanan Sisi Klien dan Pengalihan URL
Chaining dengan IDOR pada changepassword.phpuserid=500 milik penyerang diganti menjadi ID korban Misc/Account Takeover.md:42-49Kontrol Akses dan Request Server Side
Tidak ada rate limit pada 2FAkode 2FA dapat ditebak berulang Misc/Account Takeover.md:51Teknik 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-11. 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.