🤱🏼 🕸️ 👩🏻‍🍳 सतर्कता Lida: सुरक्षा परीक्षण स्वचालन 🧑 🥁 🦏

शुभ दोपहर, प्रिय पाठकों। मेरा नाम विक्टर ब्यूरोव है, मैं ISPsystem में एक डेवलपर हूं। पिछली पोस्ट में मैंने ऑटोटेस्ट बनाने के लिए उपकरण के बारे में बात की थी, आज मैं सुरक्षा परीक्षण को स्वचालित करने में अपना अनुभव साझा करूंगा।

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

भेद्यता खोज उपयोगिताओं का विश्लेषण करने के बाद, मैं इस निष्कर्ष पर पहुंचा कि उन्हें कॉल करने के लिए फ़ंक्शन और उपयोग किए गए मापदंडों को निर्दिष्ट करने की आवश्यकता है। हमने फिर से एकीकृत इंटरफ़ेस का लाभ उठाने का फैसला किया और Lida के लिए आवश्यकताओं को तैयार किया।

स्टार्टअप आवश्यकताएँ:

स्वचालित रूप से फ़ंक्शन सूची बनाएं।
स्वतः पूर्ण विकल्प।
एपीआई अनुरोध करना।
कार्य करने के बाद डेटा आउटपुट का विश्लेषण।
डेटा में कमजोरियों के लिए खोजें।
रिपोर्टों का गठन।
लचीली सेटिंग्स।

यह सब महसूस करना आसान नहीं था।

कार्यान्वयन

बाइपास फॉर्म और सूचियां

किसी फ़ंक्शन में कमजोरियों को खोजने के लिए, इसे आवश्यक मापदंडों को पारित करके निष्पादित किया जाना चाहिए। हमारा इंटरफ़ेस सूचियों और रूपों के आधार पर बनाया गया है, इसलिए आप इंटरफ़ेस तत्वों की संरचना का वर्णन करने वाले xml- दस्तावेज़ों को संसाधित करके डेटा संग्रह को स्वचालित कर सकते हैं।

मैंने मुख्य मेनू से क्रॉल शुरू करने का फैसला किया, पुन: सभी नेस्टेड सूचियों में जा रहा है। "Lida" पहले स्तर की सूची को खोलता है। एक नियम के रूप में, इसमें कई बटन हैं जो कुछ कार्यों को लागू करते हैं।

यदि बटन फॉर्म को खोलता है, तो कॉल का परिणाम एक xml-document होगा जिसमें नोड्स के साथ फ़ील्ड्स की जानकारी होगी: नाम, सत्यापनकर्ता, मान्य मानों की श्रेणी। इस जानकारी के आधार पर, क्षेत्र मान उत्पन्न होते हैं। उदाहरण के लिए, इंट के लिए एक नंबर जेनरेट किया जाएगा। यदि कोई सत्यापनकर्ता नहीं है, तो एक यादृच्छिक स्ट्रिंग उत्पन्न होती है। फॉर्म के सभी क्षेत्रों को भरने के बाद, एक अनुरोध भेजा जाता है।

यदि फ़ंक्शन एक सूची है, तो यह खुला होगा और बटन से जुड़े कार्यों को इसके तत्वों के लिए बुलाया जाएगा।

सूचियों की जांच करते समय, एक समस्या उत्पन्न होती है - सभी सूचियों में रिकॉर्ड का एक सेट होना चाहिए जो यह सुनिश्चित करेगा कि सूची के सभी बटन क्लिक करने योग्य हैं।

एसक्यूएल इंजेक्शन खोज

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

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

आप स्वयं SQL सर्वर के लॉग का उपयोग कर सकते हैं। लेकिन हमारे मामले में, प्रश्नों को निष्पादित करने के लिए केवल एक ही तरीका है और इसमें लॉगिंग जोड़ना मुश्किल नहीं था। इसके लिए धन्यवाद, हम जानते हैं कि इस या उस अनुरोध को किस चुनौती ने उत्पन्न किया है।

