ملخص قصير عن أمان OAuth

مقدمة#

قبل بضعة أيام، صادفنا مقالة مثيرة عن ثغرة في OAuth. ثغرة OAuth جديدة قد تؤثر على مئات الخدمات عبر الإنترنت من مختبر SALT. تسلط هذه المقالة الضوء على ثغرة اكتشفت في Expo، وهو إطار عمل شائع الاستخدام لتنفيذ وظائف OAuth وغيرها. تتناول المقالة تحديدًا الثغرة في مكتبة expo-auth-session، والتي تم تعيينها وحلها بشكل صحيح.

إذا كان لديك اهتمام بـ OAuth أو كنت تعمل على منتج يتعلق بالادارة الهوية والتحكم في الوصول CIAM مثلنا، فإننا نوصي بشدة بقراءة هذه المقالة. إنها ملهمة للغاية وتوفر رؤى مفيدة. تعد هذه التقارير الإيجابية تذكيرًا بكيفية أن أبسط الميزات قد تسبب ثغرات أمنية. عندما يتعلق الأمر بالأمن السيبراني والتفويض، لا يمكننا أن نكون حذرين للغاية لضمان أمان وخصوصية معلومات المستخدمين. إذا جذبت هذه المقالة انتباهك، أعتقد أنك ستوافقنا بشدة.

إنها تذكرني بالوقت الذي بدأنا فيه لأول مرة. قضينا وقتًا طويلًا في تعلم وبحث تفاصيل البروتوكولات OAuth وOIDC. كان الأمر مؤلمًا ومملًا، ولكن الفوائد كانت هائلة. ربما ليس كل فرد في فريقنا خبير في OAuth، لكن الجميع ملتزمون بالجهد المستمر نحو الأمن والتفاصيل الدقيقة. بفضل تلك الجهود المخصصة، تطور منتج Logto إلى ما هو عليه اليوم.

شكرًا لهذه الفرصة العظيمة، نود أن ننعش ذاكرتنا ببعض من تفاصيل الأمان في OAuth هنا.

نظرة على تدفق OAuth Authorization Code#

يوفر OAuth 2.0 تدفقات تفويض مختلفة تلبي أنواع العملاء والاحتياجات المختلفة. تشمل هذه التدفقات التدفق الضمني، تدفق بيانات الاعتماد العميل، تدفق بيانات اعتمادات كلمة المرور لمالك الموارد، وتدفق التفويض للجهاز. ومع ذلك، يعتبر تدفق Authorization Code هو الأكثر أمانًا واستخدامًا على نطاق واسع. على عكس التدفقات الأخرى، فإنه يفصل بين المصادقة للمستخدم وتطبيق العميل ويتضمن تبادل رمز التفويض للحصول على الرموز. يوفر هذا النهج طبقة إضافية من الأمان حيث لا يتم الكشف أبدًا عن الرموز الحساسة للعميل. بالإضافة إلى ذلك، يدعم تدفق Authorization Code إدارة الرموز على الخادم، مما يجعله مناسبًا لتطبيقات الويب التي تتطلب أمانًا قوياً وتحكمًا محسنًا في وصول المستخدم.

هنا يعد أبسط مخطط لتدفق Authorization Code:

دعنا نلقي نظرة على أهم طلبين يتم إجراؤهما في تدفق Authorization Code Grant والأجزاء البسيطة الموجودة فيهما والتي تلعب دوراً حاسماً في الحماية من الاحتيال.

نقطة النهاية للتفويض:

نقطة النهاية لتبادل الرموز:

وثائق اعتماد العميل#

في OAuth، تشير وثائق اعتماد العميل إلى بيانات الاعتماد التي تستخدمها تطبيقات العميل للتوثيق وتحديد الهوية عند الاتصال بالخادم المصدري. يتم الحصول على هذه البيانات خلال عملية تسجيل العميل وتستخدم للتحقق من هوية العميل عند إجراء طلبات إلى الخادم المصرح. (قد تجد وثائق الاعتماد الخاصة بالعميل في وحدة إدارة Logto عندما يتم تسجيل تطبيقك لأول مرة. )

