أداة الهجوم التلقائي على واجهات برمجة التطبيقات (API)

أداة هجوم واجهات برمجة التطبيقات القابلة للتخصيص من Imperva تأخذ مواصفات API كمدخل، وتُولد وتُنفذ هجمات مبنية عليها كمخرج.

الأداة قادرة على تحليل مواصفات API وإنشاء سيناريوهات هجوم بالتحوير (fuzzing) بناءً على ما هو مُحدد في مواصفات API. يتم حقن كل نقطة نهاية (endpoint) بقيم مُولّدة بذكاء داخل الحدود المحددة في المواصفات، وخارجها، مع إرسال الطلبات المناسبة والإبلاغ عن نجاحها أو فشلها بطريقة مفصّلة. يمكنك أيضًا توسيعها لتشغيل نواقل هجوم أمنية مختلفة، مثل الوصول غير القانوني إلى الموارد، XSS، SQLi، و RFI، التي تستهدف نقاط النهاية الموجودة، أو حتى غير الموجودة. لا حاجة لأي تدخل بشري. ما عليك سوى تشغيل الأداة والحصول على النتائج.

يمكن توسيع الأداة بسهولة لتتكيف مع الاحتياجات المختلفة، مثل المطور الذي يريد اختبار واجهة برمجة التطبيقات الخاصة به، أو مؤسسة تريد تشغيل عمليات مسح أمنية منتظمة للثغرات أو للأمان الإيجابي (positive security) على واجهة برمجة التطبيقات العامة الخاصة بها. تم بناؤها مع مراعاة التكامل المستمر/النشر المستمر (CI/CD).

المتطلبات

• Java 8 أو أحدث
• Gradle

التشغيل

• قم بتحميل الكود من GitHub وشغّل ./gradlew build أو gradlew.bat build على Windows
• يمكنك العثور على ملف jar القابل للتنفيذ داخل مجلد build/libs
• شغّل 'java -jar imperva-api-attack-tool.jar' لرؤية قائمة المساعدة

إنشاء ملف تنفيذي لنظام Linux

• انسخ ملف runnable.sh من مجلد src/main/resources إلى نفس الدليل الذي يوجد به ملف jar.
• الآن شغّل: cat runnable.sh imperva-api-attack-tool.jar > api-attack.sh && chmod +x api-attack.sh
• يمكنك استخدام ملف api-attack.sh كملف تنفيذي عادي

الاستخدام

المعاملات الإلزامية:

-f, --specFile=مسار_ملف_المواصفات

ملف مواصفات API (swagger 2.0) للتشغيل عليه. بصيغة JSON/YAML. للحصول على نتائج أفضل، تأكد من أن الاستجابات مُعرّفة بشكل جيد لكل نقطة نهاية.

-n, --hostName=اسم_المضيف

اسم المضيف للاتصال به. يمكن أن يكون أيضًا عنوان IP

-s, --hostScheme=مخطط_المضيف

سيتم الاتصال بالمضيف باستخدام هذا المخطط؛ مثال: https أو http

المعاملات الاختيارية:

-p, --hostPort=منفذ_المضيف

المنفذ الذي يستمع عليه المضيف لاستدعاءات API، الافتراضي: 443

-ph, --proxyHost=مضيف_الوكيل

حدد مضيف الوكيل لإرسال الطلبات عبر وكيل

-pp, --proxyPort=منفذ_الوكيل

منفذ الوكيل، الافتراضي: 80

-rcn, --addNegativeRC=رمز_الاستجابة[,رمز_الاستجابة...]

رموز استجابة إضافية سيتم قبولها في الهجمات السلبية (مثل هجمات القيم الخاطئة). يتم دعم القيم المتعددة، مفصولة بفواصل

-rcp, --addPositiveRC=رمز_الاستجابة[,رمز_الاستجابة...]

رموز استجابة إضافية سيتم قبولها في الفحوصات الإيجابية (هجمات القيم المشروعة). يتم دعم القيم المتعددة، مفصولة بفواصل

 

سيناريوهات الاستخدام النموذجية:

• ترغب في التحقق مما إذا كانت واجهة برمجة التطبيقات الخاصة بك محمية بواسطة حل أمان API.

  مثال تشغيل: api-attack.sh -f swaggerPetStore.json -n myapisite.com -s http -rcn=403

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

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

  مثال تشغيل: api-attack.sh -f swaggerPetStore.json -n myapisite.com -s http -ph 127.0.0.1 -pp=4010 -rcn=403 -rcp=404

  هذه المرة أضفنا رمز الحالة 404 إلى السيناريوهات الإيجابية. بحيث عندما لا يتم حظر سيناريو، لن نقوم بالإبلاغ عن فشل، بل نقبل الاستجابة المشروعة 404 (المورد غير موجود).

