ثغرة استعادة كلمة المرور بين المؤسسات تهدد الحسابات

🚨 أحيانًا المشكلة الأمنية مش بتكون في قوة نظام الحماية، لكن في طريقة تطبيقه لقواعد الوصول والصلاحيات.
أثناء اختبار برنامج Bug Bounty لمنصة XYZ، قررت أختبر نقطة في عملية استعادة كلمة المرور (Password Reset):
هل الـ Reset Token مرتبط فعلًا بالـ Tenant اللي تم إنشاؤه من خلاله؟
النتيجة كانت اكتشاف مشكلة أمنية مثيرة للاهتمام: Cross-Tenant Password Reset Token Acceptance.

🔍 إزاي ظهرت المشكلة؟​

أثناء الاختبار، اكتشفت إن النظام بيقبل Password Reset Token صادر من Tenant مختلف عن الـ Tenant المستهدف.
والأغرب إن السلوك ده كان شغال في الاتجاهين:

• Token صادر من Tenant A اتقبل على Tenant B.
• Token صادر من Tenant B اتقبل على Tenant A.
• عملية تغيير كلمة المرور تمت بنجاح على الحساب المستهدف.
• الـ Reset Token كان ممكن إعادة استخدامه.

بمعنى إن النظام لم يكن بيتحقق بشكل صحيح من ارتباط الـ Token بالـ Tenant والحساب المقصودين.

---

⚠️ إيه خطورة الثغرة دي؟​

في أنظمة Multi-Tenant، المفروض كل Tenant يكون معزول عن التاني، سواء في البيانات أو الحسابات أو الصلاحيات.
لكن قبول Reset Token من Tenant مختلف ممكن يكشف خلل في آلية التحقق من الهوية وحدود الوصول.
ولو أمكن استغلال المشكلة ضد حسابات مستخدمين آخرين، فقد يصل تأثيرها إلى Account Takeover (ATO)، حسب شروط الاستغلال والصلاحيات المطلوبة.

---

💡 إيه أهم درس من التجربة دي؟​

مش كل ثغرة أمنية محتاجة Payload معقد أو Exploit متقدم.
أحيانًا سؤال بسيط عن الـ Business Logic في التطبيق ممكن يكشف خلل أمني تأثيره كبير.
أثناء اختبار التطبيقات، متكتفيش بالتأكد إن الـ Token صالح فقط، لكن اهتم كمان بالتحقق من ارتباطه الصحيح بـ:

• المستخدم المقصود (User).
• المؤسسة أو المساحة المستهدفة (Tenant).
• الغرض من إنشاء الـ Token.
• صلاحية استخدامه لمرة واحدة فقط.

الخلاصة: اختبار الـ Business Logic مش رفاهية في Bug Bounty، لكنه جزء مهم جدًا من اكتشاف الثغرات اللي ممكن تفوت على اختبارات الحماية التقليدية. 🎯