API9:2019 إدارة الأصول بشكل خاطئ
| عوامل التهديد/ الاستغلال | نقاط الضعف | التأثير |
|---|---|---|
| خصائص API : قابلية الاستغلال 3 | الانتشار 3 : قابلية الاكتشاف 2 | قابلية التأثر التقني 2 : تأثر الأعمال |
| إصدارات واجهة برمجة التطبيقات API القديمة غالباً غير مرقعة وتعتبر طريق سهل لاختراق الأنظمة وتجاوز العديد من تقنيات الحماية الحديثة والتي تم تركيبها غالباً لحماية الأنظمة الحديثة و المتطورة من واجهة برمجة التطبيقات API. | وثائق الأنظمة والبرمجيات الغير محدثة تجعل من الصعب تتبع وإصلاح الثغرات. وكذلك عدم وجود جرد للأصول التقنية واستراتيجية للتخلص من الأصول القديمة يؤدي إلى وجود أنظمة تعمل بدون ترقيعات أمنية، وذلك قد يؤدي إلى تسريب للبيانات الحساسة. وكما انه من الشائع رصد واجهة برمجة التطبيقات API متاحة على الإنترنت مع كونها لا تستخدم بسبب المفاهيم الحديثة كالخدمات المصغرة (microservices) والتي تجعل من التطبيقات سهلة النشر ومستقلة على سبيل المثال (الحوسبة السحابية) | قد يتمكن المهاجمون من الوصول إلى بيانات حساسة، أو حتى اختراق الخادم من خلال استغلال احد الثغرات الغير مرقعة لخدمات واجهة برمجة التطبيقات API والتي تستخدم للاتصال بقاعدة البيانات. |
هل واجهة برمجة التطبيقات API معرضة لهذه الثغرة؟
قد تكون واجهة برمجة التطبيقات معرض لمثل هذه الثغرة في حالة :
- الغرض من استخدام واجهة برمجة التطبيقات غير واضح ولا توجد إجابات للأسئلة التالية:
- ما هي البيئة التي تعمل فيها واجهة برمجة التطبيقات (على سبيل المثال ، الإنتاج ، التدريج ، الاختبار ، التطوير)؟
- من المخول للوصول إلى الشبكة الخاصة بواجهة برمجة التطبيقات (على سبيل المثال ، عام ، داخلي ، شركاء)؟
- ما هو إصدار API المستخدم؟
- ماهي البيانات التي يتم جمعها بواسطة API؟ وهل هي بيانات شخصية؟
- ماهي آلية سير البيانات؟
- لا توجد وثائق معتمدة أو وثائق قديمة وغير محدثة.
- لا توجد خطة للتخلص من إصدارة واجهة برمجة التطبيقات القديمة.
- لا يوجد حصر للأصول أو أنه غير محدث.
- لا يوجد حصر للخدمات المتصلة بالأنظمة سواء كانت طرف أول أو طرف ثالث أو أنه غير محدث.
- إصدارات API قديمة وغير محدثة ولا تزال مستخدمة
أمثلة على سيناريوهات الهجوم:
السيناريو الأول:
بعد إعادة تصميم التطبيقات لإحدى الخدمات، لم يتم التخلص من الإصدارة القديمة والغير محمية من واجهة برمجة التطبيقات api.someservice.com/v1 والمتصلة بقاعدة البيانات. وبعد عمليات الفحص من قبل أحد المهاجمين توصل لعنوان واجهة برمجة التطبيقات الجديدة api.someservice.com/v2. باستبدال v2 بـ v1 تمكن المهاجم من الوصول لواجهة برمجة التطبيقات القديمة والغير محدثة والتي أدت إلى تسريب معلومات شخصية لأكثر من 100 مليون مستخدم.
السيناريو الثاني:
قامت منصة للتواصل الاجتماعي باستخدام آلية للحد من عدد محاولات تخمين كلمات المرور. آلية الأمان تلك لم يتم تطبيقها على الشفرة المصدرية الخاصة بواجهة برمجة التطبيقات API، بل قاموا بفصلها لكي تكون ما بين المستخدم وواجهة برمجة التطبيقات (www.socialnetwork.com). أحد الباحثين عثر على خادم لنسخة تجريبية (www.mbasic.beta.socialnetwork.com) والتي يستطيع من خلالها القيام بنفس المهام التي تقوم بها الواجهة المعتمدة بما في ذلك إعادة تعين كلمات المرور لكن بدون آلية الأمان التي تحد من عدد محاولات التخمين. و باستخدام النسخة التجريبية تمكن الباحث من إعادة تعيين كلمة السر بعد قيامة بعمليات بسيطة لتخمين كلمة المصادقة المكونة من 6 أرقام.
كيف أمنع هذه الثغرة؟
- جرد وحصر جميع الأجهزة الخاصة بواجهة برمجة التطبيقات وتوثيق الجوانب الهامة لك واحد منهم، والتركيز بشكل كبير على بيئة API (على سبيل المثال، الإنتاج ، التدريج ، الاختبار ، التطوير)، ومن هم المخولين بالوصول لهم من الشبكة (كشبكة الإنترنت أو الداخلية أو الشركاء).
- حصر جميع الخدمات المرتبطة بالأنظمة وتوثيق جوانبها المهمة كدورها في النظام ونوعية البيانات التي يتم تداولها من خلالها وحساسية تلك البيانات.
- توثيق جميع جوانب واجهة برمجة التطبيقات API مثل عمليات التحقق والأخطاء وإعادة التوجيه وسياسة حصر مشاركة الموارد (CORS)، بما في ذلك إعداداتها والطلبات والاستجابة لتلك الطلبات.
- إنشاء الوثائق بشكل آلي من خلال تبني المعايير المفتوحة. وتضمين عملية بناء الوثائق في خط الإنتاج الخاص باختبار ونشر التطبيقات.
- التأكد من أن الوثائق متاحة للأشخاص المصرح لهم فقط.
- التأكد من استخدام التدابير الوقائية اللازمة مثل جدران الحماية الخاصة بواجهة برمجة التطبيقات API لجميع إصدارات واجهة برمجة التطبيقات المتصلة بالأنترنت وليس فقط الإصدارة الحالية.
- تجنب استخدام بيانات حقيقية من بيئة التشغيل على البيئة التجريبية لواجهة برمجة التطبيقات، وفي حال توجب عليك استخدامها فيجب أن يتم تطبيق جميع المعايير الأمنية نفسها التي يتم تطبيقها على بيئة التشغيل.
- في حال كانت الإصدارات الحديثة من واجهة برمجة التطبيقات تحتوي على معايير أمان افضل، قم بإجراء تحليل للمخاطر لاتخاذ القرارات والإجراءات التي تخفف من مخاطر الإصدار القديم. على سبيل المثال إذا كان من الممكن إضافة تلك المعايير الأمنية الجديدة للإصدار السابق من دون التأثير على التوافقية مع الأنظمة الأخرى أو أنه لابد من التخلص من الإصدار القديم و إلزام جميع المستخدمين بالانتقال إلى الإصدار الحديث.