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

في هذه المقالة ، أريد مشاركة مفاهيم هجمات OAuth 2.0 المتنقلة وآليات الأمان المستخدمة لمنع مثل هذه المشكلات. المفاهيم الموصوفة ليست جديدة ولكن هناك نقص في المعلومات المنظمة حول هذا الموضوع. الهدف الرئيسي من المقال هو سد هذه الفجوة.

2.0 طبيعة والغرض

OAuth 2.0 هو بروتوكول تخويل يصف طريقة لخدمة العملاء للحصول على وصول آمن إلى موارد المستخدم على موفر الخدمة. بفضل OAuth 2.0 ، لا يحتاج المستخدم إلى إدخال كلمة المرور الخاصة به خارج مزود الخدمة: يتم تقليل العملية برمتها إلى النقر على زر "أوافق على توفير الوصول إلى ...".

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

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

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

لذلك ، دعونا نتعرف على كيفية جعل OAuth 2.0 المحمول آمنًا.

كيف يعمل؟

هناك مشكلتان رئيسيتان للأمان في OAuth 2.0 على الأجهزة المحمولة:

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

دعونا ننظر بعمق في هذه القضايا.

تطبيق المحمول هو عميل عام

لفهم جذور المشكلة الأولى وعواقبها ، دعونا نرى كيف يعمل OAuth 2.0 في حالة تفاعل الخادم من الخادم ثم مقارنته بـ OAuth 2.0 في حالة تفاعل العميل مع الخادم.

في كلتا الحالتين ، يبدأ كل شيء بسجلات خدمة العميل على خدمة الموفر ويتلقى client_id , وفي بعض الحالات , client_secret. client_id , client_secret. client_id هي قيمة عامة ، وهي مطلوبة لتعريف خدمة العميل بدلاً من قيمة client_secret ، وهي خاصة. يمكنك قراءة المزيد حول عملية التسجيل في RFC 7591 .

يوضح المخطط أدناه الطريقة التي يعمل بها OAuth 2.0 في حالة تفاعل الخادم مع الخادم.


أصل الصورة: https://tools.ietf.org/html/rfc6749#section-1.2

يمكن تقسيم بروتوكول OAuth 2.0 إلى ثلاث خطوات رئيسية:

1. [خطوات AC] تلقي code authorization_code (يشار إليه فيما يلي code ).
   
2. [خطوات DE] تبادل code إلى access_token .
   
3. الحصول على الموارد عبر access_token .

دعنا نوضح عملية الحصول على قيمة code :

1. [الخطوة أ] يعيد العميل توجيه المستخدم إلى مزود الخدمة.
   
2. [الخطوة ب] يطلب مزود الخدمة إذنًا من المستخدم لتزويد العميل بالبيانات (السهم B لأعلى). يوفر المستخدم الوصول إلى البيانات (السهم B إلى اليمين).
   
3. [الخطوة C] يقوم موفر الخدمة بإرجاع code إلى متصفح المستخدم الذي يعيد توجيه code إلى العميل.
   

دعنا نتحدث أكثر عن عملية الحصول على access_token :

1. [الخطوة د] يرسل خادم العميل طلبًا access_token . يتم تضمين Code و client_secret و redirect_uri في الطلب.
   
2. [الخطوة E] في حالة وجود code صالح ، client_secret و redirect_uri ، يتم توفير access_token .
   

يتم طلب access_token وفقًا لخطة الخادم إلى الخادم: لذلك ، بشكل عام ، يجب على المهاجم اختراق خادم خدمة العملاء أو خادم مزود الخدمة من أجل سرقة access_token إلى access_token .

الآن دعونا نلقي نظرة على نظام OAuth 2.0 المحمول دون الواجهة الخلفية (تفاعل العميل إلى الخادم).


أصل الصورة: https://tools.ietf.org/html/rfc8252#section-4.1

ينقسم المخطط الرئيسي إلى نفس الخطوات الرئيسية:

1. [الخطوات 1-4 في الصورة] الحصول على code .
2. [الخطوات 5-6 في الصورة] code التبادل إلى access_token
3. كسب الوصول إلى الموارد عبر الوصول

