स्वचालित API हमला उपकरण

Imperva का अनुकूलन योग्य API हमला उपकरण एक API विनिर्देश को इनपुट के रूप में लेता है, और उसके आधार पर हमलों को उत्पन्न और चलाता है।

यह उपकरण API विनिर्देश को पार्स करने और API विनिर्देश में परिभाषित चीज़ों के आधार पर फ़ज़िंग हमले के परिदृश्य बनाने में सक्षम है। प्रत्येक एंडपॉइंट में विनिर्देश द्वारा परिभाषित सीमाओं के भीतर चतुराई से उत्पन्न मान इंजेक्ट किए जाते हैं, और इसके बाहर, उपयुक्त अनुरोध भेजे जाते हैं और उनकी सफलता या विफलता विस्तृत रूप से रिपोर्ट की जाती है। आप इसे विभिन्न सुरक्षा हमले वैक्टर चलाने के लिए भी विस्तारित कर सकते हैं, जैसे अवैध संसाधन पहुँच, XSS, SQLi और RFI, जो मौजूदा एंडपॉइंट या गैर-मौजूदा एंडपॉइंट को लक्षित करते हैं। किसी मानवीय हस्तक्षेप की आवश्यकता नहीं है। बस टूल चलाएं और परिणाम प्राप्त करें।

टूल को विभिन्न आवश्यकताओं को पूरा करने के लिए आसानी से विस्तारित किया जा सकता है, जैसे कि एक डेवलपर जो अपने API का परीक्षण करना चाहता है, या एक संगठन जो अपने सार्वजनिक API पर नियमित भेद्यता या सकारात्मक सुरक्षा स्कैन चलाना चाहता है। इसे CI/CD को ध्यान में रखकर बनाया गया है।

आवश्यकताएँ

• Java 8 या उच्चतर
• Gradle

चलाना

• GitHub से कोड चेक आउट करें और ./gradlew build या Windows पर gradlew.bat build चलाएं
• आप build/libs फ़ोल्डर के अंतर्गत निष्पादन योग्य jar पा सकते हैं
• सहायता मेनू देखने के लिए 'java -jar imperva-api-attack-tool.jar' चलाएं

Linux निष्पादन योग्य बनाना

• src/main/resources फ़ोल्डर से runnable.sh फ़ाइल को jar फ़ाइल के साथ उसी निर्देशिका में कॉपी करें।
• अब चलाएं: cat runnable.sh imperva-api-attack-tool.jar > api-attack.sh && chmod +x api-attack.sh
• आप api-attack.sh फ़ाइल का उपयोग एक नियमित निष्पादन योग्य के रूप में कर सकते हैं

उपयोग

आवश्यक पैरामीटर:

-f, --specFile=specFilePath

API विनिर्देश फ़ाइल (swagger 2.0) जिस पर चलाना है। JSON/YAML प्रारूप। बेहतर परिणामों के लिए, सुनिश्चित करें कि प्रत्येक एंडपॉइंट के लिए प्रतिक्रियाएं अच्छी तरह से परिभाषित हैं।

-n, --hostName=hostName

कनेक्ट करने के लिए होस्ट का नाम। यह एक IP भी हो सकता है

-s, --hostScheme=hostScheme

इस योजना का उपयोग करके होस्ट से कनेक्शन बनाया जाएगा; जैसे: https या http

वैकल्पिक पैरामीटर:

-p, --hostPort=hostPort

API कॉल के लिए होस्ट जिस पोर्ट पर सुन रहा है, डिफ़ॉल्ट है: 443

-ph, --proxyHost=proxyHost

प्रॉक्सी के माध्यम से अनुरोध भेजने के लिए प्रॉक्सी होस्ट निर्दिष्ट करें

-pp, --proxyPort=proxyPort

प्रॉक्सी पोर्ट, डिफ़ॉल्ट है: 80

-rcn, --addNegativeRC=responseCode[,responseCode...]

नकारात्मक हमलों (जैसे खराब मान हमले) में स्वीकार किए जाने वाले अतिरिक्त प्रतिक्रिया कोड। कई मान समर्थित हैं, अल्पविराम द्वारा अलग किए गए

-rcp, --addPositiveRC=responseCode[,responseCode...]

सकारात्मक जाँचों (वैध मान हमले) में स्वीकार किए जाने वाले अतिरिक्त प्रतिक्रिया कोड। कई मान समर्थित हैं, अल्पविराम द्वारा अलग किए गए

सामान्य उपयोग परिदृश्य:

• आप जांचना चाहते हैं कि आपका API किसी 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 सभी इनपुट को सही ढंग से संभालता है या नहीं। इसके अलावा, आप इसे प्रतिदिन रात में, या हर बार जब कोई डेवलपर प्रोजेक्ट में नया कोड पुश करता है, चलाना चाहते हैं।

  उदाहरण रन: api-attack.sh -f myapi_swagger.yaml -n staging.myorg.com -s https

  इस बार हम बिना किसी बहिष्करण के चला रहे हैं। API विनिर्देश फ़ाइल को अपने प्रतिक्रिया कोड सटीक रूप से घोषित करने होंगे। टूल केवल उन्हें वैध मानेगा, और अन्यथा जाँचें विफल कर देगा। जाँच विफल होने की शर्तों के बारे में अधिक जानकारी नीचे देखें। उपरोक्त कमांड को Jenkins जॉब (या आपकी पसंद के किसी अन्य CI/CD सॉफ़्टवेयर) में चलाएं, जो क्रॉन, या रेपो कोड पुश गतिविधि द्वारा ट्रिगर होगा। सुनिश्चित करें कि आपके पास प्लगइन स्थापित है, जो में लिखे गए परिणामों को पार्स करेगा, CI/CD परिदृश्य में बेहतर दृश्यता के लिए।

