🧠 🍴 👎🏽 पीवीएस-स्टूडियो स्टैटिक कोड एनालाइजर को जीरो-डेफिसिटिविटी से सुरक्षा प्रदान करता है 👨‍👦 ⛲️ ✝️

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

शून्य दिवस की धमकी

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

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

हालांकि, अन्य परिस्थितियां थीं। उदाहरण के लिए, Google Chrome को एक समय में एक भेद्यता को ठीक करना था जिसने एक हमलावर को पीड़ित के डिवाइस पर मनमाने ढंग से कोड को निष्पादित करने की अनुमति दी थी।

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

स्थैतिक विश्लेषण

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

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

सीवीई और सीडब्ल्यूई

सामान्य कमजोरियाँ और एक्सपोज़र (CVE) सॉफ्टवेयर त्रुटियों का एक डेटाबेस है जिसका उपयोग साइबर अपराधी द्वारा किया जा सकता है। CVE ज्ञात सॉफ़्टवेयर दोषों को कारगर बनाने के लिए बनाया गया था। अधिकांश सूचना सुरक्षा उपकरणों ने अपने स्वयं के डेटाबेस और नामों का उपयोग किया, और इस अराजकता को खत्म करने और विभिन्न उपकरणों के साथ संगतता जोड़ने के लिए, 1999 में MITER ने CVE बनाया। हालांकि, सीवीई कोड सुरक्षा का मूल्यांकन करने के लिए पर्याप्त नहीं था। इसके लिए समस्याओं का विस्तृत विवरण और कम से कम कच्चे तेल के साथ कुछ अधिक सटीक होना चाहिए। इसलिए, कॉमन वेकनेस एन्यूमरेशन (CWE) बेस बनाया गया जो इन आवश्यकताओं को पूरा करता है। यदि त्रुटि सीडब्ल्यूई सूची में है, तो यह संभावना है कि यह एक भेद्यता का कारण बनेगा जो हमलावर द्वारा शोषण किया जा सकता है और सीवीई सूची में शामिल हो सकता है। स्पष्टता के लिए, आप नीचे दिए गए यूलर आरेख को देख सकते हैं।

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

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

शून्य-दिन के खतरे की संभावना को कम करने के लिए विकास में SAST का उपयोग करना एक और विकल्प है। विश्लेषक, CWE के अनुसार अपनी त्रुटियों को वर्गीकृत करते हुए, यह बता सकता है कि एक संभावित भेद्यता कहाँ छिपी हुई है। और इन त्रुटियों को सुधारकर, डेवलपर अपने आवेदन को अधिक विश्वसनीय बनाता है और 0-दिन के खतरे की संभावना को कम करता है।

स्थैतिक सुरक्षा परीक्षण के लिए विभिन्न उपकरण हैं। कमजोरियों से निपटने में क्षमताओं का प्रदर्शन करने के लिए, हम पीवीएस-स्टूडियो टूल पर ध्यान केंद्रित करते हैं । इस विश्लेषक की चेतावनियों को CWE के रूप में वर्गीकृत किया जा सकता है। आइए कुछ उदाहरण देखें।

चेतावनी PVS-Studio: CWE-561 : डेड कोड ( V3021 )।

public string EncodeImage(....) { if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("inputPath"); } if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("outputPath"); } .... }

इस कोड ने अनजाने में एक टाइपो बना दिया। दो स्थितियों में, एक ही चर की जाँच की जाती है। उत्पन्न अपवाद से देखते हुए, दूसरी स्थिति में चर आउटपुटपाथ की जाँच की जानी चाहिए। नतीजतन, कोड का हिस्सा पहुंच से बाहर है।

ऐसी त्रुटियां पहली नज़र में हानिरहित दिखती हैं। हालांकि, यह धारणा बहुत भ्रामक हो सकती है। बहुत सरल और पहली नज़र में गोटो ऑपरेटर के दोहराव से संबंधित हानिरहित त्रुटि पर विचार करें।

एक समय में, इस त्रुटि के कारण iOS ऑपरेटिंग सिस्टम में भेद्यता आ गई।