ومع ذلك ، في هذه الحالة التطبيق المحمول لديه أيضا وظائف الخادم. لذلك ، سيتم تضمين client_secret في التطبيق. نتيجةً لذلك ، لا يمكن client_secret عن المهاجم على الأجهزة المحمولة. يمكن استخراج client_secret المضمّن بطريقتين: عن طريق تحليل حركة مرور التطبيق إلى الخادم أو عن طريق الهندسة العكسية. كلاهما يمكن تنفيذهما بسهولة ، وهذا هو السبب في أن client_secret لا فائدة منه على الأجهزة المحمولة.

قد تسأل: "لماذا لا نحصل على access_token على الفور؟" قد تعتقد أن هذه الخطوة الإضافية غير ضرورية. علاوة على ذلك ، هناك مخطط منح ضمني يسمح للعميل باستلام access_token إلى access_token الفور. على الرغم من أنه يمكن استخدامه في بعض الحالات ، لن تعمل Implicit Grant على تأمين OAuth 2.0 للجوال.

إعادة التوجيه على الأجهزة المحمولة

بشكل عام ، تُستخدم آليات URI Scheme و AppLink المخصصة لإعادة توجيه المتصفح إلى التطبيق. لا يمكن لأي من هذه الآليات أن تكون آمنة مثل إعادة توجيه المتصفح من تلقاء نفسه.

يتم استخدام نظام URI المخصص (أو الرابط العميق) بالطريقة التالية: يحدد المطور نظام تطبيق قبل النشر. يمكن أن يكون المخطط موجودًا ، ويمكن أن يحتوي جهاز واحد على العديد من التطبيقات بنفس المخطط.

يجعل الأمور أسهل عندما يتوافق كل مخطط على جهاز مع تطبيق واحد. ولكن ماذا لو سجل تطبيقان نفس المخطط على جهاز واحد؟ كيف يقرر نظام التشغيل التطبيق الذي سيتم فتحه عند الاتصال به عبر Custom URI Scheme؟ سيعرض Android نافذة مع اختيار تطبيق ورابط للمتابعة. لا يشتمل نظام iOS على إجراء لذلك ، وبالتالي قد يتم فتح أي تطبيق. على أي حال ، يحصل المهاجم على فرصة لاعتراض التعليمات البرمجية أو الوصول إلى الوصول .

بخلاف Custom URI Scheme ، تضمن AppLink فتح التطبيق الصحيح ، لكن هذه الآلية بها عدة عيوب:

1. يجب أن يخضع كل عميل خدمة لإجراء التحقق .
   
2. يمكن لمستخدمي Android إيقاف تشغيل AppLink لتطبيق معين في الإعدادات.
   
3. لا تدعم إصدارات Android الأقدم من 6.0 والإصدارات الأقدم من iOS AppLink.
   

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

حسنا ، ماذا يوجد للهجوم؟

خلقت مشاكل Mobile OAuth 2.0 بعض الهجمات المحددة. دعونا نرى ما هي وكيف تعمل.

اعتراض رمز اعتراض الهجوم

لنأخذ في الاعتبار الحالة التي يكون فيها لجهاز المستخدم تطبيق شرعي (عميل OAuth 2.0) وتطبيق خبيث سجل نفس النظام كتطبيق شرعي. الصورة أدناه توضح مخطط الهجوم.


أصل الصورة https://tools.ietf.org/html/rfc7636#section-1

هذه هي المشكلة: في الخطوة الرابعة ، يقوم المستعرض بإرجاع code في التطبيق عبر Custom URI Scheme ، وبالتالي ، يمكن اعتراض code بواسطة تطبيق ضار (نظرًا لأنه سجل نفس المخطط كتطبيق شرعي). ثم يقوم التطبيق الضار بتغيير code إلى access_token ويستقبل الوصول إلى بيانات المستخدم.

ما هي الحماية؟ في بعض الحالات ، يمكنك استخدام الاتصال بين العمليات. سنتحدث عن ذلك لاحقا. بشكل عام ، تحتاج إلى نظام يسمى Proof Key for Code Exchange . وصفها في المخطط أدناه.


أصل الصورة: https://tools.ietf.org/html/rfc7636#section-1.1

يحتوي طلب العميل على العديد من المعلمات الإضافية: code_verifier و code_challenge (في المخطط t(code_verifier) ) و code_challenge_method (في المخطط t_m ).

Code_verifier - هو رقم عشوائي بطول لا يقل عن 256 بت ، ويتم استخدامه مرة واحدة فقط . لذلك ، يجب على العميل إنشاء code_verifier جديد لكل طلب code .

