مرحبا بالجميع! أنا نيكيتا ستوبين ، أخصائي أمن المعلومات ، Mail.Ru Mail. منذ وقت ليس ببعيد ، أجريت بحثًا عن الثغرات الأمنية على OAuth 2.0 للجوال. لإنشاء مخطط OAuth 2.0 آمن للجوّال ، لا يكفي تنفيذ المعيار بشكله النقي والتحقق من redirect_uri. من الضروري مراعاة تفاصيل تطبيقات الهاتف المحمول وتطبيق آليات حماية إضافية.

في هذه المقالة ، أود أن أشاركك المعرفة حول الهجمات على OAuth 2.0 للجوال ، حول طرق الحماية والتطبيق الآمن لهذا البروتوكول. يتم تنفيذ جميع مكونات الحماية الضرورية ، والتي سأناقشها أدناه ، في أحدث SDK لعملاء Mobile Mail.Ru Mail.

طبيعة ووظيفة بروتوكول OAuth 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. العميل غير موثوق به.
2. يعتمد سلوك إعادة التوجيه من متصفح إلى تطبيق محمول على الإعدادات والتطبيقات التي قام المستخدم بتثبيتها.

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

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

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

يعرض الرسم البياني أدناه عملية OAuth 2.0 في الاتصال من خادم إلى خادم.


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

هناك 3 مراحل رئيسية لبروتوكول OAuth 2.0:

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

دعونا نفحص استلام الرمز بمزيد من التفصيل:

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

دعنا access_token الحصول على access_token بمزيد من التفاصيل:

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

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

لنر الآن كيف يبدو مخطط OAuth 2.0 على جهاز محمول بدون خلفية (تفاعل العميل بالخادم).


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

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

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

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

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

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

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

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

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

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

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

حسنا ، ما للهجوم؟

أدت مشكلات OAuth 2.0 للجوال أيضًا إلى ظهور هجمات محددة. دعونا نرى ما هم وكيف يعملون.

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

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


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

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

كيف تحمي نفسك؟ في بعض الحالات ، يمكن استخدام آليات التواصل بين العمليات ، وسوف نتحدث عنها أدناه. في الحالة العامة ، تحتاج إلى تطبيق نظام يسمى Proof Key لـ 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_verifier جديد.

Code_challenge_method هو اسم دالة التحويل ، وغالبًا SHA-256.

Code_challenge هو code_verifier تم code_challenge_method تحويل code_challenge_method في عنوان URL Base64 الآمن.

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

إذا كان جهاز المستخدم لا يدعم SHA-256 ، فسيُسمح بالرجوع إلى إصدار أقدم حتى يتم فقد تحويل 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. [الخطوة ج] يطلب العميل access_token ، مع إضافة access_token إلى code_verifier .
6. يستقبل المزود code_challenge من code_challenge الوارد ، ثم يتحقق منه مقابل code_challenge ، الذي يتذكره.
7. [الخطوة د] في حالة تطابق القيم ، يُصدر الموفر أمر access_token العميل.

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

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

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

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

OAuth 2.0 CSRF

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

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

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

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

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

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

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

متطلبات الرمز المميز لـ CSRF: لا يصل طولها إلى 256 بت على الأقل ، والتي يتم الحصول عليها من مصدر جيد للتسلسلات شبه العشوائية.

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

ادعاء أن البرامج الضارة عميل شرعي

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

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

للأسف ، إذا كانت آلية OAuth 2.0 تستخدم دفقًا من خلال متصفح ، فلا يمكنك الدفاع ضد هذا الهجوم.

هجمات أخرى

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

ماذا تفعل؟

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

جيد ، سيئ OAuth 2.0

لنبدأ بكيفية رفع شاشة الموافقة بشكل صحيح. على الأجهزة المحمولة ، هناك طريقتان لفتح صفحة ويب من تطبيق أصلي (أمثلة على التطبيقات الأصلية: Mail.Ru Mail ، VK ، Facebook).



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

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

WebView هو متصفح مستقل لتطبيق أصلي.

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

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

تخيل الآن: يضغط المستخدم على زر "تسجيل الدخول باستخدام ..." ويطلب WebView الخاص بالتطبيق الضار اسم المستخدم وكلمة المرور الخاصين به من مزود الخدمة.

الفشل مرة واحدة على جميع الجبهات:

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

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

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

مخطط OAuth 2.0 للجوّال الآمن

سنستخدم مخطط منح كود التفويض لأنه يسمح لنا بإضافة code_challenge وحماية code_challenge من هجوم اعتراض التعليمات البرمجية.


الصورة مأخوذة من 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&
anti_csrf=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&
anti_csrf=927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24

في الخطوة 4 ، يفتح المتصفح مخطط URI المخصص ويمرر code 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 .

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

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 والبيانات الحساسة الأخرى: ضمن iOS - في Keychain ، تحت Android - في التخزين الداخلي. تم تصميم هذه المستودعات خصيصا لهذه الأغراض. إذا لزم الأمر ، يمكنك استخدام Content Provider في Android ، ولكن يجب تكوينه بأمان.
3. يجب أن تكون Code لمرة واحدة ، مع فترة حياة قصيرة.
4. للحماية من اعتراض التعليمات البرمجية ، استخدم code_challenge .
5. للحماية من هجوم CSRF على تسجيل الدخول ، استخدم الرموز المميزة لـ CSRF.
6. لا تستخدم WebView لشاشة الموافقة ، استخدم علامة التبويب المخصصة للمتصفح.
7. Client_secret عديمة الفائدة إذا لم يتم تخزينها في الخلفية. لا تعطيه للعملاء العموميين.
8. استخدم HTTPS في كل مكان ، مع حظر الرجوع إلى إصدار HTTP.
9. اتبع توصيات التشفير (اختيار التشفير ، طول الرمز المميز ، إلخ) من المعايير . يمكنك نسخ البيانات ومعرفة سبب إجراء ذلك بهذه الطريقة ، ولكن لا يمكنك عمل التشفير .
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. [RFC] OAuth 2.0 للتطبيقات الأصلية https://tools.ietf.org/html/rfc8252
2. Google OAuth 2.0 لتطبيقات الجوال وسطح المكتب https://developers.google.com/identity/protocols/OAuth2InstalledApp
3. [RFC] مفتاح إثبات تبادل التعليمات البرمجية بواسطة عملاء OAuth العامين https://tools.ietf.org/html/rfc7636
4. حالة سباق OAuth 2.0 https://hackerone.com/reports/55140
5. [RFC] نموذج تهديد OAuth 2.0 واعتبارات الأمان https://tools.ietf.org/html/rfc6819
6. الهجمات على بروتوكول OAuth 2.0 العادي https://sakurity.com/oauth
7. [RFC] بروتوكول تسجيل العميل الديناميكي OAuth 2.0 https://tools.ietf.org/html/rfc7591

شكر وتقدير

شكرا لكل من ساعد في كتابة هذا المقال ، وخاصة سيرجي بيلوف ، وأندري سومين ، وأندري لابونتس ( isciurus ) وداريا ياكوفليفا.