Kegagalan tautan ajaib dapat terjadi setelah pengiriman surat berhasil. Pesan mungkin tiba setelah masa berlakunya habis, aplikasi mungkin membuat tautan sebelumnya tidak valid, atau pengalihan mungkin terjadi di lingkungan yang salah. Selidiki hal ini sebagai hipotesis yang berbeda daripada menganggap setiap proses masuk yang gagal sebagai masalah catatan autentikasi.
Telusuri kedua perjalanan tersebut
Perjalanan email dimulai dari permintaan hingga pembuatan, antrian, dan penerimaan server penerima. Perjalanan aplikasi dimulai dari pembuatan token hingga permintaan tautan, validasi, dan pembuatan sesi. Bergabunglah dengan mereka menggunakan pengidentifikasi korelasi non-rahasia. Jangan mencatat tautan pembawa lengkap atau menempelkan tautan langsung ke pemindai eksternal.
Peristiwa penerimaan SMTP adalah bukti tentang tanggung jawab transfer, bukan sesi pengguna yang telah selesai. Jaga agar label dukungan tetap tepat. RFC 5321. Catat visibilitas yang hilang secara eksplisit ketika penyedia hanya memperlihatkan penyerahan dan status akhir.
Panduan pencatatan OWASP mendukung korelasi tanpa mengungkap rahasia akses.
Validasi desain tautan secara terpisah
Prinsip keamanan dalam panduan pengaturan ulang kata sandi OWASP mencakup token yang kadaluarsa sekali pakai, tujuan HTTPS tepercaya, dan perlindungan terhadap kebocoran token. Prinsip-prinsip tersebut relevan untuk meninjau tautan email yang sensitif, namun sumbernya adalah tentang pengaturan ulang kata sandi dan bukan spesifikasi lengkap untuk login tanpa kata sandi. Produk tautan ajaib memerlukan model ancaman dan kontrol sesinya sendiri. Panduan reset token OWASP.
Periksa host, lingkungan, jalur, dan perilaku pengalihan yang dimaksud menggunakan kredensial pengujian sekali pakai di lingkungan pengujian yang disetujui. Konfirmasikan apakah permintaan yang lebih baru membatalkan tautan sebelumnya dan apakah penggunaan yang berhasil akan membatalkan token. Catat kebijakan sebenarnya alih-alih berasumsi semua produk berperilaku sama.
Bandingkan kegagalan kadaluwarsa dan kegagalan konsumsi
Pertimbangkan dua token hipotetis yang dibuat pada pukul 09:00 UTC dengan masa berlakunya habis pada pukul 09:10. Kasus A mencapai penerimaan penerima pada pukul 09:11, sudah satu menit setelah habis masa berlakunya. Kasus B mencapai tahap tersebut pada 09:01, penukaran aplikasi berhasil dicatat pada 09:02, dan menerima upaya kedua pada 09:03. Berdasarkan kebijakan sekali pakai, upaya kedua B akan gagal karena sudah digunakan meskipun waktu tersisa tujuh menit.
Ini adalah asumsi peristiwa yang diciptakan, bukan eksekusi mesin negara atau insiden yang terverifikasi. Kasus A menyarankan penyelidikan waktu; kasus B memerlukan bukti tentang transisi penerapan sebelumnya. Penundaan pengiriman email yang lebih singkat tidak akan membuat B dapat digunakan kembali. Jangan menugaskan tindakan awal ke pemindai keamanan atau seseorang yang hanya berasal dari string agen pengguna. Hubungkan catatan permintaan resmi yang telah disunting, perubahan status, dan peristiwa sesi sebelum mengatribusikan aktor.
Perbaiki tanpa membuat tautan dapat digunakan kembali
Untuk penundaan nyata, atasi tahap lambat dan verifikasi sisa anggaran validitas. Untuk konsumsi prematur, tinjau apakah aplikasi dapat memisahkan permintaan pendaratan yang tidak berbahaya dari tindakan eksplisit dan tervalidasi dengan aman yang membentuk suatu sesi. Itu adalah tinjauan desain, bukan tambalan universal; menjaga pencegahan pemutaran ulang, kedaluwarsa, dan kontrol lain yang diperlukan.
Hapus pelacakan pemasaran yang tidak perlu dari tautan akun sensitif melalui konfigurasi templat yang disetujui dan verifikasi pesan terakhir. Perilaku pengalihan atau tautan dalam seluler apa pun masih memerlukan pengujian. Jangan pernah menyelesaikan kegagalan yang terputus-putus dengan menerima token yang kedaluwarsa tanpa batas waktu.
Uji ulang perjalanan yang dikontrol untuk mengetahui kedatangan yang tertunda, permintaan berulang, pemutaran ulang, dan perutean lingkungan yang salah. Tutup dengan kelas kegagalan yang sebenarnya dan kesenjangan yang tersisa. Klasifikasi yang jelas mencegah operator email dan teknisi aplikasi berulang kali mengubah sistem yang salah.
Memerlukan penutupan terpisah untuk setiap kelas kegagalan
Kedatangan yang lebih cepat dapat menutup kasus penundaan masa berlaku hanya setelah perjalanan yang terkendali memastikan validitas anggaran. Hal ini tidak dapat menutup kasus konsumsi sebelumnya atau kasus lingkungan yang salah. Catat kelas, pendukung transisi lamaran, dan bukti yang hilang sebelum menetapkan penyebabnya.