Code_challenge_method - هذا هو اسم وظيفة التحويل ، ومعظمهم من SHA-256.

Code_challenge - هو code_verifier الذي تم تطبيق تحويل code_challenge_method والذي تم تشفيره في URL Safe Base64.

يعد تحويل code_verifier إلى code_challenge ضروريًا لرفض متجهات الهجوم بناءً على اعتراض code_verifier (على سبيل المثال ، من سجلات نظام الجهاز) عند طلب code .

في حالة عدم دعم جهاز مستخدم SHA-256 ، client is allowed to use plain conversion of code_verifier . في جميع الحالات الأخرى ، يجب استخدام SHA-256.

هذه هي الطريقة التي يعمل بها هذا المخطط:

1. ينشئ العميل code_verifier .
   
2. يختار العميل code_challenge_method ويستقبل code_challenge من code_verifier .
   
3. [الخطوة أ] يطلب العميل code ، مع إضافة code_challenge_method و code_challenge_method إلى الطلب.
   
4. [الخطوة ب] يخزن الموفر code_challenge و code_challenge_method على الخادم ويعيد code إلى العميل.
   
5. [الخطوة C] يطلب العميل access_token ، مع إضافة code_verifier إليه.
   
6. يستقبل الموفر code_challenge من code_challenge الوارد ، ثم يقارنه بـ code_challenge ، الذي حفظه.
   
7. [الخطوة د] في حالة تطابق القيم ، يمنح الموفر العميل access_token .
   

لفهم لماذا code_challenge اعتراض التعليمات البرمجية ، لنرى كيف يبدو تدفق البروتوكول من منظور المهاجم.

1. أولاً ، يتم إرسال code طلبات التطبيق المشروعة ( code_challenge و code_challenge_method مع الطلب ).
   
2. يعترض التطبيق الضار code (ولكن ليس code_challenge ، نظرًا لأن الكود _challenge ليس في الاستجابة).
   
3. يطلب التطبيق الضار access_token (مع code صالح ، ولكن بدون code_verifier صالح).
   
4. يلاحظ الخادم عدم تطابق code_challenge ويرفع رسالة خطأ.
   

لاحظ أن المهاجم لا يمكنه تخمين code_verifier (قيمة عشوائية 256 بت!) أو العثور عليه في مكان ما في السجلات (حيث أن أول طلب ينتقل فعليًا code_challenge ).

لذلك ، يجيب code_challenge عن سؤال مزود الخدمة: "هل يطلب access_token من نفس عميل التطبيق الذي طلب code أو code مختلفًا؟".

OAuth 2.0 CSRF

OAuth 2.0 CSRF غير ضار نسبيًا عند استخدام OAuth 2.0 للترخيص. إنها قصة مختلفة تمامًا عند استخدام OAuth 2.0 للمصادقة. في هذه الحالة ، يؤدي OAuth 2.0 CSRF غالبًا إلى الاستيلاء على الحساب.

دعونا نتحدث أكثر عن هجوم CSRF وفقًا لـ OAuth 2.0 من خلال مثال عميل تطبيق سيارات الأجرة ومزود provider.com. أولاً ، يقوم المهاجم الموجود على أجهزته الخاصة بتسجيل الدخول إلى حساب attacker@provider.com ويتلقى code لسيارة أجرة. ثم يقطع عملية OAuth 2.0 ويقوم بإنشاء رابط:

 com.taxi.app://oauth? code=b57b236c9bcd2a61fcd627b69ae2d7a6eb5bc13f2dc25311348ee08df43bc0c4 

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

الآن يمكن للمهاجم تسجيل الدخول إلى حساب تاكسي الضحية في أي وقت ، لأنه مرتبط بـ attacker@provider.com . سمح هجوم تسجيل الدخول إلى CSRF للمخالف بسرقة حساب.

عادةً ما يتم رفض هجمات CSRF برمز CSRF (يطلق عليه أيضًا state ) ، و OAuth 2.0 ليس استثناء. كيفية استخدام الرمز CSRF:

1. يقوم تطبيق العميل بإنشاء وحفظ الرمز CSRF على جهاز العميل المحمول.
   
2. يتضمن تطبيق العميل الرمز المميز CSRF في طلب الوصول إلى code .
   
3. إرجاع Server الرمز المميز CSRF نفسه مع code في الرد الخاص به.
   
