كل ما pull request إن إضافة أو تغيير نقطة نهاية يُغيّر من نطاق تعرض واجهة برمجة التطبيقات (API) للهجمات. لا تكتشف معظم أدوات أمان واجهات برمجة التطبيقات هذه المشكلة إلا بعد تفعيل نقطة النهاية واستقبالها للبيانات. حينها، لا يقتصر الحل على تغيير سطر واحد في مراجعة الكود، بل يتطلب استجابة شاملة للحادث.
أمان واجهة برمجة التطبيقات هو ممارسة اكتشاف ومعالجة المخاطر في كيفية كشف التطبيق لنقاط النهاية الخاصة به: من يمكنه استدعاؤها، وما هي البيانات التي تعيدها، وما إذا كانت تفعل ما تقوله الوثائق.
معظم الأدوات المصممة لحل هذه المشكلة تختبر واجهة برمجة التطبيقات (API) أثناء التشغيل، من الخارج، بنفس الطريقة التي يستخدمها المهاجم. هذا الأسلوب فعال، لكنه لا يعمل إلا بعد نشر واجهة برمجة التطبيقات. زيجيني يسلك المسار السابق: فهو يقرأ شفرة المصدر ومواصفات واجهة برمجة التطبيقات الخاصة بك قبل أن يصل أي طلب إلى نقطة النهاية.
أربع طرق لاختبار واجهة برمجة التطبيقات، وما الذي تجيب عنه كل طريقة؟
معظم البرامج الناضجة تشغل أكثر من واحد من هذه البرامج:
- اختبار ثابت يقوم هذا التحليل بتحليل شفرة المصدر ومواصفات واجهة برمجة التطبيقات قبل النشر، ويجيب على سؤال "ما الذي كشفناه للتو؟". هذا هو النهج الذي تركز عليه هذه المقالة.
- الاختبار الديناميكي (DAST) يرسل بيانات حقيقية إلى واجهة برمجة تطبيقات قيد التشغيل ويراقب كيفية استجابتها. ويجيب على سؤال "ما الذي يمكن الوصول إليه واستغلاله فعليًا في الوقت الحالي؟"
- التضبيب يُرسل النظام مدخلات غير صحيحة أو غير متوقعة إلى نقاط النهاية للكشف عن الأعطال وحالات الفشل الاستثنائية. ويجيب على سؤال "ما الذي يتعطل عند إدخال بيانات لم نتوقعها؟"
- اختبار الاختراق اليدوي يُضيف هذا النظام حكماً بشرياً لاكتشاف الثغرات المنطقية التي تغفل عنها الأدوات الآلية، ويجيب على سؤال: "ما الذي قد يربطه مهاجم ذكي ببعضه؟"
لا يغني أيٌّ من هذه عن الآخر. فهي تجيب على أسئلة مختلفة في مراحل مختلفة من دورة حياة البرنامج، والفجوة التي تعاني منها معظم البرامج هي الأولى.
لماذا تكتشف معظم أدوات أمان واجهات برمجة التطبيقات المخاطر متأخرًا جدًا؟
يُرسل اختبار أمان واجهة برمجة التطبيقات أثناء التشغيل بيانات إلى تطبيق حيّ ويراقب استجابته. إنها طبقة ضرورية ومشروعة. وهي أيضاً، بحكم طبيعتها، مؤشر متأخر: يجب أن تكون نقطة النهاية موجودة، ومنشورة، وقابلة للوصول قبل أن يتمكن الماسح الضوئي أثناء التشغيل من تحديد أي شيء عنها. أي شيء يجده الماسح كان مكشوفاً بالفعل طوال مدة تشغيل الفحص.
ثمة ثغرة ثانية وراء مشكلة التوقيت هذه. لا تستطيع أدوات وقت التشغيل اختبار إلا ما هو موجود بالفعل. فإذا لم يتم توثيق نقطة نهاية، أو إذا أصبحت مواصفات OpenAPI قديمة بمجرد إضافة مسار جديد، فلن يتمكن الماسح الضوئي لوقت التشغيل من معرفة وجودها. فهو يختبر الخريطة، لا الموقع الفعلي.
يُسدّ اختبار أمان واجهة برمجة التطبيقات الثابتة كلا الثغرتين عن طريق نقل الفحص إلى المكان الذي تُعرّف فيه نقطة النهاية: أي إلى التعليمات البرمجية ومواصفات واجهة برمجة التطبيقات، قبل النشر. pull request الذي يُدخل نقطة نهاية هو pull request وهذا ما يكشف عن مخاطره.
ما الذي يعنيه أمان واجهة برمجة التطبيقات الثابتة فعليًا
يقوم Xygeni ببناء مخزون واجهة برمجة التطبيقات (API) الخاص بك من مصدرين: شفرة المصدر لتطبيقك ومواصفات واجهة برمجة التطبيقات الخاصة بك، بما في ذلك OpenAPI و Swagger.
يُظهر جرد المواصفات فقط نقاط النهاية التي تم توثيقها. أما جرد التعليمات البرمجية فقط فيُظهر ما هو موجود، ولكن ليس بالضرورة كيفية استخدامه. قراءة كلا النوعين من الجرد تُعطيك الصورة الكاملة: نقاط النهاية التي وثّقتها فرقك، وتلك التي لم يوثّقها أحد.
هذا المخزون هو الأساس الذي يبني عليه كل شيء آخر:
- إجمالي واجهات برمجة التطبيقات المكتشفة، والأصول المعرضة للخطر مقارنةً بالخط الأساسي
- نقاط النهاية مصنفة حسب طريقة HTTP
- المشكلات مصنفة حسب الخدمة
- كل نقطة نهاية مع طريقتها ومسارها وخدمتها ووحدتها وحالة المصادقة ودرجة المخاطر الخاصة بها
يستطيع قادة الهندسة لديك رؤية شكل واجهة برمجة التطبيقات الخاصة بك دون الحاجة إلى فتح تذكرة واحدة.
تم بناء كل نقطة نهاية وجدتها Xygeni، مع طريقتها وحالة المصادقة ودرجة المخاطر الخاصة بها، من التعليمات البرمجية والمواصفات معًا.
Production note قم باقتصاص لوحة الفرز الآلي من أي لقطة شاشة لأمان واجهة برمجة التطبيقات.
تمت مطابقتها مع قائمة OWASP لأهم 10 مخاطر أمنية في واجهات برمجة التطبيقات
تؤكد النتائج على الإطار الذي تستخدمه فرق الأمن ومدققو الحسابات لديك بالفعل. يكشف Xygeni عن المخاطر عبر معيار OWASP لأمن واجهات برمجة التطبيقات (API). أفضل 10 (2023):
هناك فئة واحدة غائبة عمدًا. تتطلب فئة API6، التي تتيح الوصول غير المقيد إلى تدفقات الأعمال الحساسة، فهمًا لما يُفترض أن تسمح به عملية الأعمال، ولا يمكن لأي محلل ثابت اكتشاف ذلك بشكل موثوق. أي بائع يدّعي خلاف ذلك إنما يبيعك مجرد خيار شكلي. هذا الخيار يبقى ضمن اختصاصك في نمذجة التهديدات واختبار الاختراق.
ليست كل النتائج متساوية: حساسية البيانات والتركيبات السامة
إنّ قائمة النتائج المُسطّحة تُعامل نقطة نهاية فحص الصحة غير المُصادق عليها بنفس معاملة نقطة نهاية غير مُصادق عليها تُعيد سجلات العملاء. هاتان ليستا نفس المشكلة، ونموذج تحديد الأولويات الذي يُقيّمهما بنفس الطريقة يُدرّب فرق العمل على تجاهل القائمة.
يقوم Xygeni بتصنيف البيانات التي تتعامل معها كل نقطة نهاية، مع وضع علامات على PII و PCI و PHI في معلمات الطلب وفي الاستجابات، ويربط ذلك بحالة مصادقة نقطة النهاية.
كما يربط النظام بين النتائج التي تظهر على نفس نقطة النهاية، ويرفع مستوى الخطورة عند تراكمها. يُعد تسريب معلومات التعريف الشخصية في الاستجابة اكتشافًا خطيرًا بحد ذاته. أما التسريب نفسه على نقطة نهاية لا تتطلب مصادقة فهو بالغ الأهمية، ولذلك يُقيّم النظام هذا التسريب على هذا الأساس بدلًا من ترك الاتصال ليكتشفه شخص ما يدويًا.
نقاط النهاية الزومبي واليتيمة: الانحراف بين الكود والمواصفات
لأن برنامج Xygeni يقرأ الكود الخاص بك ومواصفات واجهة برمجة التطبيقات (API) جنبًا إلى جنب، فإنه يحدد مواطن الاختلاف بينهما. ويظهر هذا الاختلاف في ثلاثة أنماط واضحة:
- نقاط نهاية غير موثقة. إنها موجودة في الكود ولم تتم إضافتها إلى المواصفات.
- نقاط نهاية الزومبي. تم تصنيفها على أنها مهملة أو متقاعدة، ولا يزال من الممكن الوصول إليها.
- نقاط النهاية اليتيمة. لا أحد من أعضاء الفريق الحالي يمتلكها.
لا يظهر أي من هذه العناصر في قائمة الجرد الخاصة بالمواصفات فقط، لأن المواصفات هي بالضبط ما ينقصها.
دليل يمكنك اتخاذ إجراء بناءً عليه، وليس مجرد استدعاء للتحقيق.
تشير كل نتيجة إلى المعالج المسؤول تحديدًا: الملف، والفئة، والطريقة، والسطر المحدد الذي تسبب في الثغرة، مع عرض الكود المخالف بجانبه. ويُرفق بكل نتيجة مستوى خطورتها، وتصنيفها ضمن قائمة OWASP لأهم عشرة مخاطر أمنية في واجهات برمجة التطبيقات، ومؤشر CWE الخاص بها، وحالة مصادقة نقطة النهاية، وتصنيف حساسية البيانات المعنية.
إن اكتشافًا يُشير فقط إلى نقطة نهاية يُجبر المطور على البحث في قاعدة التعليمات البرمجية قبل أن يتمكن من البدء في إصلاح أي شيء. أما اكتشافًا يُشير إلى السطر البرمجي فيُمكّنه من الوصول إلى الحل فورًا.
يتم تصدير النتائج بصيغ JSON وCSV وMarkdown وSARIF 2.1.0، بحيث يتم تحميلها في tالأدوات التي تعمل بها فرقك بالفعل.
المعالج، والسطر، والرمز البرمجي الذي تسبب في هذا الكشف. لا داعي للتحقيق في هذه المشكلة.
لماذا يقتصر هذا على منصة واحدة، وليس على جهاز ألعاب آخر؟
تتولى شركة Xygeni إدارة أمان واجهة برمجة التطبيقات (API) إلى جانب SAST, SCA, أسرار الأمن, IaC و دست داخل منصة واحدة، مرتبطة من خلال ASPMبدلاً من شحنها كأداة منفصلة بميزاتها الخاصة login وتراكم أعمالها الخاصة.
هذا الأمر مهم لأن نتائج التحليل الثابت ونتائج التحليل أثناء التشغيل تجيب على أسئلة مختلفة حول نفس نقطة النهاية، وتكون أكثر فائدة عند استخدامها معًا. يُخبرك التحليل الثابت أن نقطة النهاية محفوفة بالمخاطر قبل إطلاقها. بينما يؤكد تحليل DAST ما يمكن الوصول إليه واستغلاله فعليًا بمجرد تشغيلها.
بتقسيم ذلك على منصتين، يصبح الخطر المرتبط قائمتين متراكمتين منفصلتين. لا أحد يوفق بينهما، ونقطة النهاية غير الموثقة وغير المصادق عليها لا تظهر في أي من القائمتين.
اطلع على نطاق هجوم واجهة برمجة التطبيقات (API) الحقيقية لديك. تتوفر خدمة أمان واجهة برمجة التطبيقات (API) كـ Enterprise إضافة إلى منصة Xygeni، ويتم إجراء فحص على مستودعاتك الخاصة داخل بنيتك التحتية الخاصة.
الأسئلة الشائعة
هل يمكنه تحديد نقاط النهاية التي تتعامل مع البيانات الحساسة؟
نعم. يقوم Xygeni بتحديد PII و PCI و PHI في معلمات نقطة النهاية والاستجابات، ويستخدم هذا التصنيف لترتيب النتائج حسب التعرض الحقيقي.
هل يمكن تشغيله على كل pull request?
نعم. يقوم المسح التدريجي بتحليل نقاط النهاية التي تغيرت فقط، ويمكن للبيان الذي ينتجه أن يركز عملية مسح DAST اللاحقة على نقاط النهاية نفسها، لذلك يظل الاختبار الثابت واختبار وقت التشغيل متوافقين مع ما تم نقله بالفعل.
هل يخرج الكود الخاص بي من بيئتي؟
لا. تتم عمليات الفحص في بنيتك التحتية الخاصة. يتم تحميل النتائج فقط، وهي محمية أثناء النقل وأثناء التخزين.
كيف أحصل على ميزة أمان واجهة برمجة التطبيقات (API)؟
تتوفر خدمة أمان واجهة برمجة التطبيقات (API) كـ Enterprise إضافة. اطلب نموذجًا أوليًا وسيتم تحديد نطاقه معك.