जब पारित पैरामीटर का मान मिलता है, तो उपयोगिता इस पैरामीटर के लिए एकल उद्धरण वाले मान को पारित करती है। यदि उसी क्रम में उद्धरण पाया जाता है, तो पैरामीटर बच नहीं जाता है - हमने एसक्यूएल इंजेक्शन के लिए एक जगह पाई।

सिस्टम कॉल विश्लेषण

इसी तरह की समस्या तब होती है जब हम कोई सिस्टम कॉल करते हैं। मैंने उन्हें स्ट्रेस के साथ देखने का फैसला किया और इसके लिए इष्टतम लॉन्च मापदंडों का चयन किया। ISPmanager शुरू करने का उदाहरण:

strace -f -s 1024 -e trace=file,process bin/core ispmgr

SQL इंजेक्शन के साथ, Lida एक कार्य करता है और खुले, पास, rmdir, chmod chown, chflags, mknod, mkfifo, fcntl, symlink, लिंक, execve, mkdir फ़ंक्शंस में खुले मापदंडों को मानने के लिए स्ट्रेस आउटपुट का विश्लेषण करता है।

यदि पैरामीटर पाया जाता है, तो उपयोगिता इसके साथ एक मान पारित करती है, उदाहरण के लिए, ऊपर की निर्देशिका में एक संक्रमण के साथ एक पथ। यदि यह वैसा ही हो जाता है, तो एक संभावित भेद्यता मिल जाती है।

निष्पादित कार्य का विश्लेषण बहुत उपयोगी निकला। यह आपको यह निर्धारित करने की अनुमति देता है कि निष्पादन योग्य फ़ाइलों को चलाने के लिए कौन से फ़ंक्शन तर्क बच गए हैं। यह त्रुटि बहुत महंगी है, क्योंकि इसके माध्यम से आप केवल पासवर्ड बदलकर सर्वर तक रूट एक्सेस प्राप्त कर सकते हैं।

जब उपयोगकर्ता हमारे उत्पादों में भेद्यता पाते हैं, तो कंपनी नकद इनाम देती है, जिसकी मात्रा भेद्यता की श्रेणी पर निर्भर करती है। यह दृष्टिकोण अपने दम पर त्रुटियों की खोज करने की तुलना में सस्ता हो सकता है (परीक्षक को त्रुटि नहीं मिल सकती है और वेतन मिल सकता है)।

एक और दिलचस्प परीक्षण: स्टेटमेंट और अन्य कार्यों को कॉल करने के क्रम की जांच करना। अक्सर, एक्सेस को पहले स्टेट के माध्यम से चेक किया जाता है, और फिर कुछ असुरक्षित क्रियाएं होती हैं, जो प्रतिस्थापन के लिए अवसर छोड़ देती हैं। लेकिन हमने इसे स्वचालित नहीं किया।

विदेशी वस्तुओं तक पहुंच की जाँच करना

हम किसी अन्य उपयोगकर्ता और व्यवस्थापक की संस्थाओं के लिए उपयोगकर्ता से विदेशी वस्तुओं तक पहुंच की जांच करते हैं। इस मोड में, हम एक विदेशी उपयोगकर्ता के तत्वों की सूची को पढ़ने, संशोधित करने और देखने की क्षमता की जांच करते हैं।

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

कुछ मामलों में, त्रुटि की अनुपस्थिति का मतलब यह नहीं है कि आप सीधे अन्य उपयोगकर्ता की वस्तुओं तक पहुंच सकते हैं। इस तरह के कार्यों की शुरुआत में, हम एक तत्व अनुमतियाँ जोड़ते हैं। यह न केवल सुरक्षा, बल्कि सर्वर प्रतिक्रियाओं की शुद्धता की भी जांच करता है।

एपीआई मान्यकरण

हमारे एपीआई का सत्यापन कमजोरियों के लिए जाँच कार्यों का एक अतिरिक्त बोनस है। लिडा के काम की रिपोर्टों का विश्लेषण करते हुए, हमने सही प्रकार की त्रुटियों को वापस करना सीखा, जिससे हमारी एपीआई अधिक सुविधाजनक और तार्किक बन गई। नतीजतन, टेप रिकॉर्डर के रूप में, हमें न केवल एक सुरक्षा जांच मिली, बल्कि एक बार फिर "स्थिरता" के लिए हमारे एपीआई की जांच की।

