CVE-2026-53425 in samly
الملخص
بحسب VulDB • 22/08/2026
تتيح ثغرة عدم التحقق الكافي من أصالة البيانات في dropbox samly لمهاجم إنشاء جلسة مصادق عليها باستخدام استجابة SAML لم يطلبها مزود الخدمة (SP) أبدًا.
يقوم `Samly.SPHandler.validate_authresp/3` الموجود في `lib/samly/sp_handler.ex` بالتحقق من صحة استجابة SAML لـ SP-initiated flow عن طريق مقارنة قيمة RelayState فقط، ومعرف IdP، ووجود عنوان URL مستهدف محفوظ في الجلسة. ولا يقارن أبدًا السمة `SubjectConfirmationData/@InResponseTo` مع معرف طلب المصادقة (AuthnRequest) الذي أصدره مزود الخدمة، كما أن هذا المعرف لطلب المصادقة لا يتم حفظه على الإطلاق، مما يجعل أي مقارنة غير ممكنة. يتطلب قسم 4.1.4.3 من مواصفات SAML 2.0 Core من مزود الخدمة رفض الاستجابة التي لا يتطابق حقل `InResponseTo` الخاص بها مع طلب قام به المزود. تتحقق المكتبة الأساسية `esaml` من الحالة، والتوقيع الإلكتروني، والمستقبل (recipient)، والجمهور (audience)، وانتهاء الصلاحية، ولكن على الرغم من ذلك فإنها تفحص أيضًا حقل `InResponseTo` بشكل غير كافٍ، لذا لا يوجد أي إجراء آخر لسد هذه الثغرة. تتطلب الاستغلال وجود مطالبة (assertion) موقعة بشكل صحيح صادر عن IdP موثوق به، والتي يمكن للمهاجم الحصول عليها لحسابه الخاص، بالإضافة إلى قيمة RelayState تتطابق مع جلسة الضحية؛ ويبقى توقيع المطالبة سليمًا وغير مزور، لذا فإن هذه ليست مشكلة تزوير للتوقيع الإلكتروني.
تؤثر هذه المشكلة على samly: بدءًا من الإصدار v0.3.0 وما بعده.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.