تتكون عادةً وثائق اعتماد العميل من مكونين:

1. معرف العميل: هو معرف فريد مُعين لتطبيق العميل من قبل الخادم المصرح. وهو قيمة عامة لا تعتبر عادةً حساسة.
2. سر العميل: هو قيمة سرية مخزنة بشكل آمن معروفة فقط للعميل والخادم المصرح. وهو يعمل كنوع من التوثيق لتطبيق العميل ويستخدم للتحقق من هوية العميل عند إجراء طلبات إلى الخادم المصرح.

كما قد تجد، يتم استخدام مزيج معرف العميل وسر العميل أثناء طلب الرموز للمصادقة والحصول على رموز الوصول.

تلعب بيانات اعتماد العميل دورًا حيويًا في ضمان أمان تدفق OAuth. تساعد الخادم المصرح في التحقق من أصالة تطبيقات العملاء والسيطرة على الوصول إلى الموارد المحمية. من المهم معالجة بيانات اعتماد العميل بشكل آمن وحمايتها من الوصول غير المصرح به. يصنف Logto تطبيقات العميل وفقًا لمستويين مختلفين من الأمان:

• العملاء السريون: وتشمل تطبيقات الويب المعتمدة على الخادم وتطبيقات الآلة إلى الآلة (M2M). في حالة العملاء السريين، يتم تخزين جميع البيانات المعتمدة المتعلقة بالترخيص، بما في ذلك بيانات اعتماد العميل، بشكل آمن على جانب الخادم. بالإضافة إلى ذلك، جميع طلبات التبادل الوسيطة مشفرة لضمان سرية البيانات. خطر تسريب بيانات اعتماد العميل للعملاء السريين منخفض جدًا، مما يجعلها أكثر أمانًا بشكل جوهري. لذلك، يعامل العملاء السريون بمستوى أمان أعلى افتراضيًا. في تدفق تبادل الرموز، تقديم سر العميل هو أمر ضروري.
• العملاء العموميون: تشمل هذه الأنواع تطبيقات الويب الصفحة الواحدة (SPA) والتطبيقات الأصلية. بالنسبة للعملاء العموميين، عادةً ما تكون بيانات الاعتماد الخاصة بالعميل مشفرة في الجانب العميل، مثل داخل حزمة جافا سكريبت أو حزمة تطبيق على منصة أصلية. خطر تسريب بيانات الاعتماد أعلى مقارنةً بالعملاء السريين بسبب التعرض المتأصل لبيانات اعتماد العميل في الشيفرة الجانبية. في تدفق تبادل الرموز، تقديم سر العميل هو أمر اختياري. لا يثق Logto بتلك البيانات المعتمدة من عميل عمومي بطبيعة الحال.

حالة#

في تدفق OAuth، يعد state بارامترًا عشوائيًا تم توليده بشكل آلي يُشمل في طلب التفويض المرسل من العميل إلى الخادم المصرح. الهدف منه هو الحفاظ على حالة أو سياق طلب العميل طوال عملية التفويض.

يعمل بارامتر state كإجراء أمني لمنع الهجمات مثل التزوير عبر المواقع CSRF. عندما يقوم الخادم المصرح بإعادة توجيه المستخدم إلى تطبيق العميل بعد المصادقة والتفويض، فإنه يشمل نفس قيمة الحالة في الرد. يجب على تطبيق العميل مقارنة هذه القيمة بقيمة state الأصلية التي أرسلها في طلب التفويض.

عبر التحقق من بارامتر الحالة، يمكن للعميل ضمان أن الرد المستلم من الخادم المصرح يتوافق مع الطلب الأولي الذي قدمه. هذا يساعد في منع الهجمات التي يحاول فيها المهاجم خداع العميل لقبول استجابة موجهة لمستخدم أو تطبيق آخر.

خذ المثال التالي لهجوم CSRF في حالة استخدام خيالية:

هجوم CSRF: احتيال لربط حساب اجتماعي - المشكلة

مع وجود آلية تحقق مناسبة للحالة، يمكن للعميل اكتشاف الهجوم ومنع المستخدم من إعادة التوجيه إلى موقع الويب الخاص بالمهاجم:

