Gesaan dan persekitaran
Aplikasi menyulitkan data tempatan dalam pelayar dan memerlukan kunci merentas sesi. Reka bentuk tersebut harus mengurangkan pendedahan kunci, tetapi ia mesti menyatakan had: kod yang berjalan dalam domain asal (origin) masih boleh memanggil operasi yang dibenarkan dan pengguna boleh kehilangan kebolehpulihan data.
Perkara yang diuji oleh penemu duga
- Pemahaman tentang konteks selamat, kebolehekstrakan CryptoKey, dan kegunaan kunci (key usages).
- Mengasingkan storan data tersulit daripada pemulihan kunci dan pemodelan ancaman.
- Menerangkan sebab kriptografi pelayar tidak menjadikan XSS tidak berbahaya.
Soalan penjelasan sebelum menjawab
- Adakah ancaman itu berupa rekod storan yang dicuri, penyerang pasif, atau skrip aktif dari domain asal yang sama?
- Adakah data mesti kekal selepas log keluar, kehilangan peranti, penetapan semula kata laluan, dan pemadaman profil pelayar?
- Bolehkah frasa laluan yang dibekalkan oleh pengguna atau kelayakan WebAuthn membuka kunci pembungkus (wrapping key)?
- Algoritma, kegunaan kunci, sokongan pelayar, dan laluan migrasi yang manakah diperlukan?
Rangka jawapan 30 saat
Saya akan mewajibkan HTTPS, menjana atau mengimport CryptoKey dengan extractable ditetapkan kepada false dan hanya kegunaan yang diperlukan, serta menyimpan pemegang kunci dalam IndexedDB dan bukannya mengeksport bait kunci mentah. Teks sifer (ciphertext), nonce, parameter algoritma dan versi kekal berasingan daripada kunci. Saya akan menggabungkan ini dengan CSP, kawalan kebergantungan yang ketat, dan pelan pemulihan, sambil menyatakan bahawa skrip aktif dari domain asal yang sama masih boleh memanggil API penyulitan atau membaca teks biasa apabila aplikasi dibuka.
Perbincangan mendalam langkah demi langkah
1. Tentukan model ancaman
Sifat tidak boleh diekstrak (non-extractability) mengehadkan eksport yang tidak disengajakan dan banyak laluan kecurian storan. Ia tidak menghalang penyerang yang melaksanakan skrip dalam domain asal daripada meminta aplikasi menyahsulit data atau membaca teks biasa dalam ingatan. Nyatakan sempadan tersebut sebelum menjanjikan keselamatan.
2. Cipta atau import kunci
Gunakan algoritma yang disokong dan kegunaan khusus tujuan seperti encrypt dan decrypt. Jana kunci dalam konteks selamat atau import bahan berbungkus dengan bendera kebolehekstrakan yang diingini. Tolak parameter algoritma yang tidak dijangka dan elakkan menyimpan bahan kunci mentah dalam storan tempatan.
3. Kekalkan teks sifer secara selamat
Simpan teks sifer, nonce baharu bagi setiap penyulitan, metadata disahkan, versi kunci dan versi skema. Gunakan penyulitan disahkan seperti AES-GCM dengan nonce unik di bawah satu kunci. Kekalkan skop penyewa atau pengguna dalam data berkaitan, bukan sebagai keputusan kepercayaan tersirat.
4. Rancang pemulihan dan penggiliran (rotation)
Kunci yang tidak boleh diekstrak boleh menjadi tidak boleh digunakan selepas pemadaman profil atau kehilangan peranti. Tawarkan laluan pemulihan yang disengajakan, contohnya kunci pembungkus yang diterbitkan daripada frasa laluan atau aliran penyulitan semula melalui perantaraan pelayan, tanpa menurunkan taraf secara senyap kepada teks biasa. Versikan kunci dan migrasikan rekod secara transaksi.
5. Uji dan kendalikan
Uji algoritma yang tidak disokong, konteks tidak selamat, ralat kuota, penulisan yang terganggu, penggunaan semula nonce, migrasi versi, log keluar dan kegagalan pemulihan. Gunakan CSP dan semakan kebergantungan, elakkan log sensitif, dan ukur kegagalan penyahsulitan tanpa merekodkan teks biasa.
Contoh jawapan berkualiti tinggi
“Saya akan mewajibkan HTTPS, menjana CryptoKey dengan tujuan terhad bersama extractable bernilai false, dan mengekalkan hanya pemegang yang diuruskan oleh pelayar dalam IndexedDB. Setiap rekod menyimpan teks sifer, nonce unik, metadata disahkan dan versi kunci. Saya akan menentukan pemulihan sebelum pelancaran kerana kehilangan profil boleh menjadikan kunci yang tidak boleh diekstrak tidak dapat dipulihkan. CSP dan kawalan kebergantungan mengurangkan risiko skrip aktif, tetapi muatan XSS yang berjalan dalam domain asal masih boleh memanggil operasi nyahsulit yang dibenarkan atau membaca teks biasa semasa aplikasi dibuka.”
Kesilapan lazim
- Menyimpan kunci mentah dalam localStorage → kecurian storan mendedahkan akses teks biasa → kekalkan pemegang kunci yang tidak boleh diekstrak.
- Menggunakan semula nonce dengan AES-GCM → kerahsiaan dan integriti boleh gagal → jana nonce unik bagi setiap kunci dan rekod.
- Mendakwa XSS telah diselesaikan → kod dari domain asal yang sama boleh menggunakan autoriti aplikasi → nyatakan had skrip aktif.
- Melangkau reka bentuk pemulihan → kehilangan profil memusnahkan akses data → tentukan aliran pembungkusan, penetapan semula dan migrasi.
Soalan susulan dan jawapan
Adakah IndexedDB menjadikan kunci selamat daripada XSS?
Tidak. Ia mengelakkan meletakkan bait mentah dalam API storan mudah, tetapi skrip dari domain asal yang sama boleh mengakses pangkalan data atau memanggil kod aplikasi. Gunakan CSP, kebergantungan yang dipercayai, dan model ancaman yang realistik.
Bagaimanakah pengguna boleh memulihkan data selepas kehilangan peranti?
Bungkus kunci data dengan kunci yang diterbitkan daripada rahsia yang dipegang pengguna atau kelayakan pemulihan, atau lakukan penyulitan semula melalui aliran pelayan yang disahkan. Terangkan kompromi luar talian dan penetapan semula; jangan sekali-kali mencipta kunci baharu secara senyap yang tidak dapat menyahsulit data lama.
Bolehkah kunci dieksport semasa penggiliran?
Hanya jika dasar membenarkannya. Lebih baik menjana kunci baharu dan menyulitkan semula rekod semasa kedua-dua versi tersedia; jika pembungkusan diperlukan, lindungi kunci pembungkus dan audit peralihan tersebut.