أداة الهجوم التلقائي على واجهات برمجة التطبيقات (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، أو نشاط دفع كود إلى المستودع. تأكد من تثبيت إضافة ، والتي يجب أن تقوم بتحليل النتائج المكتوبة في ، للحصول على رؤية أفضل في سيناريو CI/CD.

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

• تتحقق الأداة من تطابق رمز استجابة الطلب المُولّد مع رموز الاستجابة المُعلنة في السواغر (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 قانوني

مثال آخر:

***** Testing API Endpoint *****
***** Test ID: 1575128763286-25078
Testing: Bad Property: /body/quantity (INTEGER), value: 0.4188493, URL encoded: 0.4188493
--> Url: /store/order
--> Method: POST
--> Headers: []
--> Body: {"petId":-2511515111206893939,"quantity":0.4188493,"id":698757161286106823,"shipDate":"�s","complete":"true","status":"approved"}
----------**----------
Request was: POST /store/order [Accept: application/json], Response status code: 200(UNEXPECTED)
Response (non parsed):
{"id":0,"petId":0,"quantity":0,"shipDate":"2019-11-30T15:46:03Z","status":"placed","complete":false}

كان من المتوقع أن يستقبل الخادم عددًا صحيحًا (integer)، لكنه قبل قيمة عشرية (double). قد يكون هذا مكانًا جيدًا لمحاولة استغلال تجاوز سعة المخزن المؤقت (buffer overflow) في الخادم.

مثال على فحص ناجح:

***** Testing API Endpoint *****
***** Test ID: 1575128763137-43035
Testing: /user/{username}
--> Url: /user/%E68E97EDB4Oq-(!BbG,Y$p'A-KW%65f9FA6jt5vvDz-cW.QGsLS+AA~RIHC3wgy25lDJsGzcT.;kJ+(
--> Method: GET
--> Headers: []
----------**----------
Request was: GET /user/%E68E97EDB4Oq-(!BbG,Y$p'A-KW%65f9FA6jt5vvDz-cW.QGsLS+AA~RIHC3wgy25lDJsGzcT.;kJ+( [Accept: application/json], Response status code: 404
Response (non parsed):
{"statusCode":404,"error":"Not Found","message":"Not Found"}

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

سيناريوهات الفحص المدعومة

سنستخدم مصطلح نقطة النهاية هنا، كمجموعة عنوان URL لنقطة النهاية وطريقة الطلب (Method).

السيناريوهات الإيجابية

• لكل نقطة نهاية، يُنشئ طلبًا بقيم مُولّدة لجميع معلماتها. يتم إنشاؤها عشوائيًا، لكنها تلتزم بالقواعد المحددة في مواصفات API.
• لكل نقطة نهاية، يُنشئ طلبًا مع المعلمات الإلزامية فقط، بقيم مولدة كما هو موضح أعلاه.

السيناريوهات السلبية

• لكل نقطة نهاية، يُنشئ طلبات متعددة، كل منها يتحقق من معامل مختلف. تقوم الأداة بذلك عن طريق حقن قيمة إدخال خاطئة وعشوائية في المعامل الذي يتم فحصه، وملء الباقي بقيم "إيجابية" تم توليدها بنفس الطريقة المذكورة في السيناريوهات الإيجابية.

جهد مستمر

نحن نعمل على ترحيل سيناريوهاتنا الأخرى إلى الأداة مفتوحة المصدر، لصالح المجتمع. تابعونا للحصول على التحديثات.

قابلية التوسع

الأداة مكتوبة بطريقة تجعل من السهل توسيع وظائف التحوير وتوليد الطلبات لتلبية احتياجاتك الخاصة. لا تتردد في اقتراح أي إضافات قد يستفيد منها الآخرون عن طريق إنشاء طلب سحب (pull request).

الحصول على المساعدة

إذا كانت لديك أسئلة حول المكتبة، تأكد من مراجعة توثيق الكود المصدري. إذا كانت لا تزال لديك أسئلة، تواصل معي عبر البريد الإلكتروني على boris.serebro(at)imperva(dot)com.

الإبلاغ عن الأخطاء

يرجى فتح مشكلة على Git (Git Issue) وتضمين أكبر قدر ممكن من المعلومات. إذا أمكن، قدم نموذج كود يوضح المشكلة التي تواجهها. إذا كنت تواجه خطأً في مستودع معين فقط، قدم رابطًا له، إذا أمكن. لا تفتح مشكلة Git للمساعدة، فقط للإبلاغ عن الأخطاء.