هجوم CSRF: احتيال لربط حساب اجتماعي - الحل

PKCE#

كما ذكرنا سابقاً، العملاء العامون مثل تطبيقات الويب SPA والتطبيقات الأصلية لديهم مخاطر أعلى لتسريب بيانات الاعتماد، بما في ذلك رمز التفويض الذي يصدره الخادم المصرح.

PKCE تعني Proof Key for Code Exchange. وهي امتداد لـ OAuth 2.0 Authorization Code Flow يعزز أمان العملاء العامين.

تم تقديم PKCE للتخفيف من خطر اعتراض رمز التفويض وتبادله بدون معرفة العميل للحصول على رمز الوصول. هذا النوع من الهجمات، والمعروف باسم هجوم اعتراض رمز التفويض، أكثر شيوعًا في البيئات حيث لا يمكن لتطبيق العميل تخزين سر العميل بأمان.

لتنفيذ PKCE، يقوم تطبيق العميل بإنشاء مدقق رمز عشوائي ويشتق منه تحدي رمز باستخدام خوارزمية هاش معينة (عادةً SHA-256). يتم تضمين تحدي الرمز في طلب التفويض الأولي المرسل إلى الخادم المصرح.

عندما يقوم الخادم المصرح بإصدار رمز التفويض، يشمل تطبيق العميل المدقق الأصلي في طلب الرمز. يتحقق الخادم من أن المدقق يطابق تحدي الرمز المخزن ثم يقوم بإصدار رمز الوصول فقط.

باستخدام PKCE، يضمن تطبيق العميل أن رمز التفويض وحده ليس كافيًا للحصول على رمز الوصول. تضيف هذه الآلية طبقة إضافية من الأمان إلى تدفق التفويض، خاصةً للعملاء العامين حيث يكون تخزين أسرار العميل أمرًا صعبًا.

يستخدم Logto PKCE كتدفق التفويض الوحيد لجميع التطبيقات من نوع العميل العام. ومع ذلك، يمكن إغفال PKCE لأولئك العملاء السريين.

إعادة توجيه URI#

URI (معرف الموارد الموحد) إعادة التوجيه هو نهاية محددة أو URL يقوم الخادم المصرح بإعادة توجيه المستخدم إليها بعد عملية المصادقة والتفويض في OAuth.

خلال تدفق OAuth، يشمل تطبيق العميل URI إعادة التوجيه كجزء من طلب التفويض الأولي. يعمل هذا URI كنقطة الارتداد حيث يتم إعادة توجيه المستخدم بعد استكمال المصادقة ومنح الأذونات للعميل.

بمجرد أن يكمل المستخدم عملية المصادقة، يقوم الخادم المصرح بإنشاء استجابة تشمل رمز التفويض، وإعادة توجيه المستخدم إلى URI إعادة التوجيه المحدد.

التحقق من URI إعادة التوجيه هو خطوة أساسية لضمان أمان وسلامة تدفق OAuth. يتضمن هذا التحقق من أن URI إعادة التوجيه المستخدم في طلب التفويض وإعادة التوجيه اللاحقة صحيح وموثوق.

لنعود ونلقي نظرة على تقرير الضعف الأصلي لـ OAuth. (القسم التالي مستند من المقال الأصلي)

عندما يضغط المستخدم على "تسجيل الدخول باستخدام فيسبوك" باستخدام التطبيق المحمول في Expo Go، فإنه يعيد توجيه المستخدم إلى الرابط التالي:

https://auth.expo.io/@moreisless3/me321/start?authUrl=https://www.facebook.com/v6.0/dialog/oauth?code_challenge=...&display=popup&auth_nonce=...&code_challenge_method=S256&redirect_uri=https://auth.expo.io/@moreisless3/me321&client_id=3287341734837076&response_type=code,token&state=gBpzi0quEg&scope=public_profile,email&returnUrl=exp://192.168.14.41:19000/--/expo-auth-session

