TrendVidStream telah memindahkan keseluruhan timbunan pengesahannya kepada sistem token pembaharuan berputar (rotating-refresh-token) yang mengesan token yang dicuri sebaik sahaja ia digunakan semula. Perubahan ini menukarkan JWT 30 hari yang dahulunya membolehkan penyerang bergerak bebas kepada kredensial jangka pendek yang mencetuskan log keluar serta-merta.

Satu pelanggaran memaksa pertukaran ini dilakukan: sebuah SDK rakan kongsi menyimpan cache JWT 30 hari dalam teks biasa, seorang penyerang mengekstraknya dan menggunakannya semula dari negara lain, dan satu-satunya penyelesaian adalah dengan memutar kunci menandatangan—satu operasi yang menyebabkan semua pengguna log keluar. Insiden tersebut telah membentuk semula keselamatan token syarikat dan kini menjadi nadi kepada perkhidmatan penstriman video tersebut.

Mengapa model lama gagal

JWT (JSON Web Tokens) adalah blok data (blobs) yang mengandungi maklumat sendiri dan telah ditandatangani, yang membolehkan pelayan mengesahkan permintaan tanpa perlu mencari dalam pangkalan data. Kemudahan ini mempunyai kos: jika sesuatu token bertahan selama berminggu-minggu, mencurinya akan memberi penyerang akses selama berminggu-minggu. Dalam pelanggaran tersebut, token yang dicuri kekal sah sehingga tamat tempoh 30 harinya kerana tiada cara untuk membatalkannya lebih awal.

Memutar kunci menandatangan adalah satu-satunya cara global untuk membatalkan semua token, tetapi ia memaksa setiap pengguna untuk log masuk semula, mengganggu perkhidmatan dan menghakis kepercayaan. Kelemahan tersebut bukan terletak pada JWT itu sendiri, tetapi pada pergantungan kepada satu kredensial tunggal yang berjangka panjang.

Ringkasan reka bentuk baharu

TrendVidStream kini mengeluarkan dua jenis token:

  • Access tokens – sah selama 15 minit; ia membawa kebenaran yang diperlukan untuk setiap panggilan API.
  • Refresh tokens – token kegunaan tunggal yang menukarkan token akses jangka pendek dengan pasangan baharu.

Apabila klien membentangkan token pembaharuan, pelayan akan:

  1. Mengesahkan tandatangan dan tuntutan (claims) token tersebut.
  2. Menyemak sama ada token tersebut telah digunakan sebelum ini.
  3. Jika semakan lulus, mengeluarkan token pembaharuan yang baharu sepenuhnya dan token akses 15 minit yang segar.
  4. Menandakan token pembaharuan lama sebagai telah digunakan.

Jika langkah 2 gagal—bermaksud token yang sama muncul buat kali kedua—pelayan akan menganggapnya sebagai isyarat kecurian dan membatalkan keseluruhan "keluarga" token yang dikaitkan dengan sesi log masuk tersebut. Kedua-dua mangsa dan penyerang dipaksa untuk log masuk semula, sekali gus memendekkan tempoh pelanggaran.

Menjejaki keluarga token

Daripada melayan setiap token sebagai rekod yang terasing, sistem ini mengelompokkannya ke dalam keluarga yang bermula apabila pengguna log masuk. Setiap putaran mencipta ahli baharu dalam keluarga tersebut. Skema SQLite yang digunakan dalam pengeluaran menyimpan:

  • family_id – pengenal pasti yang stabil untuk keseluruhan sesi.
  • token_id – pengenal pasti unik untuk setiap token pembaharuan.
  • generation – kaunter yang berguna untuk penyahpepijatan (debugging).
  • used_at – cap masa bila token tersebut ditebus.
  • revoked – penanda (flag) yang, apabila ditetapkan, akan mematikan keseluruhan keluarga tersebut.

Apabila peristiwa penggunaan semula dikesan, penanda revoked untuk family_id tersebut akan ditetapkan, membatalkan setiap token yang tergolong dalam sesi yang terjejas secara serta-merta. Ini menukarkan rampasan senyap kepada amaran isyarat tinggi yang muncul dalam log.

Tiga peraturan pelaksanaan untuk memastikan sistem kekal boleh dipercayai

  1. Sahkan tandatangan terlebih dahulu Penyerang boleh meneka ID token dan mencetuskan pembatalan besar-besaran jika pelayan menyemak "sudah digunakan sebelum ini?" sebelum mengesahkan tandatangan. Mengesahkan ketulenan terlebih dahulu dapat menghalang serangan penafian perkhidmatan (denial-of-service) yang tidak perlu.

  2. Benarkan tempoh bertenang (grace window) Aplikasi mudah alih sering menghantar dua permintaan pembaharuan berturut-turut apabila token tamat tempoh. Jika pelayan terlalu ketat, permintaan kedua akan ditandakan sebagai penggunaan semula, menyebabkan pengguna sah log keluar. Tempoh penimbal (buffer) beberapa saat membolehkan token yang "telah digunakan" masih mengembalikan pasangan baharu, sekali gus melancarkan keadaan perlumbaan (race conditions).

  3. Bungkus keseluruhan aliran dalam transaksi dengan penguncian baris (row locking) Tanpa atomisiti, dua permintaan serentak boleh berfikir bahawa mereka adalah yang pertama menggunakan token, lalu mengeluarkan token pembaharuan pendua dan memecahkan jaminan kegunaan tunggal. Transaksi pangkalan data yang mengunci baris token menjamin bahawa hanya satu permintaan sahaja yang berjaya.

Rumusan: Dengan menjadikan token pembaharuan sebagai kegunaan tunggal dan memantau penggunaan semula, sesebuah sistem boleh menukarkan setiap kredensial yang dicuri menjadi penggera, melindungi pengguna tanpa memaksa log keluar di seluruh platform.