CVE-2014-1266 भेद्यता विवरण: SSLVerifySignedServerKeyExchange फ़ंक्शन libsecurity_ssl / lib / sslKeyExchange.c में Apple iOS में डेटा ट्रांसपोर्ट सुविधा में सुरक्षित परिवहन सुविधा 6.1.6 से पहले 6.1x और 7.0x से पहले 7.x, Apple TV में 6.0x से पहले 6.x, और 10.9.2 से पहले Apple OS X 10.9.x एक TLS सर्वर कुंजी एक्सचेंज संदेश में हस्ताक्षर की जांच नहीं करता है, जो एक मध्यस्थ का उपयोग करके एसएसएल सर्वर को खराब करने के लिए मध्य-हमलावरों को अनुमति देता है हस्ताक्षर चरण के लिए निजी कुंजी या हस्ताक्षर चरण को छोड़ देना।

 static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; .... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; .... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }

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

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

वैसे, पीवीएस-स्टूडियो विश्लेषक द्वारा वर्णित त्रुटि का आसानी से पता लगाया जा सकता है। वह दो CWE चेतावनियों को तुरंत यहाँ देगा:

CWE-561 ( V779 ): डेड कोड
CWE-483 ( V640 ): गलत ब्लॉक परिसीमन

आइए एक और उदाहरण देखें। 2012 में वापस, यह MySQL में सुरक्षा समस्या के बारे में जाना गया, जिसमें एक हमलावर MySQL डेटाबेस में प्रवेश कर सकता है। मैं कोड का एक स्निपेट प्रदान करूंगा जो इसके कारण के रूप में कार्य करता है।

CVE-2012-2122 विवरण : Oracle MySQL में sql / password.c 5.1.x से पहले 5.1.63, 5.5.24 से पहले 5.5.x, और 5.6.6 से पहले 5.6.x, और MariaDB 5.1.x से पहले 5.1.62, 5.2.x से पहले 5.2.12, 5.3.x से पहले 5.3.6, और 5.5.x से पहले 5.5.23, जब कुछ वातावरण में चल रहे हैं, तो memcmp फ़ंक्शन के कुछ कार्यान्वयन के साथ, दूरस्थ हमलावरों को बार-बार प्रमाणीकरण करके प्रमाणीकरण को बायपास करने की अनुमति देता है गलत पासवर्ड, जो अंततः एक अनुचित तरीके से चेक किए गए रिटर्न मान के कारण सफल होने के लिए टोकन तुलना का कारण बनता है।

 typedef char my_bool; my_bool check_scramble(const char *scramble_arg, const char *message, const uint8 *hash_stage2) { .... return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); }

मेम्कंप फ़ंक्शन का रिटर्न प्रकार इंट है , और चेक_एसक्रंबल फ़ंक्शन का रिटर्न प्रकार my_bool है , वास्तव में, चार । नतीजतन, एक इंट चार के लिए डाली जाती है, जिसमें उच्च-ऑर्डर बिट्स को छोड़ दिया जाता है। यह इस तथ्य के कारण है कि 256 में से लगभग 1 मामले में, उपयोगकर्ता नाम को जानते हुए किसी भी पासवर्ड से जुड़ना संभव था।

फिर से, CWE की इस त्रुटि को बेअसर किया जा सकता है और कोड लिखने के चरण में भी CVE में बदलने से रोका जा सकता है। उदाहरण के लिए, PVS-Studio स्थिर विश्लेषक निम्नलिखित चेतावनी उत्पन्न करता है: CWE-197 ( V642 ): संख्यात्मक ट्रंकेशन त्रुटि।

इस विषय की निरंतरता में, मैं " कमजोरियों की तलाश में पीवीएस-स्टूडियो कैसे मदद कर सकता हूं" लेख को देखने का प्रस्ताव करता हूं।

निष्कर्ष

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

पीवीएस-स्टूडियो स्टैटिक कोड एनालाइजर को जीरो-डेफिसिटिविटी से सुरक्षा प्रदान करता है

शून्य दिवस की धमकी

स्थैतिक विश्लेषण

सीवीई और सीडब्ल्यूई

निष्कर्ष

संबंधित लिंक

More articles: