سلطت ثغرة أمنية اكتُشفت مؤخراً في واجهة برمجة التطبيقات (API) الخاصة بالهاتف المحمول التابعة لهيئة الخدمات الصحية الوطنية في المملكة المتحدة الضوء مجدداً على المخاطر المرتبطة بتلك الواجهات (APIs). وأفادت التقارير أن هذه الثغرة سمحت بالوصول غير المصرح به إلى بيانات المرضى الحساسة، مما أثار مخاوف جدية بشأن أمن تطبيقات الرعاية الصحية.
تُبرز هذه الحادثة مشكلة أوسع نطاقاً في أمن الهاتف المحمول. تُعدّ واجهات برمجة التطبيقات (APIs) أكثر أدوات الهجوم عرضة للخطر في التطبيقات الحديثة. فبينما تستثمر المؤسسات بكثافة في تأمين بنيتها التحتية في ال، فإنها غالباً ما تتجاهل أمن واجهات برمجة التطبيقات التي تربط بين تطبيقات الهاتف المحمول وقواعد البيانات الحساسة. وتُصبح واجهات برمجة التطبيقات (APIs)، عند تركها دون حماية، أبواباً مفتوحة للمهاجمين.
يشارك معكم روبودين هذه المقالة من securityboulevard والتي تتناول أسباب كون واجهات برمجة التطبيقات (APIs) للأجهزة المحمولة الحلقة الأضعف، وكيف يستغلها المهاجمون، وكيف يُمكن لنهج أمان الثقة الصفرية – بما في ذلك مصادقة تطبيقات الأجهزة المحمولة وأمن واجهات برمجة التطبيقات وقت التشغيل – أن يُخفف من هذه المخاطر. ونُسلّط الضوء على أفضل الممارسات التي ينبغي على المؤسسات اعتمادها لمنع وقوع حوادث مماثلة في المستقبل.
ثغرة واجهة برمجة التطبيقات في NHS
أدت الثغرة المبلغ عنها في نظام NHS إلى كشف بيانات المرضى من خلال واجهة برمجة تطبيقات ضعيفة الحماية. ورغم أن التفاصيل الدقيقة لا تزال غير واضحة، إلا أن هذه العيوب تنشأ عادةً بسبب:
- عدم وجود مصادقة سليمة – واجهات برمجة التطبيقات (APIs) التي لا تتحقق بدقة من طلبات التطبيقات تسمح للمهاجمين بالوصول إلى بيانات حساسة.
- مفاتيح API ثابتة مدمجة في التطبيقات – يخزن العديد من المطورين مفاتيح API داخل تطبيق الهاتف المحمول نفسه، مما يسهل على المهاجمين استخراجها.
- تثبيت الشهادات غير الكافي – بدون التحقق من صحة الشهادات بشكل صحيح، يمكن للمهاجمين تنفيذ هجمات الوسيط (MitM) لاعتراض حركة مرور API.
- غياب الحماية وقت التشغيل – يمكن للمهاجمين بسهولة إجراء هندسة عكسية للتطبيقات، وتعديل طلبات API، واستغلال ثغرات الواجهة الخلفية.
كيف يستغل المهاجمون هذه الثغرات؟ يقومون بفك تشفير التطبيق، وتحليل حركة مرور API، واستخدام نصوص برمجية آلية لمحاكاة الطلبات المشروعة. في أسوأ السيناريوهات، يحصلون على وصول إلى كم كبير من البيانات الحساسة، كما حدث في اختراق NHS.
أمن واجهات برمجة التطبيقات (APIs)
يركز أمن واجهات برمجة التطبيقات (APIs) التقليدي على مصادقة المستخدم (مثل كلمات المرور والمصادقة متعددة العوامل)، ولكن ذلك ليس كافياً. لا يحتاج المهاجمون إلى بيانات اعتماد المستخدم إذا تمكنوا من انتحال هوية تطبيق شرعي. وهنا يأتي دور مصادقة تطبيقات الهاتف المحمول وأمان التشغيل. فالمطلوب إذاً هو:
منع الوصول غير المصرح به
من أهم النتائج المستفادة من ثغرة واجهة برمجة تطبيقات NHS هو أنه لا يُسمح إلا لتطبيقات الهاتف المحمول الأصلية وغير المُعَدَّلة بالتواصل مع خدمات الواجهة الخلفية. تضمن حلول مصادقة تطبيقات الهاتف المحمول، مثل Approov، ما يلي:
- لا يمكن إلا لنسخ التطبيقات الشرعية التي تعمل على أجهزة غير مُعرَّضة للخطر الوصول إلى واجهات برمجة التطبيقات (APIs).
- تُمنع التطبيقات المُستنسخة أو المُعاد تجميعها أو المُعَدَّلة من إرسال طلبات واجهة برمجة التطبيقات (APIs).
- تُرفض البرامج الروبوتية والبرامج النصية التي تتظاهر بأنها مستخدمون حقيقيون عند بوابة واجهة برمجة التطبيقات (API).
يحقق Approov ذلك من خلال التحقق من تطبيق الهاتف المحمول أثناء التشغيل قبل منحه حق الوصول إلى واجهة برمجة التطبيقات (API)، مما يضمن عدم تمكن المهاجمين من استخدام مفاتيح API المسروقة أو التلاعب بالطلبات.
الحماية من سرقة مفاتيح API
من أكثر إخفاقات أمان API شيوعاً هو التشفير الثابت لمفاتيح API داخل تطبيقات الهاتف المحمول. يمكن للمهاجمين استخراج هذه المفاتيح من التطبيقات ،التي تمت هندستها عكسياً، واستخدامها لتقديم طلبات API غير مصرح بها. يمنع Approov ذلك من خلال تمكين إدارة مفاتيح API الديناميكية، حيث تكون مفاتيح API:
- لا تُخزن داخل التطبيق أبداً.
- تُسلم فقط أثناء التشغيل إلى نسخ تطبيق شرعية وموثقة.
- تُلغى فوراً إذا تم اكتشاف تشغيل تطبيق في بيئة مخترقة.
يضمن ذلك أنه حتى لو تمكن المهاجم من الوصول إلى شيفرة تطبيق الهاتف المحمول، فلن يتمكن من استخراج مفاتيح API صالحة للاستخدام.
الدفاع ضد هجمات الوسيط (MitM)
إن تشفير TLS غير كافٍ. يمكن للمهاجمين تثبيت شهادات الجذر أو استخدام أدوات مثل Frida وmitmproxy لاعتراض حركة مرور API. تعالج Approov هذه المشكلة بتطبيق تثبيت الشهادات الديناميكي، مما يضمن ما يلي:
- يتواصل تطبيق الهاتف المحمول فقط مع الخوادم الموثوقة.
- لا يمكن للمهاجمين حقن شهاداتهم الخاصة لاعتراض البيانات.
- تطبق تحديثات التثبيت ديناميكياً، متجنبين بذلك الوقوع في فخ انتهاء صلاحية الشهادة الذي قد يؤدي إلى تعطيل وظائف التطبيق.
التعلم من تجربة NHS
لا يُعد ثغرة واجهة برمجة تطبيقات NHS حالة معزولة. فقد عُثر على ثغرات مماثلة في واجهات برمجة التطبيقات في التطبيقات المالية والصحية والحكومية. ولمنع هذه الأنواع من الاختراقات، يجب على المؤسسات:
- تطبيق مصادقة تطبيقات الهاتف المحمول – التأكد من أن التطبيقات المُتحقق منها فقط هي التي يمكنها التواصل مع خدمات الواجهة الخلفية (Back end).
- التخلص من مفاتيح واجهة برمجة التطبيقات الثابتة – استخدام إدارة الأسرار الديناميكية لمنع استخراج المفاتيح.
- فرض تثبيت الشهادات – منع المهاجمين من اعتراض حركة مرور واجهة برمجة التطبيقات.
- مراقبة حركة مرور واجهة برمجة التطبيقات بحثاً عن أي شذوذ – استخدام أدوات أمان مدعومة بالذكاء الاصطناعي للكشف عن أنماط استخدام واجهة برمجة التطبيقات غير الطبيعية.
- اعتماد نموذج أمان الثقة الصفرية – لا تفترض أبداً أن طلب واجهة برمجة التطبيقات شرعي إلا بعد التحقق منه.
كلمة أخيرة
تُسلّط ثغرة واجهة برمجة تطبيقات NHS الضوء على مشكلة واسعة الانتشار في أمن الأجهزة المحمولة: تُركّز المؤسسات على حماية الواجهة الخلفية وتُهمل أمن واجهة برمجة التطبيقات. في الواقع، تُعدّ واجهات برمجة التطبيقات (APIs) بمثابة ساحة الهجوم الجديدة، ويتطلب تأمينها استراتيجية أمنية تُركّز على الأجهزة المحمولة.
من خلال الاستفادة من مصادقة تطبيقات الأجهزة المحمولة، وأمن واجهة برمجة التطبيقات، والإدارة الديناميكية للمفاتيح، يُمكن للمؤسسات ضمان بقاء واجهات برمجة التطبيقات (APIs) الخاصة بها غير مرئية وغير قابلة للوصول من قِبل المُهاجمين. ولا يقتصر أمن الأجهزة المحمولة على الجهاز فحسب، بل يشمل أيضاً ضمان الثقة عبر النظام البيئي الرقمي بأكمله. مع تطوّر المُهاجمين، يجب أن تتطور استراتيجيات الأمن أيضاً.
