يمكن أن يحدث فشل الارتباط السحري بعد نجاح تسليم البريد. قد تصل الرسالة بعد انتهاء الصلاحية، أو قد يبطل التطبيق رابطًا سابقًا، أو قد تصل عملية إعادة التوجيه إلى بيئة خاطئة. قم بالتحقيق في هذه الفرضيات باعتبارها فرضيات متميزة بدلاً من التعامل مع كل عملية تسجيل دخول غير ناجحة باعتبارها مشكلة في سجل المصادقة.
تتبع الرحلتين
تبدأ رحلة البريد من الطلب وحتى الإنشاء والانتظار وقبول خادم الاستلام. تبدأ رحلة التطبيق من إنشاء الرمز المميز وحتى طلب الارتباط والتحقق من الصحة وإنشاء الجلسة. انضم إليهم باستخدام معرف الارتباط غير السري. لا تقم بتسجيل الروابط الحاملة الكاملة أو لصق رابط مباشر في ماسح ضوئي خارجي.
يعد حدث قبول SMTP دليلاً على مسؤولية النقل، وليس جلسة مستخدم مكتملة. حافظ على دقة تسميات الدعم. RFC 5321. قم بتسجيل الرؤية المفقودة بشكل صريح عندما يكشف الموفر فقط عن الإرسال والحالة النهائية.
إرشادات تسجيل OWASP يدعم الارتباط دون كشف أسرار الوصول.
التحقق من صحة تصميم الارتباط بشكل منفصل
تتضمن مبادئ الأمان في إرشادات إعادة تعيين كلمة المرور الخاصة بـ OWASP الرموز المميزة التي تنتهي صلاحيتها للاستخدام مرة واحدة، ووجهات HTTPS الموثوقة والحماية من تسرب الرمز المميز. تتعلق هذه المبادئ بمراجعة الروابط الحساسة المرسلة عبر البريد الإلكتروني، ولكن المصدر يدور حول إعادة تعيين كلمة المرور بدلاً من المواصفات الكاملة لتسجيل الدخول بدون كلمة مرور. يحتاج منتج الارتباط السحري إلى نموذج التهديد الخاص به وعناصر التحكم في الجلسة. إرشادات إعادة تعيين الرمز المميز لـ OWASP.
افحص سلوك المضيف والبيئة والمسار وإعادة التوجيه المقصود باستخدام بيانات اعتماد الاختبار التي يمكن التخلص منها في بيئة اختبار معتمدة. تأكد مما إذا كان الطلب الأحدث يبطل الروابط السابقة وما إذا كان الاستخدام الناجح يبطل الرمز المميز. قم بتسجيل السياسة الفعلية بدلاً من افتراض أن جميع المنتجات تتصرف بشكل مماثل.
قارن بين فشل انتهاء الصلاحية وفشل الاستهلاك
فكر في رمزين افتراضيين تم إنشاؤهما في الساعة 09:00 بالتوقيت العالمي المنسق مع انتهاء الصلاحية في الساعة 09:10. تصل الحالة "أ" إلى قبول المتلقي في الساعة 09:11، أي بعد دقيقة واحدة من انتهاء الصلاحية. تصل الحالة "ب" إلى تلك المرحلة في الساعة 09:01، ويتم تسجيل استرداد الطلب الناجح في الساعة 09:02، وتستقبل المحاولة الثانية في الساعة 09:03. بموجب سياسة الاستخدام المفرد، يجب أن تفشل المحاولة الثانية لـ B كما تم استخدامها بالفعل على الرغم من بقاء سبع دقائق.
هذه افتراضات حدث مخترعة، وليست تنفيذًا لآلة الدولة أو حوادث تم التحقق منها. الحالة (أ) تقترح إجراء تحقيق في التوقيت؛ تتطلب الحالة ب دليلاً حول النقل المبكر للتطبيق. إن تأخير البريد الأقصر لن يجعل B قابلاً لإعادة الاستخدام. لا تقم بتعيين الإجراء المبكر لفحص الأمان أو لشخص فقط من سلسلة وكيل المستخدم. قم بربط سجلات الطلب المنقحة المعتمدة وتغييرات الحالة وأحداث الجلسة قبل إسناد الممثل.
إصلاح دون جعل الروابط قابلة لإعادة الاستخدام
للتأخير الحقيقي، قم بمعالجة المرحلة البطيئة وتحقق من ميزانية الصلاحية المتبقية. بالنسبة للاستهلاك المبكر، راجع ما إذا كان التطبيق يمكنه فصل طلب وصول غير ضار عن الإجراء الصريح الذي تم التحقق من صحته بشكل آمن والذي ينشئ جلسة. هذه مراجعة للتصميم، وليست تصحيحًا عالميًا؛ الحفاظ على منع إعادة التشغيل وانتهاء الصلاحية وغيرها من الضوابط المطلوبة.
قم بإزالة التتبع التسويقي غير الضروري من روابط الحساب الحساسة من خلال تكوين القالب المعتمد وتحقق من الرسالة النهائية. لا يزال أي سلوك لإعادة التوجيه أو الارتباط العميق للجوال بحاجة إلى الاختبار. لا تحل أبدًا مشكلة الفشل المتقطع عن طريق قبول الرموز المميزة منتهية الصلاحية إلى أجل غير مسمى.
أعد اختبار الرحلات التي تم التحكم فيها لتأخير الوصول والطلبات المتكررة وإعادة التشغيل والتوجيه الخاطئ للبيئة. أغلق بفئة الفشل الدقيقة والفجوات المتبقية. يمنع التصنيف الواضح مشغلي البريد ومهندسي التطبيقات من تغيير النظام الخاطئ بشكل متكرر.
تتطلب إغلاقًا منفصلاً لكل فئة فشل
يمكن للوصول الأسرع إغلاق حالة تأخير انتهاء الصلاحية فقط بعد أن تؤكد الرحلة الخاضعة للرقابة ميزانية الصلاحية. ولا يمكن إغلاق قضية الاستهلاك المسبق أو البيئة الخاطئة. قم بتسجيل الفصل ودعم انتقال التطبيق والأدلة المفقودة قبل تحديد السبب.