Private Key Ada di Browser,
tetapi Bukan Berarti Auth Bypass.

Dalam sebuah aplikasi web, browser mengambil material RSA berformat private key dari fungsi server. JavaScript kemudian memiliki kode untuk menandatangani body permintaan. Secara visual, sinyal ini kuat: private key biasanya tidak boleh meninggalkan server.

Tetapi nama artefak bukan bukti kewenangan. Pertanyaan yang menentukan bukan “apakah ini private key?”, melainkan “keputusan keamanan apa yang mempercayai signature tersebut, dan kemampuan baru apa yang muncul setelah signature dibuat?”

Sinyal awal dan klaim paling sempit

Analisis JavaScript menunjukkan tiga komponen: fungsi yang mengambil key, fungsi RSA-SHA512 untuk menandatangani request, dan dua header yang membawa hasil signature serta pengenal key. Reproduksi lokal berhasil membuat signature dengan format yang sama.

Hipotesis: aktor anonim dapat menggunakan key yang dikirim ke browser untuk melewati kontrol request-integrity dan memperoleh operasi sensitif yang ditolak tanpa signature.

Falsifier-nya juga harus jelas: bila unsigned baseline dan request bertanda tangan mendapat keputusan sensitif yang sama, atau bila signature tidak terhubung ke authorization, hipotesis bypass gugur.

Authority model yang sebenarnya

Model ini mencegah dua hal dicampuradukkan. Signature request dapat membantu membedakan client resmi dari bot, tetapi belum tentu membuktikan siapa penggunanya. Authentication biasanya tetap bergantung pada session atau token identitas yang diverifikasi secara terpisah.

Eksperimen yang dilakukan

1. Reproduksi kriptografi

Key berhasil diparse sebagai RSA private key. Signature terhadap body terkontrol dapat dibuat secara lokal menggunakan algoritma yang sama dengan client. Tahap ini membuktikan kemampuan kriptografi, bukan dampak keamanan.

2. Audit feature flag

Bundle produksi memuat jalur signing, tetapi konfigurasi runtime menunjukkan feature flag terkait berada dalam keadaan nonaktif. Artinya, kode yang dikirim ke browser belum tentu merupakan kontrol yang sedang dipakai pada jalur produksi.

3. Unsigned baseline

Permintaan tanpa signature dikirim ke operasi pembanding. Hasilnya dicatat sebagai unsigned baseline agar request bertanda tangan tidak dinilai sendirian.

4. Mutasi satu variabel

Body, identitas, dan konteks dipertahankan. Satu-satunya perubahan adalah signature valid yang dibuat dengan key tersebut. Pada jalur terlindungi, signature yang benar tidak mengubah keputusan penolakan.

5. Negative control

Signature salah dan request tanpa signature dibandingkan pada jalur publik. Keduanya memperoleh kemampuan publik yang sama. Ini konsisten dengan server yang tidak memakai header tersebut sebagai boundary otorisasi.

6. Pengujian boundary identitas

Claim identitas yang tidak memiliki bukti kriptografi sah tetap ditolak atau diperlakukan sebagai sesi tamu. Dengan kata lain, identitas tetap ditolak meskipun request dapat diberi signature menggunakan key dari client.

Mengapa private key tetap menjadi sinyal kuat?

Konvensi keamanan mengajarkan bahwa private key harus dirahasiakan. Itu benar ketika key mewakili identitas atau kewenangan eksklusif. Namun aplikasi client-side tidak dapat menyimpan secret yang benar-benar rahasia dari pengguna yang menjalankan client tersebut.

Jika seluruh browser menerima key yang sama, server tidak boleh memperlakukannya sebagai bukti identitas pengguna. Paling jauh, desain itu mungkin dimaksudkan sebagai friksi anti-automation, obfuscation, kompatibilitas dengan gateway, atau fitur eksperimen yang belum aktif.

Penjelasan benign yang bertahan

Kode tersedia, kontrol produksi nonaktif

Modern web bundle sering membawa jalur eksperimen yang diaktifkan melalui konfigurasi. Keberadaan fungsi tidak membuktikan real call-site sedang digunakan.

Request signing bukan authentication

Server dapat memproses signature sebagai sinyal client atau bot-management, lalu tetap meminta token identitas yang valid untuk operasi pengguna.

Endpoint publik memang mengizinkan guest bootstrap

HTTP 200 pada operasi bootstrap tamu tidak membuktikan bypass. Pembanding yang benar adalah apakah akun, data privat, atau mutasi terlindungi menjadi tersedia.

Apa yang diperlukan agar berubah menjadi finding?

• Unsigned request ditolak oleh aplikasi, bukan sekadar WAF atau noise jaringan.
• Request identik dengan signature valid diterima.
• Acceptance memberikan kemampuan sensitif baru, bukan hanya respons 200.
• State atau data otoritatif membuktikan boundary crossing.
• Efek dapat direproduksi dari sesi bersih dengan negative control.

Tanpa rangkaian tersebut, label “private-key exposure” terlalu luas dan mudah menyiratkan account takeover yang tidak terbukti.

Pelajaran untuk developer

• Jangan kirim secret yang menjadi dasar authentication atau authorization ke client.
• Anggap seluruh material dalam browser dapat diekstrak dan direproduksi.
• Pisahkan request-integrity, anti-automation, authentication, dan authorization dalam threat model.
• Hapus jalur kriptografi client-side yang tidak aktif agar tidak menciptakan kompleksitas dan salah persepsi.
• Jika signing memang diperlukan, gunakan key per sesi dengan tujuan terbatas dan tetap lakukan authorization penuh di server.
• Regression test harus membandingkan unsigned, invalid-signature, valid-signature, dan identity-token invalid.

Keputusan akhir

Kesimpulan

Artefak yang tampak berbahaya harus menaikkan prioritas investigasi, bukan langsung menaikkan severity. Dalam kasus ini, reproduksi signature berhasil, tetapi tidak ada kemampuan sensitif, akses akun, atau perubahan state yang muncul.

Nilai eksperimennya adalah pemetaan trust boundary: kriptografi di client ternyata bukan sumber kebenaran identitas. Server tetap memerlukan bukti autentikasi yang terpisah, dan bukti runtime membantah klaim bypass.