सिद्धांत और व्यवहार में कमजोरियों का पता लगाना, या कोई आदर्श स्थैतिक विश्लेषक क्यों नहीं है

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

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

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

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

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

कोई सार्वभौमिक स्थिर विश्लेषक क्यों नहीं है जो किसी भी कोड की पूरी तरह से जांच करेगा और झूठी सकारात्मकता के बिना उसमें सभी दोषों को ढूंढेगा और साथ ही साथ जल्दी से काम करेगा और बहुत सारे संसाधनों (सीपीयू समय और मेमोरी) की आवश्यकता नहीं है?

स्थिर विश्लेषणकर्ताओं की वास्तुकला के बारे में थोड़ा

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

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



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

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

स्थैतिक विश्लेषण के लिए अनुकूलन रूपांतरण

स्थिर विश्लेषक के लिए स्मृति और समय में कुशलता से काम करने के लिए, आपके पास एक कॉम्पैक्ट सार्वभौमिक आंतरिक प्रतिनिधित्व होना चाहिए, और यह इस तथ्य से प्राप्त किया जा सकता है कि आंतरिक प्रतिनिधित्व कई पेड़ों में विभाजित है, जिनमें से प्रत्येक को संबंधित प्रोग्रामिंग भाषाओं के लिए डिज़ाइन किया गया है।

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

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

जाहिर है, इन परिवर्तनों में से प्रत्येक को उन दोषों को "खो देता है" जो विश्लेषक को पता लगाने चाहिए, लेकिन यह स्मृति दक्षता और प्रदर्शन के लिए "शुल्क" है।

एक स्थिर कोड विश्लेषक क्या है?

सशर्त रूप से, दोष जो किसी तरह से घुसपैठियों में रुचि रखते हैं, और इसलिए, लेखा परीक्षकों को निम्नलिखित समूहों में विभाजित किया जा सकता है:

• सत्यापन की त्रुटियां
• सूचना रिसाव की त्रुटियाँ,
• प्रमाणीकरण त्रुटियां।

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

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

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

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

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

मेमोरी त्रुटियां

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

विशिष्ट मेमोरी त्रुटियों में उपयोग-बाद-मुक्त , डबल-फ्री , नल-पॉइंटर-डीरेफेरेंस और उनकी किस्में शामिल हैं, उदाहरण के लिए, आउट-ऑफ-बाउंड्स-रीड और आउट-ऑफ-बाउंड-राइट ।

जब अगला विश्लेषक मेमोरी लीक का पता लगाने में विफल रहा, तो आप सुन सकते हैं कि ऐसे दोषों का शोषण करना मुश्किल है। एक हमलावर को अत्यधिक योग्य होना चाहिए और बहुत सारे कौशल को लागू करना चाहिए, सबसे पहले, कोड में इस तरह की खराबी की उपस्थिति के बारे में पता लगाना और, दूसरा, शोषण करने के लिए। ठीक है, यह तर्क आगे बढ़ता है: "क्या आपको यकीन है कि आपका सॉफ़्टवेयर उत्पाद इस तरह के स्तर के गुरु के लिए दिलचस्प है?" ... हालांकि, इतिहास ऐसे मामलों को जानता है जब स्मृति त्रुटियों का सफलतापूर्वक शोषण किया गया था और इससे काफी नुकसान हुआ था। उदाहरण के रूप में, आप इस तरह की प्रसिद्ध स्थितियों का हवाला दे सकते हैं:

1. CVE-2014-0160 - खुलने वाली लाइब्रेरी में एक त्रुटि - निजी कुंजी के एक संभावित समझौते के लिए सभी प्रमाणपत्रों और पासवर्ड पुनर्जनन की आवश्यकता होती है।
2. CVE-2015-2712 - मोज़िला फ़ायरफ़ॉक्स में js कार्यान्वयन में बग - सीमा जाँच।
3. CVE-2010-1117 - इंटरनेट एक्सप्लोरर में मुफ्त के बाद उपयोग - दूर से शोषक।
4. CVE-2018-4913 - एक्रोबेट रीडर में मुफ्त के बाद उपयोग - कोड निष्पादन।

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

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


स्थैतिक विश्लेषक को सही ढंग से कैसे संचालित किया जाए, यह हमारे ब्लॉग में पढ़ी गई जानकारी के साथ सही ढंग से और कुशलता से काम करता है।