• ترغب في التحقق مما إذا كانت واجهة برمجة التطبيقات الخاصة بك تتعامل مع جميع المدخلات بشكل صحيح. علاوة على ذلك، ترغب في تشغيلها بشكل ليلي، أو حتى بعد كل مرة يدفع فيها مطور كودًا جديدًا إلى المشروع.

  مثال تشغيل: api-attack.sh -f myapi_swagger.yaml -n staging.myorg.com -s https

  هذه المرة نقوم بالتشغيل دون أي استثناءات. يجب أن يعلن ملف مواصفات API عن رموز الاستجابة الخاصة به بدقة. ستقبل الأداة فقط تلك الرموز كمشروعة، وسيتم إخفاق الفحوصات بخلاف ذلك. انظر أدناه لمزيد من التفاصيل حول شروط إخفاق الفحوصات. شغّل الأمر أعلاه في وظيفة Jenkins (أو أي برنامج CI/CD آخر تفضله)، والتي سيتم تشغيلها بواسطة مهمة cron، أو نشاط دفع كود إلى المستودع. تأكد من تثبيت إضافة TestNG، والتي يجب أن تقوم بتحليل النتائج المكتوبة في build/testng-results، للحصول على رؤية أفضل في سيناريو CI/CD.

• ترغب في التحقق مما إذا كانت واجهة برمجة التطبيقات هذه قد تكون معرضة لمحاولات التحوير. ما عليك سوى تشغيل الأداة والتحقق من حالات الفشل المبلغ عنها.

  مثال تشغيل: api-attack.sh -f publiclyAvailableSwaggerOfAPI.yaml -n api.corporate.com -s https

• ترغب في التحقق من تنفيذ واجهة برمجة التطبيقات الخاصة بك بشكل صحيح على جانب الخادم، أو أن تعريفها يتوافق مع تنفيذ الخادم.

  مثال تشغيل: api-attack.sh -f publiclyAvailableSwaggerOfAPI.yaml -n api.corporate.com -s https

شروط إخفاق الفحوصات

• تتحقق الأداة من تطابق رمز استجابة الطلب المُولّد مع رموز الاستجابة المُعلنة في السواغر (swagger). ومع ذلك،
• الفحوصات الإيجابية: إذا كان هناك خطأ واضح (الرمز 5xx)، فسيظل الفحص يفشل، حتى لو لم يكن رمز الاستجابة هذا مُعرّفًا في المواصفات، ولكن ليس إذا قدمت تجاوزًا (override).
• الفحوصات السلبية: إذا لم تكن الاستجابة خطأ مشروعًا (1xx، 2xx، 5xx)، نفشل الفحص ما لم تقدم تجاوزًا. إذا لم يكن رمز الخطأ المشروع موجودًا في المواصفات، سيفشل الفحص أيضًا.
• يمكنك استخدام تعريف 'default' في قسم الاستجابة في السواغر، لكن هذا غير موصى به. حدد دائمًا إجاباتك المشروعة بدقة.

شروط إخفاق الفحوصات

• تتحقق الأداة من تطابق رمز استجابة الطلب المُولّد مع رموز الاستجابة المُعلنة في السواغر. ومع ذلك،
• الفحوصات الإيجابية: إذا كان هناك خطأ واضح (الرمز 5xx)، فسيظل الفحص يفشل، حتى لو لم يكن رمز الاستجابة هذا مُعرّفًا في المواصفات، ولكن ليس إذا قدمت تجاوزًا.
• الفحوصات السلبية: إذا لم تكن الاستجابة خطأ مشروعًا (1xx، 2xx، 5xx)، نفشل الفحص. ما لم تقدم تجاوزًا. إذا لم يكن رمز الخطأ المشروع موجودًا في المواصفات، سيفشل الفحص أيضًا.
• يمكنك استخدام تعريف 'default' في قسم الاستجابة في السواغر، لكن هذا غير موصى به. حدد دائمًا إجاباتك المشروعة بدقة.

المخرجات المتوقعة:

• تستخدم الأداة إطار إعداد تقارير testng، لذا يمكن استخدام أي إضافة تتعامل مع تشغيل testng هنا. لاحظ فقط أن النتائج تُكتب تحت مجلد build/testng-results. يمكن تغيير ذلك بالطبع.
• تُولد الأداة طلبات وفقًا لمجموعات الفحص الخاصة بها، وكل طلب يفحص شيئًا محددًا. لذا سيعرض كل فحص جميع التفاصيل ذات الصلة في مخرجات سطر الأوامر، بالإضافة إلى ما يتم فحصه، وماهية الاستجابة، وما إذا كانت كما هو متوقع أم لا.
• سيتم تخزين أي طلبات خاطئة في مجلد bad_requests، حتى تتمكن من تحليلها لاحقًا (على سبيل المثال، إذا كان هذا يعمل على خادم CI/CD، وليس لديك وصول فوري إلى الجهاز).
• في النهاية، سيتم تزويدك بملخص.

مثال على فحص سلبي فشل:

***** Testing API Endpoint *****
***** Test ID: 1575128763286-74212
Testing: Bad Property: /username (STRING), value: {, URL encoded: %7B
--> Url: /user/{
--> Method: GET
--> Headers: []
----------**----------
Request was: GET /user/{ [Accept: application/json], Response status code: 200(UNEXPECTED)
Response (non parsed):
{"id":0,"username":"string","firstName":"string","lastName":"string","email":"string","password":"string","phone":"string","userStatus":0}

لماذا فشل الفحص؟ حصل الطلب على 200، على الرغم من أنه لم يحتوي على عنوان URL قانوني