عندما تصل رسالة بريد إلكتروني للوصول إلى الحساب متأخرة، غالبًا ما يطلب المستخدمون عدة رسائل أخرى. يمكن أن يؤدي ذلك إلى إنشاء رسائل مكررة ونوافذ صلاحية مربكة وتحميل قائمة انتظار إضافية. قم بتشخيص الرحلة من الطلب إلى الاستخدام الناجح قبل إلقاء اللوم على DNS أو تمديد عمر كل رمز مميز.
إنشاء جدول زمني منقح للحدث
استخدم معرف الارتباط الداخلي لقبول طلب الانضمام، وإنشاء الرمز المميز، ووضع الوظيفة في قائمة الانتظار، وقبول الموفر، واستجابة المتلقي، والرمز المميز الذي تم استرداده أو رفضه. لا تضع الرمز المميز أو إعادة تعيين عنوان URL أو OTP في السجلات الروتينية. سجل المعرفات وفئات الأسباب مع وصول محدود للغاية إلى أي نموذج رسالة مطلوب لاستكشاف الأخطاء وإصلاحها.
قبول SMTP يعني أن الخادم قد قبل المسؤولية في تلك المرحلة؛ ولا يوضح موضع البريد الوارد أو قراءة الإنسان للرسالة. حافظ على هذا التمييز في أدوات الدعم. RFC 5321.
إرشادات تسجيل OWASP يدعم الارتباط مع استبعاد الأسرار من السجلات الروتينية.
فصل المصادقة عن صلاحية التطبيق
فحص الرسائل النهائية التي يتم التحكم فيها لمعرفة هويات المرسل المقصود ونتائج مصادقة المتلقي الموثوق به. يمكن أن يؤدي تكوين البائع القديم إلى قطع هذا المسار حتى أثناء عمل الرسائل الإخبارية. وعلى العكس من ذلك، فإن تمرير مصادقة البريد لا يمكن أن يجعل رمز التطبيق منتهي الصلاحية أو المستخدم بالفعل صالحًا.
توصي OWASP باستخدام الرموز أو الرموز المميزة ذات الاستخدام الواحد بشكل آمن مع انتهاء الصلاحية المناسبة والتخزين الآمن والحماية ضد تعداد الحساب والطلبات المفرطة. توفر إرشادات إعادة تعيين كلمة المرور الخاصة بها خط الأساس الأمني لتدفقات إعادة التعيين، وليس وعدًا بشأن زمن وصول تسليم البريد الإلكتروني. OWASP نسيت إرشادات كلمة المرور.
تتطلب الرموز التي يتم تسليمها عبر البريد الإلكتروني لاستخدامات المصادقة الأخرى تقييمًا أمنيًا خاصًا بها. لا تصف امتلاك البريد الإلكتروني بأنه مصادقة مقاومة للتصيد الاحتيالي، ولا تفترض أن توصية إعادة تعيين كلمة المرور توافق على كل عملية نشر لمرة واحدة (OTP). ضمن متطلبات الهوية الرقمية الخاصة بها، تحظر NIST البريد الإلكتروني باعتباره موثقًا خارج النطاق مع التمييز بين تأكيد العنوان ورموز الاسترداد وبين هذا الحظر. NIST SP 800-63B-4 الأقسام 3.1.3 و 3.1.3.1.
عمل موازنة الصلاحية
يحدد الجدول الزمني الافتراضي إنشاء الرمز المميز عند 09:00:00 وانتهاء الصلاحية عند 09:05:00 . يتم قبول الموفر في الساعة 09:00:10 ، وقبول المتلقي في الساعة 09:04:40 وإجراء المستخدم التوضيحي في 09:05:20 . تبقى 20 ثانية فقط عند قبول جهاز الاستقبال؛ يحدث الإجراء بعد 20 ثانية من انتهاء الصلاحية.
بموجب السياسة المعلنة التي تنص على أن الرمز المميز غير صالح عند انتهاء صلاحيته أو بعده، فإن الرمز المميز غير المستخدم الصالح والمقدم في الثانية 299 سيظل ضمن نافذة الخمس دقائق هذه، في حين أن العرض في الثواني 300 أو 301 لن يكون كذلك. يجب ألا يصبح الرمز المميز الذي تم استرداده بالفعل قابلاً لإعادة الاستخدام لمجرد بقاء الوقت. هذه هي النتائج المتوقعة بموجب السياسة المبتكرة، وليس الشيكات الرمزية المنفذة أو العمر العالمي الموصى به.
السؤال القابل للتنفيذ هو أين ذهبت الـ 280 ثانية بين الإنشاء وقبول المتلقي؟ قبول الموفر في الثانية 10 لا يثبت أن الـ 270 ثانية التالية قد تم إنفاقها بالكامل داخل موفر واحد؛ الحصول على أدلة الانتظار والاستجابة قبل إسناد المسؤولية. تظل رؤية البريد الوارد غير معروفة. لم يتم اختبار أي رمز حقيقي أو حساب إنتاج أو تسليم.
إصلاح المرحلة الفاشلة
إذا كان التطبيق في قائمة الانتظار ببطء شديد، فقم بإعطاء الأولوية لعبء عمل الوصول إلى الحساب وإزالة تأخيرات الدُفعات التي يمكن تجنبها. إذا أبلغ الموفر عن حالات فشل مؤقتة، فافحص الاستجابات الكاملة وإعادة محاولة المعالجة المدعومة. إذا تم إبطال الرمز المميز من خلال طلب أحدث، فاجعل هذا السلوك مفهومًا دون الكشف عما إذا كان الحساب موجودًا لمقدم طلب غير مصادق عليه.
استخدم حدود المعدلات واستجابات الطلبات العامة الواضحة لمنع النقرات المتكررة من أن تصبح طوفانًا من البريد. التوفيق بين عمليات إعادة المحاولة وسياسة الرمز المميز للتطبيق. يمكن أن تؤدي إعادة إرسال رسالة قديمة بشكل عشوائي إلى تسليم رمز مميز غير صالح بالفعل، في حين أن إصدار عدد غير محدود من الرموز المميزة الجديدة يمكن أن يزيد من خطر إساءة الاستخدام.
التحقق دون تسجيل الأسرار
اختبار الحسابات الخاضعة للرقابة المعتمدة عبر الوجهات ذات الصلة وتسجيل زمن الوصول للمرحلة ونتائج انتهاء الصلاحية والمعالجة المكررة. أي تغيير في انتهاء الصلاحية أو إنشاء الرمز المميز أو استرداد الحساب يحتاج إلى مراجعة أمنية؛ إن تمديد العمر ليس بديلاً عن إصلاح قوائم الانتظار.
قم بإغلاق الحادث من خلال سبب خاص بالمرحلة والعلاج المحدد ورحلة العميل المُقاسة. أبقِ فجوات الرؤية المتبقية واضحة. يجب أن يكون فريق الدعم قادرًا على شرح عبارة "تم قبول الرسالة من قبل المتلقي، واستنفدت فترة الصلاحية" دون الادعاء بأن العميل قرأ الرسالة أو كشف بيانات الاعتماد الخاصة به.
اختر المالك من المرحلة الفاشلة
ينتمي تأخير قائمة الانتظار إلى التطبيق أو مشغل الإرسال؛ ينتمي رفض الاستلام الصريح إلى التحقيق في المسار؛ تنتمي النتيجة منتهية الصلاحية أو المستخدمة بالفعل إلى سياسة الرمز المميز وحالة التطبيق. احتفظ بسجل ارتباط منقح واحد واطلب من المالك المعني تحديد إعادة اختبار معتمدة.