कठिनाइयों

झूठी सकारात्मकता

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

झूठी सकारात्मकता लिडा की सबसे बड़ी समस्या थी। ऐसा लगता था कि यह पूरी तरह से डीबग हो गया था, लेकिन जब अलग-अलग पैनलों पर जांच की गई, तो नई गलत सकारात्मकता पैदा हुई। नतीजतन, उनके सुधार के कई चरण थे।

इकाई निर्माण

पैनल में अधिकांश क्रियाएं किसी भी इकाई (डोमेन नाम, डेटाबेस, आदि) पर की जाती हैं। अधिकतम स्वचालन प्राप्त करने के लिए, लिडा को इन संस्थाओं को स्वचालित रूप से बनाना पड़ा। लेकिन व्यवहार में यह लागू करना मुश्किल हो गया। कभी-कभी सत्यापन कोड में किया जाता है, इसलिए पैरामीटर मान को स्वचालित रूप से प्रतिस्थापित करना हमेशा संभव नहीं होता है। दूसरा कारण निर्भर संस्थाएं हैं। उदाहरण के लिए, मेलबॉक्स बनाने के लिए, आपको एक मेल डोमेन बनाने की आवश्यकता है।

इसलिए, हमने पूर्ण स्वचालन के लिए नहीं लड़ने का फैसला किया। शुरू करने से पहले, परीक्षक मैन्युअल रूप से इकाइयां बनाता है और मशीन का स्नैपशॉट लेता है, क्योंकि सत्यापन के बाद संस्थाओं को बदल दिया जाएगा। यह आपको एक इकाई के असफल निर्माण के मामले में फ़ंक्शन के एक समूह की जांच नहीं छोड़ना देता है।

विनाशकारी कार्यों को बुलावा देना

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

कुछ फ़ंक्शन सर्वर को रिबूट करते हैं। उन्हें नज़रअंदाज़ किया जाना चाहिए और अनदेखी की सूची में जोड़ा जाना चाहिए।

ऑपरेटिंग तर्क की प्रकृति के कारण, कुछ फ़ंक्शन पैनल को पुनरारंभ करते हैं। सुरक्षा परीक्षण के दौरान, यह SQL क्वेरी या स्ट्रेस को ट्रेस किए बिना पैनल को शुरू करने का कारण बनता है - आगे सत्यापन अर्थहीन हो जाता है। आपको इसे ट्रैक करना होगा और ट्रेस मोड में पैनल को पुनरारंभ करना होगा।

आश्रित मापदंडों की जाँच

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

इस समस्या को हल करने के लिए, मैंने आश्रित क्षेत्रों के विश्लेषण और आश्रित नियंत्रण के सभी संयोजनों की जांच के लिए एल्गोरिदम को जोड़ा।

इंटरफ़ेस में उपलब्ध सुविधाओं की जाँच करना

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

निष्कर्ष

हमने Jidakins में हर रात के निर्माण में Lida को शामिल किया। इसके काम के परिणामों के आधार पर, एक सत्यापन रिपोर्ट तैयार की जाती है, इसमें संदिग्ध फ़ंक्शन के बारे में जानकारी सभी मापदंडों के साथ प्रदर्शित की जाती है।

डेवलपर द्वारा बंद किए गए कार्य को अब न केवल परीक्षक द्वारा, बल्कि लिडा द्वारा भी जांचा जाता है। परीक्षक प्राप्त रिपोर्ट को संसाधित करता है: ब्राउज़र को संदिग्ध फ़ंक्शन के मापदंडों की प्रतिलिपि बनाता है और व्यवहार और लॉग पैनल का विश्लेषण करता है। यदि भेद्यता की पुष्टि की जाती है, तो त्रुटि डेवलपर को लॉग इन होती है।

सतर्कता Lida: सुरक्षा परीक्षण स्वचालन