ماسح أمان OpenAPI

حول المشروع

لا يمكن لكاشفات الأمان في تطبيقات الويب الحديثة اكتشاف مشكلات أمان التصريح بسهولة. بعض الأمثلة من Shopify، LINE، NordVPN. أحد الأسباب هو أن كاشفات الأمان تبحث بشكل أساسي عن SQLi و XSS و RCE بدلاً من البحث عن أخطاء أمان التصريح، وعادةً لا تملك الكاشفات معرفة بكيفية تصرف تطبيق الويب. لهذا السبب يتم اكتشاف معظم أخطاء التصريح حالياً يدوياً. تم إنشاء ماسح أمان OpenAPI للمساعدة في اكتشاف مشكلات أمان التصريح مع كل من الأتمتة والمراجعة اليدوية. إنه يتصرف كأداة اختبار وحدة خارجية للتأكد من أن كل شيء يتصرف بالطريقة التي ينبغي أن يكون عليها.

بني بـ

• Schemathesis

بدء الاستخدام

شاهد هذا الفيديو للمتابعة أو استمر في القراءة.

قم بعمل Fork أو استنساخ هذا المشروع واتبع التعليمات أدناه للبدء.

سيكون سير العمل لاستخدام هذا الماسح بالشكل التالي:

• تحضير ملف OpenAPI yaml لواجهة الـ API المستهدفة
• تحديد نقاط النهاية والمتغيرات المستهدفة لاستخدامها لاختبار الـ API
• توليد عدة مجموعات من بيانات الاعتماد من مستخدمين مختلفين لضمان تغطية مجموعة متنوعة من الحالات الحدودية أثناء إجراء اختبارات الـ API
• بعد التهيئة، بدء المشغل ويمكن العثور على نتيجة المسح في القطع الأثرية
• جدولة المشغل ليتم تشغيله بشكل دوري وتخصيص الطريقة التي ترغب في تلقي الإشعارات بها عندما يكون هناك تغيير في نتيجة المسح

المزايا

بالنسبة للمطورين، استخدام هذه الأداة سيضيف طبقة إضافية من الطمأنينة بأن الـ API يتصرف كما هو متوقع من الداخل والخارج. ويمكن تشغيل الماسح عند كل نشر للشفرة عن طريق تفعيل المسار https://docs.gitlab.com/ee/ci/triggers/.

بالنسبة لصائدي الثغرات المكافآت، استخدام هذه الأداة يمكن أن يضمن لك البقاء دائماً على اطلاع على الـ API المستهدفة، لأننا جميعاً نعرف، حتى نقطة نهاية معينة لم تكن ضعيفة سابقاً، قد تصبح ضعيفة في المستقبل لأسباب مختلفة. لذا من الأسهل أتمتة الجزء اليدوي من صيد الثغرات باستخدام هذه الأداة.

تحذير قبل الاستخدام

تأكد من أن لديك الإذن لمسح الـ API المستهدفة.

المتطلبات الأساسية

ستحتاج إلى ملف OpenAPI yaml لتطبيق الويب واستبداله بمحتوى api.yaml في المستودع.

الاستخدام

استبدل محتوى api.yaml بملف OpenAPI yaml الهدف، وانتقل إلى Settings -> CI/CD -> Expand Variables في مشروع GitLab وأدخل المتغيرات بالتنسيقات أدناه.

OPENAPI_CREDS

سيتم تمرير بيانات الاعتماد المقدمة هنا إلى استدعاءات الـ API بتنسيق رأس Authorization: Bearer. يوصى بإعداد رموز وصول لحسابين مستخدمين على الأقل بصلاحيات مختلفة، ويمكنك أيضاً إنشاء أكثر من رمز وصول واحد لكل حساب مستخدم لاختبار السلوك الصحيح لرموز الوصول ذات النطاقات المختلفة.

{
   "<user_a>":[
      {
         "scope":"<scope>",
         "access_token":"<value>",
         "name":"<name_of_access_token>"
      },
      {
         "scope":"<scope>",
         "access_token":"<value>",
         "name":"<name_of_access_token>"
      }
   ],
   "<user_b>":[
      {
         "scope":"<scope>",
         "access_token":"<value>",
         "name":"<name_of_access_token>"
      }
   ]
}

OPENAPI_ENDPOINTS

يجب أن تكون نقاط النهاية المقدمة هنا استدعاءات API قائمة على GET، ويمكنك أيضاً تضمين الاستعلام في جسم JSON. في المثال أدناه، نقطة النهاية هي /org/{orgs}/repos والاستعلام لها هو type=all. بالنسبة لنقطة النهاية /repos/{owner}/{repo}، لن يكون هناك استعلام.

{
   "/orgs/{org}/repos":{
      "type":"all"
   },
   "/repos/{owner}/{repo}":{
      
   }
}

OPENAPI_PATHS

يمكن توفير متغيرات المسار هنا، وسيقوم الماسح بتوليد جميع التركيبات من القيم في متغيرات المسار.

{
   "org":[
      "test-org"
   ],
   "owner":[
      "ngalongc",
      "reconless"
   ],
   "repo":[
      "public-repo",
      "private-repo"
   ]
}

في هذه الحالة، يتم توليد استدعاءات API المركبة التالية، وسيتم استدعاؤها جميعاً بواسطة مجموعة مختلفة من بيانات الاعتماد المقدمة في OPENAPI_CREDS.

/orgs/test-org/repos?type=all
/repos/ngalongc/public-repo
/repos/ngalongc/private-repo
/repos/reconless/public-repo
/repos/reconless/private-repo

PRIVATE_TOKEN

اذهب إلى https://gitlab.com/-/profile/personal_access_tokens وأنشئ رمز وصول api واستبدل القيمة هنا. يُستخدم رمز وصول GitLab هذا لتنزيل نتائج المسح من مشغل GitLab.

<YOU_GITLAB_API_ACCESS_TOKEN>

OPENAPI_BASE_URL

يجب أن تكون هذه هي قيمة عنوان url الأساسي لخادم API الخاص بك

https://example.com/api/v3

عرض توضيحي لتشغيل اختبارات صلاحية بسيطة على GitHub API

لقطة شاشة للإشعار المرسل عبر Slack عند اكتشاف تغييرات في API

لقطة شاشة لنتيجة المسح في القطع الأثرية

تقرير عينة: https://ngalog-gitlab.gitlab.io/-/openapi_security_scanner/-/jobs/966841401/artifacts/sample.html

القيود

• يمكنه اختبار نقاط النهاية القائمة على GET فقط
• بالنسبة لبعض نقاط نهاية API مثل /users/{user_id}/activities، تختلف الاستجابات في كل مرة يتم استدعاؤها، لذا فإن اكتشاف التغييرات في هذا النوع من API ليس ذا معنى

المساهمة

المساهمات هي ما يجعل مجتمع المصادر المفتوحة مكاناً رائعاً للتعلم والإلهام والإبداع. أي مساهمات تقدمها موضع تقدير كبير.

1. قم بعمل Fork للمشروع
2. قم بإنشاء فرع الميزة الخاص بك (git checkout -b feature/AmazingFeature)
3. قم بإجراء التغييرات الخاصة بك (git commit -m 'Add some AmazingFeature')
4. ادفع إلى الفرع (git push origin feature/AmazingFeature)
5. افتح طلب دمج (Merge Request)

الترخيص

موزع بموجب رخصة MIT. انظر LICENSE لمزيد من المعلومات.

الاتصال

Ron Chan - @ngalongc

رابط المشروع: https://gitlab.com/ngalog-gitlab/openapi_security_scanner