Gesaan dan penetapan
Penyedia menandatangani cap masa dan badan mentah. Permintaan mungkin tertangguh, pendua, tidak terbentuk dengan betul (malformed), atau diubah oleh penghuraian JSON. Pelaksanaan mesti menolak pengubahsuaian dan main semula (replay) tanpa membocorkan pemasaan perbandingan.
Perkara yang diuji oleh penemu duga
- Mengekalkan bait yang tepat dan menghuraikan pengepala tandatangan berstruktur dengan selamat.
- Mengira HMAC dengan algoritma yang ditentukan dan membandingkannya dalam masa-malar.
- Menguatkuasakan toleransi cap masa dan tingkah laku kegagalan yang jelas.
Soalan penjelasan sebelum menjawab
- Apakah rentetan bertandatangan yang tepat, algoritma ringkasan (digest), pengekodan, dan format pengepala yang ditentukan oleh penyedia?
- Adakah badan permintaan tersedia sebagai bait mentah sebelum penghuraian JSON?
- Apakah toleransi pencongan jam (clock-skew) dan pengecam main semula yang diperlukan?
- Patutkah input yang tidak terbentuk dengan betul mengembalikan penolakan generik tanpa mendedahkan pemeriksaan mana yang gagal?
Rangka kerja jawapan 30 saat
Saya akan membaca bait mentah, menghuraikan cap masa dan tandatangan tanpa mempercayai jenisnya, menolak cap masa di luar tetingkap yang dibenarkan, dan mengira HMAC ke atas rentetan berkanun yang ditakrifkan oleh penyedia. Saya akan membandingkan bait MAC yang telah dinyahkod dengan primitif masa-malar, kemudian menyahduplikasi ID peristiwa sebelum dimasukkan ke dalam baris gilir. Ralat mengembalikan satu penolakan generik manakala metrik dalaman mengklasifikasikan kegagalan.
Penelitian mendalam langkah demi langkah
1. Kekalkan badan mentah
Jangan jadikan JSON yang dihuraikan sebagai rentetan untuk tujuan pengesahan. Ruang putih, susunan kunci, dan pelarian Unicode boleh mengubah bait. Baca badan sekali sahaja, kuasakan had saiz, dan hantar bait yang sama kepada pengesahan dan penghuraian kemudian.
2. Huraikan dan sahkan pengepala
Pisahkan pengepala kepada cap masa dan tandatangan berversi, tolak pendua atau pengekodan yang tidak sah, dan batasi panjang cap masa. Tukarkan cap masa kepada integer dan tolak nilai di luar tetingkap pencongan yang dikonfigurasikan sebelum melakukan kerja yang berat.
3. Kira dan bandingkan
Bina mesej bertandatangan yang tepat, kira HMAC dengan ringkasan yang dikonfigurasikan, nyahkod tandatangan yang dibekalkan, dan bandingkan tatasusunan bait yang sama panjang dengan fungsi masa-malar. Jangan sekali-kali membandingkan rentetan heksadesimal dengan kesaksamaan biasa apabila penyerang boleh mengukur masa tindak balas.
4. Cegah main semula
Selepas pengesahan tandatangan, perlukan ID peristiwa yang stabil dan rekodkannya secara atomik dengan tempoh pengekalan sekurang-kurangnya sepanjang tetingkap cap masa yang diterima. Permintaan sah yang berulang boleh mengembalikan kejayaan tanpa mengulangi kesan perniagaan.
5. Uji sempadan
Uji bait yang diubah, rahsia yang salah, algoritma yang salah, pengepala yang tidak terbentuk dengan betul, cap masa lama dan masa depan, tandatangan pendua, badan kosong, badan bersaiz lebih, dan ID peristiwa yang berulang. Pastikan log bebas daripada rahsia dan muatan lengkap.
Contoh jawapan berkualiti tinggi
“Saya akan mengekalkan badan mentah, menghuraikan dan mengehadkan cap masa, menolak di luar tetingkap main semula, dan membina rentetan bertandatangan tepat daripada penyedia. Saya akan mengira HMAC dengan ringkasan yang diperlukan, menyahkod tandatangan, dan menggunakan perbandingan bait masa-malar. Selepas pengesahan, saya akan menyahduplikasi ID peristiwa secara atomik sebelum memasukkannya ke dalam baris gilir. Input yang tidak terbentuk dengan betul menerima satu penolakan generik; pembilang dalaman membezakan kegagalan penghuraian, masa, MAC, dan main semula.”
Kesilapan biasa
- Mengesahkan JSON yang dihuraikan → penyirikan boleh mengubah bait yang ditandatangani → sahkan badan mentah.
- Menggunakan kesaksamaan rentetan biasa → pemasaan boleh mendedahkan padanan separa → gunakan perbandingan bait masa-malar.
- Melangkau pemeriksaan cap masa → tandatangan sah boleh dimainkan semula → kuasakan tetingkap berbatas dan penyahduplikasian peristiwa.
- Mencatat log pengepala dan muatan → rahsia atau data peribadi bocor → catat log ID selamat dan kelas kegagalan sahaja.
Soalan susulan dan jawapan
Mengapa perlu mengesahkan sebelum menghuraikan?
Menghuraikan terlebih dahulu boleh menormalkan bait dan mungkin menggunakan aliran permintaan satu kali. Pengesahan mesti meliputi tepat apa yang ditandatangani oleh penyedia; huraikan hanya selepas penerimaan.
Bolehkah dua tandatangan diterima semasa pertukaran (rotation)?
Boleh, jika penyedia mendokumentasikan pertindihan. Cuba hanya versi aktif dan versi yang akan ditamatkan dalam tetingkap yang terhad, rekod versi mana yang lulus, dan tamatkan rahsia lama.
Adakah pengesahan cap masa mencukupi untuk perlindungan main semula?
Tidak. Permintaan yang sah boleh dimainkan semula berulang kali dalam tetingkap masa. Simpan ID peristiwa atau ringkasan yang stabil secara atomik dan jadikan operasi perniagaan idempoten.