مقدمة
في مايو 2017، شهدت Google واحدة من أخطر الهجمات المرتبطة بواجهات OAuth API، وهو الهجوم المعروف عالميًا باسم Google Docs OAuth Phishing Attack. اعتمد المهاجمون على تطبيق مزيف يستغل نظام السماح (Authorization) بدلًا من سرقة كلمات المرور، مما جعل الهجوم ينتشر بسرعة هائلة حول العالم.
بداية الهجوم
تلقّى آلاف المستخدمين رسالة تبدو طبيعية للغاية: “تمت مشاركتك في مستند Google Docs”. عند الضغط على الرابط، يُطلب من المستخدم منح صلاحيات كاملة لتطبيق يحمل اسم “Google Docs”، لكنه في الحقيقة تطبيق طرف ثالث مزيف تمت برمجته خصيصًا للهجوم.
كيف استغل المهاجمون OAuth API؟
اعتمد الهجوم على نقطة ضعف غير تقنية: ثقة المستخدم في شاشة أذونات OAuth. فبدل طلب كلمة المرور، طلب التطبيق المزيف صلاحيات الوصول إلى:
- البريد الإلكتروني (Gmail)
- قائمة جهات الاتصال
- الوصول إلى المعلومات الشخصية في الحساب
وبمجرد الضغط على “سماح / Allow”، أصبح للمهاجم وصول قانوني بالكامل إلى الحساب دون الحاجة لأي كلمة مرور.
تسلسل الهجوم
- تسجيل تطبيق مزيف في منصة مطوري Google.
- تسمية التطبيق بنفس اسم “Google Docs” لجعل الأمر مألوفًا للمستخدم.
- إرسال رسائل مشاركة وهمية بملف Google Docs.
- منح المستخدمين صلاحيات واسعة عبر OAuth.
- التوسع السريع عبر وصول التطبيق لجهات الاتصال.
سبب نجاح الهجوم
- واجهة OAuth موثوقة بصريًا لدى المستخدمين.
- اسم التطبيق مطابق للتطبيق الرسمي.
- عدم وجود تنبيه يميز بين تطبيق Google الحقيقي والتطبيقات الخارجية وقتها.
- الانتشار عبر جهات الاتصال أعطى الهجوم مصداقية أكبر.
النتيجة
انتشر الهجوم عالميًا خلال دقائق قليلة، مستهدفًا آلاف الحسابات الشخصية وحسابات مؤسساتية. اكتشفت Google الهجوم سريعًا، فقامت بإلغاء صلاحيات التطبيق المزيف وحذفه وإرسال تنبيهات أمنية للمستخدمين. يُعد هذا الهجوم أبرز مثال على أن واجهات API يمكن أن تتحول إلى نقطة اختراق خطيرة إذا لم تُستخدم بعناية.
الدروس المستفادة
- ضرورة فحص هوية التطبيقات قبل منحها صلاحيات OAuth.
- التدريب على فهم شاشة الأذونات وتفسيرها.
- استخدام سياسات تقييد الصلاحيات في المؤسسات.
- عدم الوثوق بأي تطبيق حتى لو بدا أنه من Google.