स्वचालित 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 सॉफ़्टवेयर) में चलाएं, जो क्रॉन, या रेपो कोड पुश गतिविधि द्वारा ट्रिगर होगा। सुनिश्चित करें कि आपके पास TestNG प्लगइन स्थापित है, जो build/testng-results में लिखे गए परिणामों को पार्स करेगा, CI/CD परिदृश्य में बेहतर दृश्यता के लिए।

• आप जांचना चाहते हैं कि क्या यह API फ़ज़िंग प्रयासों के लिए खुला हो सकता है। बस टूल चलाएं और रिपोर्ट की गई विफलताओं की जाँच करें।

  उदाहरण रन: api-attack.sh -f publiclyAvailableSwaggerOfAPI.yaml -n api.corporate.com -s https

• आप जांचना चाहते हैं कि आपका API सर्वर साइड पर सही ढंग से लागू किया गया है, या इसकी परिभाषा सर्वर कार्यान्वयन से मेल खाती है या नहीं।

  उदाहरण रन: api-attack.sh -f publiclyAvailableSwaggerOfAPI.yaml -n api.corporate.com -s https

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

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

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

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

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

• टूल testng रिपोर्टिंग फ्रेमवर्क का उपयोग करता है, इसलिए testng रन को संभालने वाला कोई भी प्लगइन यहां उपयोग किया जा सकता है। बस ध्यान दें कि परिणाम build/testng-results फ़ोल्डर के अंतर्गत लिखे जाते हैं। इसे निश्चित रूप से बदला जा सकता है।
• टूल अपने जाँच सूट के अनुसार अनुरोध उत्पन्न करता है, और प्रत्येक अनुरोध कुछ विशिष्ट जाँचता है। तो प्रत्येक जाँच कमांड लाइन आउटपुट में सभी प्रासंगिक विवरण प्रस्तुत करेगी, साथ ही यह भी कि क्या जाँचा जा रहा है, प्रतिक्रिया क्या है, और क्या यह अपेक्षित था या नहीं।
• कोई भी खराब अनुरोध bad_requests फ़ोल्डर में संग्रहीत किए जाएंगे, ताकि आप बाद में इसका विश्लेषण कर सकें (उदाहरण के लिए, यदि यह CI/CD सर्वर पर चल रहा है, और आपके पास मशीन तक तत्काल पहुँच नहीं है)
• अंत में, आपको एक सारांश प्रदान किया जाएगा