4. يقارن تطبيق العميل الرموز CSRF الواردة والمحفوظة. إذا كانت قيمهم متطابقة ، فستستمر العملية.
   

متطلبات رمز CSRF: يجب أن يكون nonce على الأقل 256 بت وأن يتم استلامه من مصدر جيد للتسلسلات العشوائية الزائفة.

باختصار ، يسمح رمز CSRF لعميل التطبيق بالإجابة على السؤال التالي: "هل كنت أنا الذي بدأ طلب access_token أو شخص ما يحاول access_token ؟".

سر العميل الثابت

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

يعتمد تأثير تعريض client_id و client_secret بشدة على مقدار موفر خدمة الثقة الذي يضعه على بعض client_id ، زوج client_secret . يستخدم أحدهم فقط لتمييز عميل واحد عن آخر بينما يقوم الآخرون بفتح نقاط نهاية API مخفية أو تحديد حدود سعر أكثر ليونة لبعض العملاء.

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

تطبيق ضار يتصرف كعميل شرعي

يمكن لبعض التطبيقات الضارة تقليد التطبيقات المشروعة وعرض شاشة موافقة بالنيابة عنها (شاشة الموافقة هي شاشة يرى المستخدم فيها: "أوافق على توفير الوصول إلى ..."). قد ينقر المستخدم على "السماح" ويزود التطبيق الضار ببياناته.

يوفر كل من Android و iOS آليات للتطبيقات. يستطيع موفر التطبيق التأكد من أن تطبيق العميل مشروع والعكس صحيح.

لسوء الحظ ، إذا كانت آلية OAuth 2.0 تستخدم سلسلة رسائل عبر المتصفح ، فمن المستحيل الدفاع عن هذا الهجوم.

هجمات أخرى

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

كيف نفعل ذلك بشكل آمن؟

لقد تعلمنا كيف يعمل بروتوكول OAuth 2.0 وما هي نقاط الضعف الموجودة على الأجهزة المحمولة. الآن ، دعونا نضع الأجزاء المنفصلة معًا للحصول على مخطط آمن لنظام OAuth 2.0 المحمول.

جيد ، سيء 2.0

لنبدأ بالطريقة الصحيحة لاستخدام شاشة الموافقة. للأجهزة المحمولة طريقتان لفتح صفحة ويب في تطبيق محمول.



الطريقة الأولى هي عن طريق متصفح Custom Tab (على اليسار في الصورة). ملاحظة : يطلق على علامة تبويب المتصفح المخصصة لنظام أندرويد علامة تبويب Chrome المخصصة ، ولـ iOS - SafariViewController. إنها مجرد علامة تبويب في المتصفح يتم عرضها في التطبيق: لا يوجد تبديل مرئي بين التطبيقات.

الطريقة الثانية هي عبر WebView (على اليمين في الصورة) ، وأعتقد أنها سيئة فيما يتعلق بـ OAuth 2.0 المحمول.

WebView هو متصفح مضمن لتطبيق جوال.

" المستعرض المضمن " يعني أن الوصول إلى ملفات تعريف الارتباط والتخزين وذاكرة التخزين المؤقت والمحفوظات وغيرها من بيانات Safari و Chrome محظور على WebView. العكس صحيح أيضًا: لا يستطيع Safari و Chrome الوصول إلى بيانات WebView.

" متصفح تطبيقات الجوال " يعني أن تطبيق الجوّال الذي يشغّل WebView له حق الوصول الكامل إلى ملفات تعريف الارتباط والتخزين وذاكرة التخزين المؤقت والتاريخ وبيانات WebView الأخرى.

الآن ، تخيل: ينقر أحد المستخدمين على "enter with ..." ويطلب WebView من أحد التطبيقات الضارة تسجيل الدخول وكلمة المرور من مزود الخدمة.

ملحمة تفشل:

1. يقوم المستخدم بإدخال معلومات تسجيل الدخول وكلمة المرور الخاصة بحساب مزود الخدمة في التطبيق ، مما يسهل سرقة هذه البيانات.
   
2. تم تطوير OAuth 2.0 في البداية لعدم إدخال اسم المستخدم وكلمة المرور الخاصة بمزود الخدمة.
   
   يعتاد المستخدم على إدخال تسجيل الدخول وكلمة المرور الخاصة به في أي مكان وبالتالي زيادة إمكانية الصيد .
   