في الاستجابة، تعيّن auth.expo.io الكوكي التالي: ru=exp://192.168.14.41:19000/--/expo-auth-session. سيتم استخدام القيمة RU لاحقًا كرابط عودة في الخطوة 5. ثم يعرض المستخدم رسالة تأكيد، وإذا وافق المستخدم - يعيد توجيهه إلى فيسبوك لمتابعة تدفق المصادقة

...

تقرأ هذه الصفحة معلمة "returnUrl" وتضع الكوكي بناءً عليها.

لنقم بتغيير returnUrl إلى hTTps://attacker.com (https غير مسموح به، لذلك حاولت إدخال حروف كبيرة وقد نجح الأمر)، مما يحدد RU (رابط العودة) في الكوكي إلى https://attacker.com.

...

في الحالة أعلاه، بدلاً من استخدام البارامتر الأصلي redirect_uri، قدم Expo بارامتر جديد يسمى returnUrl بدون التحقق الصحيح. هذا الإغفال وفر فرصة للمهاجمين للوصول إلى رمز التفويض الذي أرجعته فيسبوك. للمزيد من التفاصيل، يرجى الرجوع إلى المقال الأصلي.

تخدم فحوصات URI إعادة التوجيه عدة أغراض مهمة:

1. منع الهجمات الاحتيالية: من خلال التحقق من URI إعادة التوجيه، يضمن الخادم المصرح أن المستخدم يُعاد توجيهه إلى نقطة نهاية موثوقة ومرخصة. هذا يساعد في منع المهاجمين من إعادة توجيه المستخدمين إلى مواقع ضارة أو غير مرخصة.
2. الحماية من التوجيهات المفتوحة: التوجيهات المفتوحة هي ثغرات يمكن استغلالها لإعادة توجيه المستخدمين إلى مواقع ضارة. من خلال التحقق من URI إعادة التوجيه، يمكن للخادم المصرح ضمان أن التوجيه يبقى داخل حدود النطاق المصرح أو مجموعة النطاقات الموثوقة.
3. ضمان التوجيه الصحيح لاستجابات التفويض: يساعد التحقق من URI إعادة التوجيه في ضمان أن الخادم المصرح يعيد توجيه المستخدم إلى تطبيق العميل المقصود. يضمن أن الاستجابة، مثل رمز التفويض أو رمز الوصول، تُسلم إلى الوجهة الصحيحة.

في Logto، تسجيل redirect_uri إلزامي لجميع أنواع التطبيقات. نقارن ونعادل القيمة المستلمة مع تلك المسجلة في خادم Logto. يشمل ذلك أي معلمات بحث مخصصة. إذا فشل طلب التفويض في التحقق بسبب قيمة redirect_uri مفقودة أو غير صحيحة أو غير متطابقة، فسيتم إرجاع خطأ URI إعادة التوجيه غير الصحيح إلى redirect_uri المسجل في الملف.

ملخص#

نظرًا لطبيعتها المعقدة والدقيقة، من المفهوم أن هذه التفاصيل غالبًا ما تُتجاهل. بعضها مجرد سلسلة عشوائية مثل state.

ومع ذلك، من المهم أن نلاحظ أن هذه التدابير الأمنية تضيف طبقات حماية لتفويض المستخدم، وتخفف من مخاطر مثل هجمات CSRF، واعتراض رمز التفويض، وإعادة التوجيه غير المرخص له.

هذه ليست سوى جزء صغير من الميزات الأمنية الشاملة التي يوفرها بروتوكول OAuth. توفر OAuth إطارًا قويًا للمصادقة والتفويض الآمنين. كما تقدم نهايات مفتوحة ومرنة لتلبية المتطلبات المختلفة في التطبيقات الواقعية للمنتجات.

بصفتنا مطورين ومقدمي خدمات، من الضروري الاستمرار في إعطاء الأولوية لأمان تدفق تفويض المستخدم. الحفاظ على الحذر، واتباع أفضل الممارسات، ومواكبة أحدث التطورات في نظام OAuth البيئي أمر أساسي لضمان سلامة وحماية هويات المستخدمين والبيانات الحساسة. سنبقى ملتزمين بالحفاظ على أعلى معايير الأمان في تنفيذ OAuth وحماية خصوصية وثقة مستخدمينا.