एक लोकल नोट्स एप्लीकेशन अपने यूनिट टेस्ट पास कर सकता है, जबकि उसमें दो सिक्योरिटी कमियां भी हो सकती हैं। GET /notes/:id रूट तब नोट 42 दिखाता है जब कोई ऑथेंटिकेटेड यूज़र इसके लिए रिक्वेस्ट करता है, भले ही नोट 42 किसी दूसरे अकाउंट का हो। इसके अलावा, एप्लीकेशन एक ऐसा सर्च टर्म स्वीकार करता है जो बिना सुरक्षित तरीके से हैंडल किए डेटाबेस क्वेरी तक पहुँच जाता है। तीसरी समस्या रिपॉजिटरी के कस्टम कोड के बाहर होती है, जहाँ एक पैकेज वर्शन में पब्लिश की गई सिक्योरिटी एडवाइजरी होती है। पहली कमी के लिए अटैकर को सिर्फ़ एक वैलिड लो-प्रिविलेज अकाउंट चाहिए, दूसरी के लिए एक एक्सेस करने लायक HTTP एंडपॉइंट, और डिपेंडेंसी रिस्क के लिए सोर्स-कोड एक्सेस की ज़रूरत नहीं होती।
ये कमियां एप्लीकेशन के अटैक सरफेस को उजागर करती हैं, यानी हर वो कोड पाथ, रनटाइम इंटरफ़ेस और डिपेंडेंसी बाउंड्री जिसके ज़रिए अनट्रस्टेड इनपुट या अटैकर के कंट्रोल वाला व्यवहार सिस्टम को प्रभावित कर सकता है। डिफेंडर का सवाल यह नहीं है कि आम तौर पर कौन सा स्कैनर सबसे अच्छा है। हमें यह तय करना होगा कि एक ही नोट्स एप्लीकेशन के लिए स्टैटिक एप्लीकेशन सिक्योरिटी टेस्टिंग, डायनामिक एप्लीकेशन सिक्योरिटी टेस्टिंग और सॉफ्टवेयर कंपोजीशन एनालिसिस को क्या सबूत देने चाहिए, और फिर उस सबूत का इस्तेमाल करके यह तय करना होगा कि कोई बदलाव लागू किया जा सकता है या नहीं। सोर्स रिपॉजिटरी, रनिंग HTTP व्यवहार और थर्ड-पार्टी पैकेज रिस्क के अलग-अलग हिस्सों को उजागर करते हैं।
सबसे छोटा उपयोगी अंतर /notes/42 के लिए रिक्वेस्ट है। सोर्स एनालिसिस उस ऑथराइजेशन कंडीशन की पहचान कर सकता है जो रिक्वेस्ट करने वाले यूज़र के अकाउंट की तुलना कभी नोट के मालिक से नहीं करती। रनटाइम एनालिसिस एक यूज़र के तौर पर ऑथराइज्ड लैब रिक्वेस्ट भेज सकता है और देख सकता है कि क्या रिस्पॉन्स किसी दूसरे यूज़र का नोट दिखाता है। डिपेंडेंसी एनालिसिस कमजोर फीचर को बिना इस्तेमाल किए पैकेज मैनिफेस्ट की जांच कर सकता है। कौन सा ऑब्जर्वर हर दावे को साबित कर सकता है, यह इस बात पर निर्भर करता है कि कमी कहाँ मौजूद है।
नोट्स एप्लीकेशन में ट्रस्ट बाउंड्री यह दिखाती हैं कि हर तरह का सबूत कहाँ शुरू और खत्म होता है।
यह डायग्राम दिखाता है कि क्यों कोई भी एक स्कैनर ब्राउज़र इनपुट, एप्लिकेशन लॉजिक, डेटाबेस कॉल और बाहरी पैकेज बाउंड्री को समान रूप से नहीं देख पाता है।
क्योंकि तीनों ऑब्ज़र्वर को एक कॉमन टारगेट की ज़रूरत होती है, इसलिए कोर्स में एक ऐसी रिपॉज़िटरी का इस्तेमाल किया जाता है जिसमें स्थानीय रूप से ओन्ड (locally owned), जानबूझकर खामियों वाला नोट्स एप्लिकेशन होता है। यह एप्लिकेशन वेब API बाउंड्री पर HTTP पैरामीटर और JSON बॉडी स्वीकार करता है, लोकल लॉगिन रूट से बनी पहचान का इस्तेमाल करता है, HTML या JSON रिस्पॉन्स देता है, और अपने डेटा-एक्सेस लेयर के ज़रिए डेटाबेस ऑपरेशन भेजता है। हम केवल इस लोकल लैब एप्लिकेशन और उन एनवायरनमेंट को स्कैन करते हैं जिन्हें हम कंट्रोल करते हैं। लिखित अनुमति के बिना थर्ड-पार्टी सर्विस की टेस्टिंग करना कोर्स का हिस्सा नहीं है और इससे यूनाइटेड स्टेट्स में ‘कंप्यूटर फ्रॉड एंड एब्यूज़ एक्ट’ या यूनाइटेड किंगडम में ‘कंप्यूटर मिसयूज़ एक्ट 1990’ जैसे कानूनों का उल्लंघन हो सकता है।
रिपॉज़िटरी में जानबूझकर दो तरह के व्यवहार शामिल किए गए हैं। एक है इंजेक्शन-प्रोन सर्च पाथ, जो CWE-89 (SQL कमांड में इस्तेमाल होने वाले खास एलिमेंट्स का गलत न्यूट्रलाइज़ेशन) का उदाहरण है। दूसरा है GET /notes/:id पर टूटा हुआ ऑब्जेक्ट-लेवल ऑथराइज़ेशन; OWASP API सिक्योरिटी टॉप 10 2023 में इस फेलियर कैटेगरी को API1 ब्रोकन ऑब्जेक्ट लेवल ऑथराइज़ेशन कहा गया है। डिपेंडेंसी मैनिफ़ेस्ट में एक ऐसे पैकेज का भी ज़िक्र है जो जानबूझकर पुराना रखा गया है और जिसमें एक ज्ञात समस्या है। ये मामले अलग-अलग रहते हैं क्योंकि कोड से मिली जानकारी, HTTP ऑब्ज़र्वेशन और पैकेज एडवाइज़री एक-दूसरे की जगह इस्तेमाल होने वाले सबूत नहीं हैं।
रिपॉज़िटरी स्नैपशॉट किसी भी स्कैन या रिक्वेस्ट को चलाए बिना रूट, डेटा एक्सेस और डिपेंडेंसी डिक्लेरेशन का पता लगाता है।