بالنظر إلى جميع سلبيات WebView ، فإن الاستنتاج الواضح يقدم نفسه: استخدام شاشة Custom Browser للموافقة.

إذا كان لدى أي شخص وسيطات لصالح WebView بدلاً من علامة تبويب المتصفح المخصصة ، فسأكون ممتناً إذا كتبت عنها في التعليقات.

تأمين مخطط OAuth 2.0 المحمول

سنستخدم مخطط منح كود التفويض ، لأنه يسمح لنا بإضافة code_challenge بالإضافة إلى state والدفاع ضد هجوم اعتراض الشفرة و OAuth 2.0 CSRF.


أصل الصورة: https://tools.ietf.org/html/rfc8252#section-4.1

سيبدو طلب الوصول إلى التعليمات البرمجية (الخطوات 1-2) كما يلي:

 https://o2.mail.ru/code? redirect_uri=com.mail.cloud.app%3A%2F%2Foauth& state=927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24& code_challenge=ZjYxNzQ4ZjI4YjdkNWRmZjg4MWQ1N2FkZjQzNGVkODE1YTRhNjViNjJjMGY5MGJjNzdiOGEzMDU2ZjE3NGFiYw%3D%3D& code_challenge_method=S256& scope=email%2Cid& response_type=code& client_id=984a644ec3b56d32b0404777e1eb73390c 3D٪ 3D & https://o2.mail.ru/code? redirect_uri=com.mail.cloud.app%3A%2F%2Foauth& state=927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24& code_challenge=ZjYxNzQ4ZjI4YjdkNWRmZjg4MWQ1N2FkZjQzNGVkODE1YTRhNjViNjJjMGY5MGJjNzdiOGEzMDU2ZjE3NGFiYw%3D%3D& code_challenge_method=S256& scope=email%2Cid& response_type=code& client_id=984a644ec3b56d32b0404777e1eb73390c 

في الخطوة 3 ، يحصل المستعرض على استجابة من خلال إعادة التوجيه:

 com.mail.cloud.app://outh? code=b57b236c9bcd2a61fcd627b69ae2d7a6eb5bc13f2dc25311348ee08df43bc0c4& state=927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24 

في الخطوة 4 ، يفتح المستعرض Custom URI Scheme ويمرر الرمز CSRF إلى تطبيق عميل.
طلب access_token (الخطوة 5):

 https://o2.mail.ru/token? code_verifier=e61748f28b7d5daf881d571df434ed815a4a65b62c0f90bc77b8a3056f174abc& code=b57b236c9bcd2a61fcd627b69ae2d7a6eb5bc13f2dc25311348ee08df43bc0c4& client_id=984a644ec3b56d32b0404777e1eb73390c 

الخطوة الأخيرة تجلب استجابة مع access_token .

هذا المخطط آمن بشكل عام ، ولكن هناك بعض الحالات الخاصة عندما يكون OAuth 2.0 أكثر بساطة وأمانًا.

Android IPC

لدى Android آلية لنقل بيانات ثنائية الاتجاه بين العمليات: IPC (اتصال بين العمليات). IPC أفضل من نظام URI المخصص لسببين:

1. يمكن للتطبيق الذي يفتح قناة IPC أن يؤكد صحة التطبيق الذي يتم فتحه بشهادته. العكس صحيح أيضًا: يمكن للتطبيق المفتوح أن يؤكد صحة التطبيق الذي فتحه.
   
2. إذا أرسل المرسل طلبًا عبر قناة IPC ، فيمكنه تلقي إجابة عبر نفس القناة. جنبا إلى جنب مع الاختيار التبادلي (البند 1) ، فهذا يعني أنه لا يمكن لأي عملية خارجية اعتراض access_token .
   

لذلك ، يمكننا استخدام Implicit Grant لتبسيط نظام OAuth 2.0 المحمول. لا code_challenge state يعني أيضا أقل سطح الهجوم. يمكننا أيضًا تقليل مخاطر التطبيقات الضارة التي تعمل مثل عميل شرعي يحاول سرقة حسابات المستخدمين.

sdk للعملاء

إلى جانب تطبيق نظام OAuth 2.0 المحمول الآمن ، يجب على المزود تطوير SDK لعملائه. سيؤدي ذلك إلى تبسيط تطبيق OAuth 2.0 من جانب العميل وفي نفس الوقت تقليل عدد الأخطاء ونقاط الضعف.

