API सिक्योरिटी टेस्टिंग चेकलिस्ट, इस आधार पर कि जाँच कौन करता है
ऑटोमेटेड फ़ंक्शनल वेरिफ़िकेशन से कवर
ये व्यवहार से जुड़ी जाँचें हैं: जिस रिक्वेस्ट को API को मना करना चाहिए, क्या वह उस पर सही प्रतिक्रिया देता है। ये आपके नियमित सुइट का हिस्सा होनी चाहिए और हर बदलाव पर चलनी चाहिए।
बिना ऑथेंटिकेशन के एक्सेस अस्वीकार होता है। हर प्रोटेक्टेड एंडपॉइंट, बिना क्रेडेंशियल के कॉल करने पर, डेटा देने के बजाय सही रिजेक्शन लौटाए।
ऑथराइज़ेशन हर ऑब्जेक्ट के स्तर पर लागू होता है। यूज़र A, पाथ में आइडेंटिफ़ायर बदलकर यूज़र B के रिकॉर्ड न पढ़ सके, न बदल सके। असली APIs में सबसे ज़्यादा एक्सप्लॉइट की जाने वाली खामी यही है, और यह एक सीधी-सादी व्यवहार-आधारित जाँच है।
रोल की सीमाएँ बनी रहती हैं। रीड-ओनली रोल लिख नहीं सकता। एक्सपायर्ड या रिवोक किया गया टोकन अस्वीकार होता है।
इनपुट वैलिडेशन रेंज से बाहर की वैल्यू अस्वीकार करता है। हर पैरामीटर पर बाउंड्री केस, उन पर भी जिन्हें कोई डॉक्युमेंट नहीं करता।
एरर अंदरूनी जानकारी लीक नहीं करते। स्टैक ट्रेस, क्वेरी के टुकड़े और इंटरनल होस्टनेम रिस्पॉन्स से बाहर रहें।
स्कैनर या किसी विशेष टूल की ज़रूरत
डिपेंडेंसी और लाइब्रेरी की वल्नरेबिलिटीज़।
इंजेक्शन की श्रेणियाँ: SQL, कमांड, टेम्प्लेट, डीसीरियलाइज़ेशन।
TLS कॉन्फ़िगरेशन और सर्टिफ़िकेट हैंडलिंग।
आपके स्टैक के ख़िलाफ़ ज्ञात CVE की जाँच।
इंसान की ज़रूरत
बिज़नेस लॉजिक का दुरुपयोग। नेगेटिव क्वांटिटी का ऑर्डर करना, डिस्काउंट को दोबारा भुनाना, ऐसे वर्कफ़्लो में कोई स्टेप छोड़ देना जो क्रम मानकर चलता था।
थ्रेट मॉडलिंग, और यह तय करना कि संवेदनशील डेटा असल में है क्या।
कुछ भी जिसमें यह कल्पना करनी पड़े कि कोई आपके प्रोडक्ट का गलत इस्तेमाल कैसे करेगा।
वह एक चीज़ जिसे लोग छोड़ देते हैं
ऑब्जेक्ट-लेवल ऑथराइज़ेशन वह आइटम है जो सबसे ज़्यादा बार छूटता है और जिसे जाँचना सबसे आसान है। दो अकाउंट बनाइए, एक से एक रिकॉर्ड बनवाइए, और दूसरे के टोकन से उसे पढ़ने की कोशिश कीजिए। अगर डेटा मिल जाता है, तो आपके पास इंडस्ट्री की सबसे आम गंभीर API खामी मौजूद है, और उसे ढूँढने में एक टेस्ट लगता है।
इसे ऑटोमेट करना पूरी कवायद की क़ीमत वसूल कर देता है, क्योंकि यह जाँच हर नए एंडपॉइंट के लिए दोहरानी पड़ती है और कोई इंसान इसे याद नहीं रखेगा।
ऑटोमेट होने वाले आधे हिस्से को सचमुच चलाना
जेनरेट किए गए API प्लान में ऑथराइज़ेशन और बाउंड्री कैटेगरी शामिल होती हैं, इसलिए ये जाँचें आपकी फ़ंक्शनल कवरेज के साथ-साथ मौजूद रहती हैं, न कि एक अलग सिक्योरिटी कवायद के रूप में जिसे कोई शेड्यूल ही नहीं करता।
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
जो लोग लोकल इंस्टॉल नहीं चाहते, उनके लिए डैशबोर्ड इन्हीं चीज़ों को कवर करता है, और पूरा कमांड सरफ़ेस मौजूद है CLI रिपॉज़िटरी में।
इसकी कार्यप्रणाली दी गई है API टेस्टिंग डॉक्युमेंटेशन में।
वे दो अकाउंट जो आपको हमेशा बनाए रखने चाहिए
इस सूची के लगभग हर व्यवहार-आधारित आइटम के लिए दो यूज़र चाहिए, और सबसे सस्ता उपाय यही है कि हर एनवायरनमेंट में टेस्ट अकाउंट की एक जोड़ी बनाकर रखी जाए, बजाय इसके कि हर टेस्ट के लिए नए बनाए जाएँ।
इन्हें उन तरीक़ों से अलग रखिए जो आपके प्रोडक्ट के लिए मायने रखते हैं: अलग मालिक, अलग रोल अगर आपके यहाँ रोल हैं, और आदर्श रूप से अलग ऑर्गनाइज़ेशन। फिर हर ऑथराइज़ेशन जाँच सेटअप की कवायद के बजाय दो लाइन का टेस्ट बन जाती है, और लोग उन्हें सचमुच लिखते हैं।
जो तरीक़ा नाकाम होता है वह है हर टेस्ट के अंदर अकाउंट बनाना। यह धीमा है, पीछे डेटा छोड़ जाता है, और इसका मतलब है कि जाँच आपके साइनअप फ़्लो के चलने पर निर्भर हो जाती है — यानी टूटा हुआ साइनअप हर परमिशन टेस्ट को गलत वजह से लाल कर देता है। एक बार सीड किए गए स्थायी अकाउंट यह सब ख़त्म कर देते हैं।
समूह के हिसाब से कैडेंस
व्यवहार-आधारित जाँचें हर बदलाव पर। स्कैनर एक तय शेड्यूल पर और रिलीज़ के समय। इंसानी समीक्षा तब, जब थ्रेट मॉडल बदले — यानी जब आप किसी नए तरह का डेटा या नए तरह का यूज़र जोड़ें।
डैशबोर्ड से रिपॉज़िटरी कनेक्ट कीजिए और रन उसी डिप्लॉयमेंट से शुरू होंगे जो आप पहले से बनाते हैं, या इसके बजाय अपने वर्कफ़्लो में एक स्टेप जोड़ दीजिए।
ऑटोमेट होने वाले एक-तिहाई हिस्से को TestSprite कैसे कवर करता है
जेनरेट किए गए API प्लान में ऑथराइज़ेशन और बाउंड्री कैटेगरी शामिल होती हैं, इसलिए इस सूची के व्यवहार-आधारित आइटम आपकी फ़ंक्शनल कवरेज के साथ-साथ मौजूद रहते हैं, न कि एक अलग कवायद के रूप में जिसे किसी को शेड्यूल करना पड़े।
इसका मतलब है कि बिना ऑथेंटिकेशन के एक्सेस, ऑब्जेक्ट-लेवल ऑथराइज़ेशन, रोल की सीमाएँ, एक्सपायर्ड टोकन और रेंज से बाहर का इनपुट — ये सब हर बदलाव पर, चल रही सर्विस के ख़िलाफ़, हर एंडपॉइंट के लिए जाँचे जाते हैं, उन एंडपॉइंट्स के लिए भी जो पिछले हफ़्ते जोड़े गए। Auto-Authentication पूरे रन के दौरान सेशन ज़िंदा रखता है, Dynamic Variables कॉल्स के बीच वैल्यू ले जाते हैं, Dependency Chains हर केस को क्या चाहिए और वह क्या बनाता है, इससे एक्ज़ीक्यूशन का क्रम निकालते हैं, और Auto-Cleanup ठीक वही हटाता है जो रन ने बनाया था।
क़ीमत चतुराई में नहीं, कैडेंस में है। ये जाँचें लिखना मुश्किल नहीं है; मुश्किल है चालीसवें एंडपॉइंट पर इन्हें याद रखना। इनका जेनरेट होना और लगातार चलते रहना ही वह चीज़ है जो असली APIs में सबसे ज़्यादा एक्सप्लॉइट की जाने वाली कमी को भर देती है, बिना कोई ऐसी प्रक्रिया जोड़े जिसका पालन किसी को करना पड़े।
क्या यह पेनिट्रेशन टेस्ट का विकल्प है?
नहीं। यह व्यवहार वाले आधे हिस्से को लगातार कवर करता है, जिससे पेनिट्रेशन टेस्ट को कम चीज़ें ढूँढनी पड़ती हैं और वह महँगा एंगेजमेंट ज़्यादा उपयोगी बन जाता है।
क्या TestSprite वल्नरेबिलिटी स्कैन करता है?
नहीं। यह व्यवहार की पुष्टि करता है, जिसमें ऑथराइज़ेशन और बाउंड्री केस शामिल हैं। वल्नरेबिलिटी स्कैनिंग एक अलग उपकरण है।
व्यवहार-आधारित जाँचें कितनी बार चलनी चाहिए?
हर बदलाव पर। नए एंडपॉइंट लगातार जुड़ते रहते हैं और हर एक को वही ऑथराइज़ेशन जाँच चाहिए जो पिछले को चाहिए थी।
शुरुआत कहाँ से करें?
हर उस एंडपॉइंट पर ऑब्जेक्ट-लेवल ऑथराइज़ेशन से जो कोई आइडेंटिफ़ायर लेता है। सबसे ज़्यादा हिट रेट, सबसे कम मेहनत।
क्या इसके लिए हमें सिक्योरिटी टीम चाहिए?
थ्रेट मॉडलिंग और बिज़नेस लॉजिक के दुरुपयोग के लिए, हाँ। ऊपर दी गई चेकलिस्ट के आइटम सामान्य इंजीनियरिंग काम हैं।
जिस चेकलिस्ट का कोई ज़िम्मेदार न हो, वह सिर्फ़ एक दस्तावेज़ है।
API सिक्योरिटी टेस्टिंग चेकलिस्ट तीन हिस्सों में बँटती है: व्यवहार-आधारित जाँचें जिन्हें आप ऑटोमेट करके हर बदलाव पर चलाते हैं, स्कैनिंग जो एक तय शेड्यूल पर चलती है, और दुरुपयोग को लेकर इंसानी समझ। शुरुआत ऑब्जेक्ट-लेवल ऑथराइज़ेशन से कीजिए, जो सबसे आम गंभीर खामी है और जिसे ढूँढने में एक टेस्ट लगता है।