Security Assertion Markup Language
السلام عليكم ورحمة الله وبركاته
في هذه المقالة سنتطرق أولًا لشرح الـ Security Assertion Markup Language (SAML)
ومن ثم سنلقي نظرة على إحدى الثغرات المرتبطة بالـ SAML
لنبدأ بالجزء الأول ... بسم الله
ما هو الـ SAML ؟
الـ SAML هو معيار ( أو بروتوكول إن صح التعبير) مفتوح المصدر يمكّننا من تنفيذ (Implement) مفهوم الـ Single Sign-On (SSO) ، هذا التعريف النظري المختصر جدًا،
بما أن الـ SAML يتيح لنا تنفيذ مفهوم الـ SSO لنلخص هذا المفهوم بشكل عام
في الـ SSO لدينا Authentication Service واحدة يتعامل معها المستخدم ، وبعد أن تتم عملية الـ Authentication بنجاح يستطيع المستخدم الوصول لعدة أنظمة أو خدمات
الآن لو عدنا للـ SAML سنجد أن هذا المعيار يتكون من الأطراف الآتية :
Identity Provider (IdP) : المسؤول عن عملية الـ Authentication ومن ثم تمرير النتيجة للـ Service Provider (SP)
Service Provider (SP) : الخدمة التي يريد المستخدم الوصول لها والتي قامت بتوجيه المستخدم إلى الـ IdP حتى تتم عملية الـ Authentication قبل الوصول الى الـ Resources
الرسم التالي يلخّص آلية عمل الـ SAML
1 : في هذه الخطوة يقوم المستخدم بطلب الوصول الى الـ Resource الموجودة لدى الـ Service Provider
2 :
- سيقوم الـ Service Provider بإعادة توجيه المستخدم الى الـ Identity Provider لإتمام عملية الـ Authentication أولًا قبل السماح بالوصول الى الـ ) Resources الـ IdP كما ذكرنا سابقًا هو المسؤول عن عملية الـ Authentication في الـ SAML )
- تُعرَف هذه الخطوة أيضًا بـ SAML Request
3 :
- يقوم المستخدم بإتمام عملية الـ Authentication عبر الـ Identity Provider
- بعد أن تتم عملية الـ Authentication بنجاح يقوم الـ Identity Provider بإعادة توجيه المستخدم إلى الـ Service Provider
4 :
- عندما يتم إعادة توجيه المستخدم الى الـ Service Provider ، يقوم الـ Identity Provider بإرفاق XML Document مع المستخدم ، حيث يوضح هذا الـ XML Document العديد من الصلاحيات والبيانات التي يقوم الـ Service Provider بمعالجتها قبل السماح للمستخدم بالوصول الى الـ Resource المطلوبة
- في هذا الجزء من عملية التواصل بين الـ SP والـ IdP قد تحدث العديد من الثغرات المتعلقة بالـ SAML إذا لم يقم الـ Service Provider بمعالجة الـ XML Document بشكل جيد
- تُعرَف هذه الخطوة أيضًا بـ SAML Response
- في هذه المقالة سنناقش أحد الثغرات الممكن حدوثها خلال هذه الخطوة
5 و 6 و 7 و 8 :
- يستكمل الـ Service Provider معالجة طلب المستخدم حتى يصل المستخدم الى الخدمة المطلوبة
- هذه الخطوات خارج نطاق اهتمامنا في هذه المقالة
SAML Response :
عرفنا سابقًا أنه بعد أن يقوم المستخدم بإتمام عملية الـAuthentication يقوم الـ IdP بالرد على الـ SP وهذا الرد هو ما يسمى بالـ ـ SAML Response
يحتوي الـ SAML Response على جزء مهم جدًا يسمى الـ SAML Assertion
الـ SAML Assertion ما هو إلا XML Document يوضّح معلومات مثل هوية المستخدم وقد يحتوي أيضًا على خصائص أخرى مرتبطة بالمستخدم
الرسم التالي يلخّص أيضًا الـ Syntax الخاص بالـ SAML Assertion
بعد التعرف على الـ SAML سننتقل للجزء الثاني من هذه المقالة
Vulnerable SAML Infrastructure :
سنشرح الثغرة المتعلقة بالـ SAML على هذا التطبيق
ملاحظات:
- التطبيق يحتوي على العديد من الثغرات المرتبطة بالـ SAML، تستطيع الإطلاع على تفاصيلها والـ write-up لكل ثغرة من هنا
- في هذه المقالة سنناقش السيناريو التالي:
إعداد التطبيق :
نبدأ أولًا بإعداد التطبيق، ولتشغيل التطبيق ستحتاج قبلها تثبيت Docker
في حالتي قمت باعداد التطبيق بالطريقة الأسرع ، ألا وهي تشغيل التطبيق عبر الـ docker-compose والتي ستقوم بتشغيل الـ docker containers الخاصة بكلا التطبيقين الـ Service Provider والـ Identity Provider
بعد تشغيل التطبيق نستطيع الوصول لتطبيق الـ Service Provider عبر الآي بي والمنفذ التالي : http://127.0.0.1:8000 وتطبيق الـ Identity Provider عبر : http://127.0.0.1
سنحتاج أيضًا لضبط إعدادات التطبيق حسب السيناريو المذكور سابقًا ولتنفيذ ذلك سنسجل الدخول الى التطبيق بصلاحية المستخدم instructor ونضبط الخيارات كالآتي :
Nothing Configured :
في هذا السيناريو الـ Service Provider يقوم باستقبال الـ SAML Response من الـ Identity Provider ومن ثم معالجته بدون إجراء أي تحقق على سلامة الـ SAML Response ضد التعديل
سنبدأ أولًا بتسجيل الدخول كمستخدم عادي (yogi) لا يملك صلاحيات على الـ Service Provider
عند إعتراضنا لطلب تسجيل الدخول سنجد أن المسؤول عن هذه الخطوة هو الـ Identity Provider كما يظهر في الـ Host Header
- هذه الخطوة رقم 3 في الرسم السابق الخاص بالـ SAML
بعد إتمام عملية تسجيل الدخول بنجاح عبر الـ Identity Provider سنجد الـ Request التالي والذي يحتوي على الـ SAML Response كما نرى
- هذه الخطوة رقم 4 في الرسم السابق الخاص بالـ SAML
لو قمنا بعمل decode للـ SAML Response سنجد أنه عباره عن XML document كما ذكرنا سابقًا ويحتوي على بعض البيانات
بعد تحليل البيانات في الـ SAML Response سنلاحظ وجود Attribute تحدد صلاحية المستخدم .. تحديدًا ضمن الـ AttributeStatement
الصورة التالية توضح جميع الحقول المعرفة ضمن الـ AttributeStatement
سنقوم بالتعديل على القيمة المخزنه في الحقل memberOf حيث يبدو أنه هذا الحقل يحدد صلاحية المستخدم
قيمة الحقل قبل التعديل :
وسنقوم بتعديل هذه القيمة الى صلاحية أعلى .. ومن ثم نرى إستجابة التطبيق
بعد تمرير الـ Request سنلاحظ أننا إستطعنا الدخول الى التطبيق بالإضافة الى أنه تم تعديل الـ group membership الخاصة بالمستخدم
إضافة الى ذلك، لو تصفحنا الخانة الخاصة بالـ Complaints سنجد أن المستخدم يستطيع التعديل عليها
الى هنا نكون انتهينا من حل هذا السيناريو
مواضيع مُقترحة حول الثغرات المرتبطة بالـ SAML :
XML Signature Wrapping (XSW)
ختامًا، أود الإشارة بأن هذه المقالة تمّت كتابتها خلال دراسة هذه المواضيع، فكل ما تم ذكره هنا قد يحتمل الخطأ، لكن بالإمكان العودة إلى المراجع التي إستندت عليها هذه المقالة
وإن أصبت فمن توفيق الله وحده، وإن أخطأت فمن نفسي والشيطان
المراجع:
مقالات:
- https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html
- https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/
- https://auth0.com/blog/how-saml-authentication-works/
- https://blog.aniljohn.com/2007/11/saml-20-assertion-syntax.html
- https://wiki.surfnet.nl/display/surfconextdev/Responses+and+Assertions
دورات:
- WAPTXv2 from eLearnSecurity