जाँच विफल होने की शर्तें

• टूल उत्पन्न अनुरोध प्रतिक्रिया कोड को स्वैगर में घोषित प्रतिक्रिया कोड से मिलान करता है। फिर भी,
• सकारात्मक जाँचें: यदि यह स्पष्ट त्रुटि है (कोड 5xx है), तो हम फिर भी जाँच विफल कर देंगे, भले ही यह प्रतिक्रिया कोड विनिर्देश में परिभाषित न हो, लेकिन यदि आपने ओवरराइड प्रदान किया है तो नहीं।
• नकारात्मक जाँचें: यदि प्रतिक्रिया कोई वैध त्रुटि नहीं है (1xx, 2xx, 5xx), तो हम जाँच विफल कर देते हैं जब तक कि आपने ओवरराइड प्रदान नहीं किया। यदि वैध त्रुटि कोड विनिर्देश में नहीं है, तो जाँच भी विफल हो जाएगी।
• आप स्वैगर के प्रतिक्रिया अनुभाग में 'डिफ़ॉल्ट' परिभाषा का उपयोग कर सकते हैं, लेकिन इसकी अनुशंसा नहीं की जाती है। हमेशा अपने वैध उत्तरों को सटीक रूप से परिभाषित करें।

जाँच विफल होने की शर्तें

• टूल उत्पन्न अनुरोध प्रतिक्रिया कोड को स्वैगर में घोषित प्रतिक्रिया कोड से मिलान करता है। फिर भी,
• सकारात्मक जाँचें: यदि यह स्पष्ट त्रुटि है (कोड 5xx है), तो हम फिर भी जाँच विफल कर देंगे, भले ही यह प्रतिक्रिया कोड विनिर्देश में परिभाषित न हो, लेकिन यदि आपने ओवरराइड प्रदान किया है तो नहीं।
• नकारात्मक जाँचें: यदि प्रतिक्रिया कोई वैध त्रुटि नहीं है (1xx, 2xx, 5xx), तो हम जाँच विफल कर देते हैं। जब तक आपने ओवरराइड प्रदान नहीं किया। यदि वैध त्रुटि कोड विनिर्देश में नहीं है, तो जाँच भी विफल हो जाएगी।
• आप स्वैगर के प्रतिक्रिया अनुभाग में 'डिफ़ॉल्ट' परिभाषा का उपयोग कर सकते हैं, लेकिन इसकी अनुशंसा नहीं की जाती है। हमेशा अपने वैध उत्तरों को सटीक रूप से परिभाषित करें।

अपेक्षित आउटपुट:

• टूल 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}

सर्वर को एक पूर्णांक प्राप्त करने की उम्मीद थी, लेकिन एक डबल मान स्वीकार किया। यह सर्वर में किसी बफर ओवरफ्लो का शोषण करने का एक अच्छा स्थान हो सकता है।

सफल जाँच का उदाहरण:

***** 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 और विधि युग्म के रूप में करेंगे।

सकारात्मक परिदृश्य

• प्रत्येक एंडपॉइंट के लिए, इसके सभी मापदंडों के लिए उत्पन्न मानों के साथ एक अनुरोध बनाता है। ये यादृच्छिक रूप से उत्पन्न होते हैं, लेकिन API विनिर्देश में परिभाषित नियमों का पालन करते हैं।
• प्रत्येक एंडपॉइंट के लिए, केवल आवश्यक मापदंडों के साथ एक अनुरोध बनाता है, जिसमें ऊपर वर्णित अनुसार उत्पन्न मान होते हैं।

नकारात्मक परिदृश्य

• प्रत्येक एंडपॉइंट के लिए, कई अनुरोध बनाता है, प्रत्येक एक अलग पैरामीटर की जाँच करता है। टूल जाँच किए जा रहे पैरामीटर में एक यादृच्छिक खराब इनपुट मान इंजेक्ट करके और शेष को "सकारात्मक" मानों से भरकर ऐसा करता है जो सकारात्मक परिदृश्यों में वर्णित उसी तरीके से उत्पन्न होते हैं।

चल रहे प्रयास

हम अपने अन्य परिदृश्यों को समुदाय के लाभ के लिए ओपन-सोर्स टूल में स्थानांतरित करने पर काम कर रहे हैं। अपडेट के लिए जुड़े रहें।

विस्तारशीलता

टूल इस तरह से लिखा गया है कि इसकी फ़ज़िंग और अनुरोध उत्पादन कार्यक्षमता को आपकी विशिष्ट आवश्यकताओं को पूरा करने के लिए विस्तारित करना आसान है। बेझिझक कोई भी ऐसा जोड़ सुझाएं जिससे दूसरों को लाभ हो सके, पुल अनुरोध बनाकर।

सहायता प्राप्त करना

यदि लाइब्रेरी के बारे में आपके कोई प्रश्न हैं, तो स्रोत कोड दस्तावेज़ीकरण अवश्य देखें। यदि अभी भी प्रश्न हैं, तो मुझसे boris.serebro(at)imperva(dot)com पर ईमेल द्वारा संपर्क करें।

बग रिपोर्ट करना

कृपया एक Git Issue खोलें और जितनी संभव हो उतनी जानकारी शामिल करें। यदि संभव हो, तो एक नमूना कोड प्रदान करें जो आपके सामने आने वाली समस्या को दर्शाता हो। यदि आप केवल किसी विशिष्ट रिपॉजिटरी पर बग का अनुभव कर रहे हैं, तो यदि संभव हो तो उसका लिंक प्रदान करें। सहायता के लिए Git Issue न खोलें, केवल बग रिपोर्ट के लिए।