Alat pengembang · dekoder JWT
Serangan alg:none dan Kebingungan Kunci: Mengapa Verifikator Harus Menyematkan Algoritma
· Mengapa itu penting
jwt keamanan kriptografi
Jika pemverifikasi mengizinkan token memilih algoritmanya sendiri, penyerang tidak dapat memilih algoritma apa pun atau menukar RSA dengan HMAC. Postingan ini menjelaskan serangan dan aturan yang mencegahnya.
Token yang memverifikasi dirinya sendiri — bagaimana bidang header menjadi permukaan serangan
Label algoritma berada di dalam input token yang dikendalikan penyerang. Jika pemverifikasi memperlakukan label tersebut sebagai izin untuk memilih mode validasi yang tersedia, token mulai memengaruhi aturan yang digunakan untuk menilai dirinya sendiri. ToolAcre menampilkan label secara tepat sehingga pengulas dapat melihatnya, namun tidak pernah bertindak berdasarkan kriptografis.
Arah amannya adalah sebaliknya: konfigurasi layanan tepercaya menentukan kelompok algoritme yang dapat diterima dan kunci terkait, lalu header yang masuk harus sesuai dengan kebijakan tersebut. Panel dekode tidak dapat memberikan kebijakan tersebut dan tidak boleh disalahartikan sebagai perlindungan hanya karena panel tersebut menyoroti nilai yang mencurigakan.
Repositori menandai alg:none tetapi tidak menetapkan riwayat spesifikasi di balik JWT yang tidak aman
Implementasinya memperlakukan `alg: none` sebagai deklarasi yang tidak ditandatangani dan memperingatkan bahwa menerimanya berarti menerima konten sewenang-wenang. Itu juga melaporkan segmen ketiga yang kosong secara terpisah. Bukti repositori mendukung penolakan masukan tersebut dalam alur kerja yang diautentikasi; itu tidak mendokumentasikan mengapa JWT tanpa jaminan awalnya disertakan dalam spesifikasi.
Oleh karena itu, kata-kata historis tersebut dikoreksi, bukan dibuat-buat. Yang penting secara operasional sudah jelas: layanan yang mengharapkan kredensial yang ditandatangani tidak boleh mengizinkan header token menonaktifkan pemeriksaan tanda tangan. ToolAcre sendiri tidak melakukan verifikasi, sehingga kemampuannya untuk menampilkan `none` hanya merupakan deteksi untuk inspeksi.
Serangan alg:none — menghapus tanda tangan dan meminta pemverifikasi untuk menerima tanda tangan yang kosong
Serangan yang tidak ditandatangani mengubah header menjadi permintaan `none`, mengubah klaim jika diinginkan dan tidak memberikan byte tanda tangan. Setiap segmen masih dapat valid secara sintaksis, dan dua segmen pertama didekode menjadi JSON yang dipoles. Pemverifikasi permisif akan mengubah preferensi penyerang menjadi bypass otentikasi.
Pemverifikasi yang ketat tidak memiliki cabang yang meningkatkan input ini ke status tepercaya ketika token yang ditandatangani diperlukan. Peringatan ToolAcre membantu mengidentifikasi bentuk selama proses debug, namun membaca kata `none` tidak menghentikan backend membuat keputusan yang buruk. Penegakan adalah tempat di mana kredensial dikonsumsi.
Kebingungan kunci — menampilkan kunci publik sebagai rahasia HMAC sehingga token RS256 diverifikasi sebagai HS256
Kebingungan kunci muncul ketika pemverifikasi mengizinkan kelompok algoritma dengan peran kunci yang tidak kompatibel dan gagal mengikat setiap pilihan ke jenis kunci yang benar. Kunci verifikasi RSA publik bukanlah rahasia HMAC. Memperlakukan byte-nya sebagai byte setelah penyerang mengubah label algoritme akan meruntuhkan pemisahan public/private yang diinginkan.
Mencegah kelas kesalahan tersebut memerlukan lebih dari sekadar memeriksa segmen berbentuk tanda tangan. Layanan harus memasangkan algoritma yang diharapkan, jenis kunci, penerbit dan profil token melalui konfigurasi tepercaya. Dekoder yang menampilkan RS256 atau HS256 tidak dapat mengetahui apakah backend mempertahankan pengikatan tersebut.
Cara mengatasinya - sematkan algoritme yang diterima di pemverifikasi dan jangan pernah menurunkannya dari token
Sematkan algoritme yang diterima dalam konfigurasi pemverifikasi dan pertahankan daftar sesempit yang diizinkan oleh kontrak penerbit. Tolak `none` untuk alur kredensial yang ditandatangani dan tolak ketidakcocokan daripada mencoba algoritme lain. Jangan mendapatkan daftar yang diizinkan dari header yang belum diverifikasi atau dari klaim payload.
Pencarian kunci mengikuti prinsip yang sama. `kid` dapat memilih di antara kandidat yang sudah dipercaya, namun tidak boleh membuat sumber kepercayaan baru. URL header atau kunci yang disematkan tidak boleh diikuti hanya karena token memintanya. Verifikator memutuskan sumbernya secara independen.
Contoh praktis - membaca header di decoder ToolAcre JWT untuk menemukan alg:none, dan mengapa menemukannya tidak sama dengan dilindungi
Buat header token tidak berbahaya yang mendeklarasikan `none` dan biarkan segmen ketiga kosong. ToolAcre menerjemahkan JSON, melaporkan algoritma yang dideklarasikan, memperingatkan bahwa algoritma tersebut tidak ditandatangani dan mencatat tanda tangan yang tidak ada. Ini adalah perilaku yang diharapkan dari alat inspeksi.
Latihan ini tidak membuktikan bahwa API menolak token tersebut. Konfirmasikan hal tersebut secara terpisah dengan pengujian negatif terkontrol terhadap pemverifikasi dan konfigurasi sebenarnya. Jika API menerimanya, perbaikan termasuk dalam batas verifikasi tersebut; menambahkan peringatan yang lebih keras ke dekoder tidak akan melindungi permintaan.
Apa yang tidak tercakup dalam hal ini — banyaknya perbaikan khusus perpustakaan; lihat RFC 8725 dan log perubahan perpustakaan Anda
Library API, default, dan perbaikan historis bervariasi berdasarkan produk dan versi. Modul ini tidak menetapkan nama opsi mana yang menyematkan algoritme di tumpukan Anda, dan artikel ini sengaja tidak menciptakannya. Baca dokumentasi dan log perubahan terkini dari perpustakaan yang dipilih, lalu laksanakan kasus penolakan di jaringan pengujian Anda sendiri.
Uji juga jenis kunci yang salah, nilai `kid` yang tidak diketahui, tanda tangan yang hilang, dan profil token yang tidak terduga. Tujuannya adalah untuk menunjukkan bahwa konfigurasi menang atas saran token. Dekode yang berhasil tidak termasuk dalam pernyataan penerimaan ini karena keberhasilan sintaksis kompatibel dengan setiap contoh jahat.
Kesimpulan: pemverifikasi yang memutuskan, bukan token — dekoder membantu Anda melihat header, namun hanya verifikasi yang dipasangi pin yang melindungi Anda
Verifikator memutuskan; tokennya tidak. ToolAcre dapat menampilkan header yang bertuliskan `none`, algoritme yang tidak dikenal, atau pengidentifikasi kunci yang mengejutkan. Visibilitas tersebut membantu melakukan triase, namun hanya kebijakan algoritme yang disematkan dan kunci tepercaya yang diikat dengan benar yang mencegah penerimaan.
Jangan pernah menyarankan untuk mengaktifkan `none`, memilih kunci verifikasi dari header yang tidak tepercaya, atau memperlakukan panjang tanda tangan yang ditampilkan sebagai validasi. Dekode untuk inspeksi, lalu buktikan perilaku penolakan dan penerimaan pada batas kriptografi sebenarnya dengan pengujian terkontrol.