Kerentanan JWT: alg=none & Kekacauan Kunci

JWT ditandatangani secara kriptografis, tetapi banyak pustaka memiliki kerentanan serius. Yang paling sering dieksploitasi adalah serangan alg=none, serangan kebingungan RS256→HS256, dan pembobolan rahasia yang lemah secara brute force. Semua ini berawal dari mempercayai bidang header yang dikendalikan penyerang.

Spesifikasi JWT mengizinkan alg:"none" untuk token tanpa pengamanan. Pustaka yang bermasalah menerima nilai ini dan sepenuhnya melewati verifikasi tanda tangan. Penyerang mengubah muatan (misalnya, "role":"admin"), menetapkan alg:"none", menghapus tanda tangan, lalu server menerimanya.

Asli: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyIn0.SIG Serangan: eyJhbGciOiJub25lIn0.eyJzdWIiOiJhZG1pbiJ9. (tanda tangan kosong, diakhiri titik). Server yang rentan berhasil memverifikasinya dan memberikan akses administrator.

Jangan pernah menerima alg:"none" dalam produksi. Tetapkan daftar putih algoritme yang diizinkan secara eksplisit: jwt.decode(token, key, algorithms=["HS256"]). Sebagian besar pustaka modern (PyJWT 2+, jsonwebtoken 9+) menolak alg=none secara bawaan.

Jika server menggunakan RS256 dan klien mengubah alg menjadi HS256, server mungkin memverifikasi menggunakan kunci publik RSA-nya sebagai rahasia HMAC. Karena kunci publik itu... publik, penyerang menandatangani muatan sembarang dengannya dan server memverifikasinya.

Langkah-langkah: 1) Ambil kunci publik dari titik akhir JWKS. 2) Buat muatan berbahaya. 3) Tandatangani dengan HMAC-SHA256 menggunakan byte PEM kunci publik mentah sebagai rahasia HMAC. 4) Tetapkan alg:"HS256" pada header. 5) Jalur HS256 server berhasil memverifikasinya.

Selalu tentukan algoritme yang diharapkan secara eksplisit dalam panggilan verifikasi. Jangan pernah menentukan algoritme berdasarkan header token. Gunakan jalur kode terpisah untuk RS256 dan HS256 yang tidak dapat ditukar oleh pemanggil.

HS256 dengan rahasia lemah (entropi kurang dari 256 bit) dapat dibobol secara luring menggunakan brute force. Alat seperti hashcat mendukung pembobolan JWT: hashcat -a 0 -m 16500 token.txt wordlist.txt. Gunakan rahasia acak secara kriptografis dengan panjang minimal 32 byte.

Header kid (ID kunci) memilih kunci yang akan digunakan. Jika server menggunakan kid sebagai parameter kueri SQL atau jalur sistem berkas tanpa sanitasi: kid="../../dev/null" → HMAC dengan kunci kosong → token palsu diterima. Selalu lakukan sanitasi terhadap kid.

Header jwk menyertakan kunci publik untuk verifikasi. Server yang rentan mungkin menggunakan kunci yang disertakan tersebut secara langsung, sehingga penyerang dapat memasok pasangan kuncinya sendiri, menandatangani token dengan kunci privat, dan menyertakan kunci publiknya. Lakukan verifikasi hanya terhadap kunci yang terdaftar.

Beberapa implementasi lupa memeriksa klaim exp atau menggunakan waktu server secara tidak konsisten. Selalu validasi exp, nbf, dan iat secara eksplisit. Gunakan pustaka yang memeriksa semua ini secara bawaan dan jangan pernah menonaktifkan validasi klaim dalam produksi.

Kerentanan JWT muncul karena mempercayai header alg, menerima alg=none, dan menggunakan rahasia yang lemah. Perbaikan: tetapkan algoritme pada pihak yang memverifikasi, gunakan rahasia yang kuat, dan lakukan sanitasi terhadap kid. Berikutnya: praktik implementasi JWT yang aman.