الاستنتاجات

اسمحوا لي أن ألخص ذلك لك. فيما يلي قائمة التحقق (الأساسية) الخاصة بأمان OAuth 2.0 لموفري OAuth 2.0:

1. أساس قوي أمر بالغ الأهمية. في حالة تطبيق OAuth 2.0 المحمول ، فإن الأساس هو مخطط أو بروتوكول تم اختياره للتنفيذ. من السهل ارتكاب الأخطاء أثناء تنفيذ مخطط OAuth 2.0 الخاص بك . وقد اتخذت بالفعل بالفعل طرقات وتعلموا الدرس. لا حرج في التعلم من أخطائهم وجعل التنفيذ الآمن دفعة واحدة. يوصف مخطط OAuth 2.0 الأكثر أمانًا في كيفية القيام بذلك بشكل آمن ؟
   
2. يجب تخزين Access_token والبيانات الحساسة الأخرى في Keychain لنظام التشغيل iOS والتخزين الداخلي لنظام Android. تم تطوير هذه المخازن خصيصًا لذلك. يمكن استخدام موفر المحتوى في Android ، ولكن يجب تهيئته بشكل آمن.
   
3. Client_secret لا طائل منه ، إلا إذا تم تخزينه في الخلفية. لا تتخلى عن ذلك للعملاء العموميين.
   
4. لا تستخدم WebView لشاشة الموافقة ؛ استخدام علامة التبويب متصفح مخصص.
   
5. للدفاع ضد هجوم اعتراض الكود ، استخدم code_challenge .
   
6. للدفاع ضد OAuth 2.0 CSRF ، استخدم state .
   
7. استخدم HTTPS في كل مكان ، مع حظر الرجوع إلى HTTP. في ما يلي عرض توضيحي مدته 3 دقائق يوضح السبب (مع مثال من فضل الأخطاء).
   
8. اتبع معايير التشفير (اختيار الخوارزمية ، طول الرموز ، إلخ). يمكنك نسخ البيانات ومعرفة سبب تنفيذها بهذه الطريقة ، لكن لا تقم بتشفير التشفير الخاص بك.
   
9. يجب استخدام Code مرة واحدة فقط ، مع عمر افتراضي قصير.
   
10. من جانب عميل التطبيق ، تحقق مما تفتح لـ OAuth 2.0 ؛ ومن جانب موفر التطبيق ، تحقق من الذي يفتح لك لـ OAuth 2.0.
    
11. ضع في اعتبارك نقاط الضعف الشائعة في OAuth 2.0 . يعمل Mobile OAuth 2.0 على توسيع وتكملة النسخة الأصلية ، وبالتالي ، لا يزال redirect_uri يتحقق من وجود تطابق تام وتوصيات أخرى لـ OAuth 2.0 لا تزال سارية.
    
12. يجب عليك تزويد عملائك بـ SDK. سيكون لديهم عدد أقل من الأخطاء والثغرات وسيكون من الأسهل بالنسبة لهم تطبيق OAuth 2.0.
    

مزيد من القراءة

1. "نقاط ضعف تطبيق OAuth 2.0 للهاتف المحمول" https://www.youtube.com/watch؟v=vjCF_O6aZIg
   
2. بحث حالة سباق OAuth 2.0 https://hackerone.com/reports/55140
   
3. كل شيء تقريبًا حول OAuth 2.0 في مكان واحد https://oauth.net/2/
   
4. لماذا مفاتيح وأسرار OAuth API ليست آمنة في تطبيقات الجوال https://developer.okta.com/blog/2019/01/22/oauth-api-keys-arent-safe-in-mobile-apps
   
5. [RFC] OAuth 2.0 للتطبيقات الأصلية https://tools.ietf.org/html/rfc8252
   
6. [RFC] مفتاح إثبات لتبادل الرموز بواسطة عملاء OAuth العموميين https://tools.ietf.org/html/rfc7636
   
7. [RFC] نموذج تهديدات OAuth 2.0 واعتبارات الأمان https://tools.ietf.org/html/rfc6819
   
8. [RFC] بروتوكول تسجيل العميل الديناميكي OAuth 2.0 https://tools.ietf.org/html/rfc7591
   
9. Google OAuth 2.0 لتطبيقات الأجهزة المحمولة وسطح المكتب https://developers.google.com/identity/protocols/OAuth2InstalledApp
   

قروض

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