स्रोत कोड विश्लेषण और स्वचालित शोषण पीढ़ी के बारे में

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



दरअसल, PH में IV पर स्रोत कोड सुरक्षा के विश्लेषण को स्वचालित करने के बारे में हमारे दृष्टिकोण के बारे में कहा जा सकता है कि सब कुछ पहले ही सर्गेई प्लेखोव और एलेक्सी मोस्कविन ने " सोर्स कोड द्वारा स्वचालित जनन की समस्याएँ " रिपोर्ट में कहा था। उन लोगों के लिए जो रिपोर्ट में मौजूद नहीं थे और इसकी रिकॉर्डिंग नहीं देखी थी, मैं आगे लेख पढ़ने से पहले ऐसा करने की सलाह देता हूं। हालांकि, इवान नोविकोव उर्फ @ d0znpp की रिपोर्ट के अंत में एक ही बार में "सवाल क्या है?" पर कई सवाल पूछे गए थे, "आपका दृष्टिकोण एक ही RIPS से अलग कैसे है?" और "आप प्रवेश बिंदु कैसे बनाते हैं?" कि आवेदन को तैनात किए बिना, शोषण करने के लिए आवश्यक बाहरी डेटा प्राप्त करना असंभव है (जैसे, उदाहरण के लिए, एक विशेषाधिकार प्राप्त उपयोगकर्ता का नाम और उसका पासवर्ड, प्रवेश बिंदुओं के लिए मार्ग, आदि)। मैं तुरंत एक आरक्षण करना चाहता हूं कि कुछ शब्दावली भ्रम है (हमारी तरफ से बिना शर्त के): नाम "स्रोत कोड द्वारा हमले वैक्टर के स्वचालित रूप से आउटपुट सेट की समस्याएं" बहुत अधिक सटीक रूप से एआई पर काम के दौरान हल किए गए कार्यों के सार को प्रतिबिंबित करेगा। कॉल करने के लिए एआई के आउटपुट पर जो शोषित के रूप में सामने आता है वह वास्तव में बिल्कुल सही नहीं है। यदि केवल इसलिए कि यह शब्द के पारंपरिक अर्थों में शोषण करने की तुलना में कूलर है :) और फिर मैं इस विचार को प्रकट करने की कोशिश करूंगा और अपने सहयोगियों को इवान द्वारा पूछे गए प्रश्नों के अधिक विस्तृत उत्तर के साथ पूरक करूंगा।

क्या है मामला?

सबसे पहले, मामला कोड में खामियों को खोजने और हमलों के कुछ वर्गों के लिए उनकी भेद्यता की पुष्टि करता है। इस मामले के ढांचे के भीतर स्वचालित शोषण पीढ़ी का कार्य एक भेद्यता के अस्तित्व की पुष्टि करते हुए, एक न्यूनतम हमले वेक्टर के निष्कर्ष पर आता है। उसी समय, एक वेक्टर एक विशिष्ट HTTP अनुरोध नहीं है, लेकिन कुछ कारकों का एक सेट है जो सिस्टम को भेद्यता की स्थिति में रखता है और उस पर एक सफल हमले की अनुमति देता है। मैं और भी अधिक कहूंगा: सामान्य मामले में, हमले के वेक्टर को केवल HTTP अनुरोध के रूप में व्यक्त करना संभव नहीं है। सबसे पहले, क्योंकि इस वेक्टर को कई प्रश्नों की आवश्यकता हो सकती है। दूसरे (और यह महत्वपूर्ण है), क्योंकि वेक्टर में कुछ पर्यावरणीय गुणों के लिए शर्तें शामिल हो सकती हैं जिन्हें HTTP अनुरोध के संदर्भ में वर्णित नहीं किया जा सकता है। फिर भी, विचाराधीन मामले के ढांचे के भीतर, हमें चाहिए: ए) ऐसी सभी शर्तों को प्राप्त करें; बी) किसी तरह विश्लेषण के परिणामों में उन्हें व्यवस्थित करें। यह ठीक वही है जो एक सदिश की इतनी जटिल परिभाषा की ओर ले जाता है। मैं आपको एक सरल उदाहरण दूंगा (इसके बाद हम ASP.NET वेब फॉर्म के लिए C # कोड पर विचार करेंगे)

var settings = Settings.ReadFromFile("settings.xml"); string str1; if (settings["key1"] == "validkey") { Response.Write(Request.Params["parm"]); } else { Response.Write("Wrong key!"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

जाहिर है, इस मामले में, XSS हमले के लिए भेद्यता सेटिंग। Xx कॉन्फ़िगरेशन फ़ाइल में key1 पैरामीटर के मूल्य पर निर्भर करती है। और, अगर हम ईमानदारी से इसे पढ़ते हैं (जो वास्तव में है, और प्रतीकात्मक रूप से Settings.eadFromFile ("settings.xml") को कॉल नहीं करते हैं और चर सेटिंग्स के परिणाम को असाइन करते हैं), तो हम केवल दो संभावित तरीकों में से एक के साथ जाएंगे। निष्पादन, जो अनिवार्य रूप से हमें भेद्यता को छोड़ने के लिए ले जाएगा यदि फ़ाइल में key1 "मान्य" के लिए सेट नहीं है। प्रतीकात्मक रूप से पहली कॉल करते हुए, हम अंत में निम्नलिखित सूत्र पर पहुंचेंगे, जो वांछित वेक्टर होगा:

 Settings.ReadFromFile("setings.xml")["key1"] == "validkey" -> {Request.Params["Parm"] = <script>alert(0)</script>}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

हम इसे HTTP शोषण से भी निकाल सकते हैं:

 GET http://host.domain/path/to/document.aspx?parm=%3Cscript%3Ealert%280%29%3C%2fscript%3E HTTP/1.1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

जो, हालांकि, आत्मनिर्भर नहीं है और यह वेब एप्लिकेशन के पर्यावरण पर लगाई गई शर्तों पर निर्भर करता है।



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



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



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

आपका दृष्टिकोण RIPS से अलग कैसे है?

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



शायद एक उदाहरण दिखाने के लिए बेहतर है। मान लें कि हमारे पास निम्नलिखित स्रोत कोड टुकड़ा है ^[१] :

 string name = Request.Params["name"]; string key1 = Request.Params["key1"]; string parm = Request.Params["parm"]; byte[] data; if (string.IsNullOrEmpty(parm)) { data = new byte[0]; } else { data = Convert.FromBase64String(parm); } string str1; if (name + "in" == "admin") { if (key1 == "validkey") { str1 = Encoding.UTF8.GetString(data); } else { str1 = "Wrong key!"; Response.Write(str1); return; } } else { str1 = "Wrong role!"; } Response.Write("<a href='http://host.domain' onclick='" + CustomSanitize(str1) + "'>Click me</a>");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

जाहिर है, दो बार संभावित खतरनाक ऑपरेशन होता है (इसके बाद PVO - संभावित रूप से कमजोर ऑपरेशन) - Response.Write विधि के लिए एक कॉल, जो सर्वर द्वारा उत्पन्न HTTP अनुरोध की प्रतिक्रिया की धारा को लिखता है। पहले मामले में, निरंतर "गलत कुंजी!" विधि को पारित कर दिया गया है, जो हमारे लिए कोई दिलचस्पी नहीं है। लेकिन दूसरे में, परिणाम एक तर्क के साथ CustomSanitize विधि को कॉल करने का परिणाम है, जिसके मूल्य की गणना प्राप्त अनुरोध के मापदंडों के मूल्यों से की जाती है। लेकिन एचटीएमएल मार्कअप तत्वों के इंजेक्शन के माध्यम से एक्सएसएस हमले की संभावना की पुष्टि करने के लिए वे हमारे लिए क्या होना चाहिए ताकि str1 में पर्याप्त मूल्य प्राप्त कर सकें? आइए देखें कि इस प्रश्न का उत्तर खोजने की प्रक्रिया कैसे दिख सकती है ^[२] ।



इसके साथ शुरू करने के लिए, हम दूसरे रिस्पांस के लिए पुन: सक्रियता की स्थिति प्राप्त करते हैं। इस तथ्य के बावजूद कि यह स्वयं किसी भी निर्माण में अंतर्निहित नहीं है जो नियंत्रण प्रवाह को प्रभावित करता है, कोड के पिछले ब्लॉकों में, फ़ंक्शन कॉमन से पूरे कोड तक एक वापसी होती है, जिसमें से रीचैबिलिटी स्थिति एक ही समय में हमारे पीवीओ की अप्राप्यता के लिए एक शर्त है। जाहिर है, वापसी के बयान के लिए निष्पादित की जाने वाली शर्त एक तार्किक अभिव्यक्ति है: (नाम == "प्रशंसा" && key1! = "Validkey")। इसलिए, इसकी अप्रतिस्पर्धीता की स्थिति अभिव्यक्ति होगी: (नाम! = "Adm" || name == "adm" && key1 == "validkey")। चूँकि यह रिटर्न एकमात्र ऐसा स्टेटमेंट है जो दूसरे रिस्पांस की रीचैबिलिटी को प्रभावित करता है। इसके अलावा, पीवीओ की रीचैबिलिटी के लिए अंतिम अभिव्यक्ति की स्थिति होगी।



वास्तव में, अभिव्यक्ति (नाम! = "Adm" || name == "adm" && key1 == "validkey") नियंत्रण प्रवाह ग्राफ़ पर PVO के लिए पथ बनाने के लिए हमें दो परस्पर अनन्य शर्तें प्रदान करता है। जब उनमें से प्रत्येक को निष्पादित किया जाता है, तो str1 के संभावित मूल्यों पर विचार करें। नाम (! = "Adm") के साथ, चर str1 को निरंतर "गलत भूमिका!" मिलती है, जो निश्चित रूप से हमें एक सफल हमले तक नहीं ले जा सकती है। लेकिन (नाम == "प्रशंसा" && key1 == "वैध") के साथ, str1 को डेटा तर्क के साथ एन्कोडिंग.UTF8.GetString विधि को कॉल करने का परिणाम मिलता है, जो बदले में दो मान ले सकता है: string के साथ नया बाइट [0] ।NNullOrEmpty (parm) और Convert.FromBase64String (parm) के साथ! string.sNullOrEmpty (Parm)। झुकाव के साथ निर्बाध त्याग। भेद्यता मूल्यों की शोषणशीलता और सभी प्रकार के मूल्यों को उनके दागी स्रोतों तक पहुंचाना, हम निम्नलिखित सूत्र प्राप्त करते हैं:

 (Request.Params["name"] == "adm" && Request.Params["key1"] == "validkey" && !string.IsNullOrEmpty(Request.Params["parm"])) -> Response.Write("<a href='http://host.domain' onclick='" + CustomSanitize(Convert.FromBase64String(Request.Params["parm"])) + "'>Click me</a>")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

इस मामले में निर्मित निष्पादन मॉडल का एक चित्रमय प्रतिनिधित्व (क्लिक करने योग्य) जैसा दिखेगा:





इस प्रकार, हमारे पास पहले से ही अनुरोध और नाम 1 मापदंडों का मूल्य है, और जो कुछ भी करना बाकी है वह Request.Params ["parm"] के मूल्य का पता लगाना है, जिस पर अभिव्यक्ति का अंतिम मूल्य CustomSanitize (Convert.FanBase64String (Request.Params) "parm है। »])) हमें XSS के लिए अग्रणी भेद्यता का शोषण देगा।



और यहाँ एक समस्या यह है कि स्थैतिक विश्लेषण के पारंपरिक साधन सामना नहीं कर सकते हैं। Convert.FromBase64String विधि एक पुस्तकालय विधि है और इसे व्युत्क्रम Convert.ToBase64String फ़ंक्शन के रूप में विश्लेषक ज्ञान आधार में वर्णित किया जा सकता है, जिससे हम यह निष्कर्ष निकाल सकते हैं कि CustomSanitize का परिणाम इनपुट Convert.ToBase64String पर जाना चाहिए। लेकिन CustomSanitize के साथ क्या करना है, जो एक पुस्तकालय नहीं है, कहीं भी वर्णित नहीं है और विश्लेषण के इस स्तर पर एक ब्लैक-एंड-ब्लैक बॉक्स है? ठीक है, अगर इस पद्धति के स्रोत हमारे लिए उपलब्ध हैं - इस मामले में, हम इसके शरीर में "के माध्यम से" गिर सकते हैं और ऊपर वर्णित तरीके से प्रतीकात्मक कोड निष्पादन जारी रख सकते हैं। लेकिन क्या होगा अगर कोई स्रोत कोड नहीं हैं? इसका उत्तर पिछले वाक्य में था: उस बारे में कुछ समय के लिए भूल जाना, हमारा विश्लेषण स्थिर है और इस पद्धति के साथ एक ब्लैक बॉक्स के रूप में काम करता है। हमारे पास पहले से परिवर्तित अभिव्यक्ति Convert.ToBase64String (CustomSanitize (Request.Params ["parm"]) है), कई संभावित XSS वैक्टर हैं (इसे {`<स्क्रिप्ट> अलर्ट (0) </ script>`, ``) करें। onmouseover = 'a [alert], [a] [.call (a [१], १) `और over onmouseover =" a [alert]; a [०] ।apply (a [१], [१]] `}) - तो क्यों अनुरोध को निर्दिष्ट करके इस फॉर्मूले को परिभाषित नहीं किया जाता है। Parsams [" parm "] वैक्टर के मूल्यों के साथ प्रतीक चर और सीधे परिणामस्वरूप अभिव्यक्ति को निष्पादित करता है?



मान लीजिए कि CustomSanitize केवल कोण ब्रैकेट वर्णों को निकालता है। फिर, फ़ज़िंग के परिणामस्वरूप, हमें तीन मान मिलते हैं:

 scriptalert(0)/script 'onmouseover='a[alert];a[0].call(a[1],1) "onmouseover="a[alert];a[0].apply(a[1],[1])
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

जिनमें से बाद के दो हमले वैक्टर के रूप में विचार के योग्य हैं। इसलिए हम जानते हैं कि पीवीओ तर्क के रूप में पूर्ण अभिव्यक्ति उत्तीर्ण हुई। हम उस सटीक स्थान को जानते हैं जहां वर्ण चर का मूल्य। Parsams ["parm"] गिर जाएगा जब यह वैक्टर के मूल्यों द्वारा निर्दिष्ट किया जाता है। इन दो वेक्टर से चुनने के लिए हमें और क्या चाहिए, जिनके उपयोग से इंजेक्शन लग जाएगा? जो लोग वेबिनार को ध्यान से सुनते हैं " एक सुरक्षित वेब एप्लिकेशन कैसे विकसित करें और एक ही समय में अपना दिमाग न खोएं? " तुरंत जवाब देंगे कि हमें किसी और चीज की आवश्यकता नहीं है :)



इस प्रकार इस कोड के विश्लेषण का अंतिम परिणाम एक प्रासंगिक है (पीवीओ निष्पादन के संदर्भ में प्रतीकात्मक चर के मूल्य को परिभाषित करना) शोषण:

 Request.Params["name"] = "adm" Request.Params["key1"] = "validkey" Request.Params["parm"] = "'onmouseover='a[alert];a[0].call(a[1],1)"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

जिसमें से HTTP (जो HTTP अनुरोध के वास्तविक मापदंडों के लिए आवश्यकताओं को परिभाषित करता है) का फायदा उठाना पहले से ही संभव है:

 GET http://host.domain/path/to/document.aspx?name=adm&key1=validkey&parm=%27onmouseover%3D%27a%5Balert%5D%3Ba%5B0%5D.call%28a%5B1%5D%2C1%29 HTTP/1.1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

एआई में, अगर दिलचस्पी है, तो यह इस तरह दिखता है (क्लिक करने योग्य):





बेशक, कठोर वास्तविकता में, सब कुछ थोड़ा अधिक जटिल है: यहां तक ​​कि एक फिल्टरिंग फ़ंक्शन द्वारा संशोधित वेक्टर भी "शूट" कर सकता है, जो इस तरह के कार्यों में नियमित अभिव्यक्तियों की उपस्थिति के साथ, निरंतर मूल्यों के बजाय उन्हें वर्णन करने वाले परिमित ऑटोमेटा में हेरफेर करने की आवश्यकता की ओर जाता है; तथ्य यह है कि क्वेरी के इनपुट पैरामीटर आउटपुट भाषा के एक मनमाने ढंग से व्याकरणिक निर्माण में चिपक सकते हैं, जिससे द्वीप भाषाओं, आदि के गुणों की पार्सिंग और / या अनुमानी निष्कर्ष की आवश्यकता होती है। आदि लेकिन ये पहले से ही व्यक्तिगत (और शायद थोड़ा अधिक वैज्ञानिक) लेखों के लिए विषय हैं। मैं केवल यह ध्यान देता हूं कि हमारे कार्य के हिस्से के रूप में, इन समस्याओं को भी सफलतापूर्वक हल किया गया है।

आपको प्रवेश बिंदु कैसे मिलते हैं?

सभी उदाहरणों में, मैंने जानबूझकर "/path/to/document.aspx" (यानी वेब एप्लिकेशन में प्रवेश बिंदु के लिए मार्ग) प्राप्त करने के प्रश्न को छोड़ दिया, क्योंकि इस कार्य के पास एक सार्वभौमिक समाधान नहीं है और इसके लिए विश्लेषक के ज्ञान आधार में विभिन्न रूपरेखाओं की बारीकियों का वर्णन करने की आवश्यकता है। ASP.NET Webforms के लिए, उदाहरण के लिए, प्रवेश बिंदु तथाकथित के हैंडलर तरीके हैं। वेब प्रपत्र नियंत्रण की पोस्टबैक (जिसके लिए पार्सिंग .aspx फ़ाइलों की आवश्यकता होती है और उन्हें संबंधित कोडबाइंड फ़ाइलों में लिंक करना होता है)। ASP.NET MVC में, रूट्सकोलिलेशन को सीधे अनुप्रयोग इनिशियलाइज़ेशन कोड में बदलकर मार्गों को परिभाषित किया जाता है। हमें urlMappings, urlrewritingnet और इस तरह के अनुभागों की WebConfig में उपस्थिति की संभावना के बारे में नहीं भूलना चाहिए, जो कि आवेदन के लिए HTTP अनुरोधों के मार्ग को भी प्रभावित करता है। और कुछ भी नहीं डेवलपर को अपने स्वयं के HTTP हैंडलर को परिभाषित करने से रोकता है जो कस्टम रूटिंग लॉजिक को लागू करता है, जिसका रिवर्स एक एल्गोरिदमिक रूप से अघुलनशील कार्य है। इस मामले में, हमारे पास जावा / सी # या PHP के मामले में सभी .php फ़ाइलों के मामले में प्रविष्टि के सभी सार्वजनिक और संरक्षित तरीकों के रूप में विचार करने के अलावा कोई विकल्प नहीं है, जो बाहरी से अप्राप्य कोड पर झूठे-सकारात्मक को पकड़ने की बढ़ती संभावना के लिए इस्तीफा दे दिया। हालाँकि, जीवित है, मैंने व्यक्तिगत रूप से ऐसे .NET अनुप्रयोगों को अभी तक नहीं देखा है, और PHP फ्रेमवर्क के मौजूदा चिड़ियाघर, हालांकि प्रेरणादायक है, विश्लेषक के ज्ञान आधार में काफी औपचारिक है, जिसमें प्रवेश बिंदुओं के लिए मार्ग प्राप्त करने से संबंधित भाग शामिल है। विदेशी, जैसे कि डेटाबेस में रूटिंग के नियमों का वर्णन करना, जैसा कि यह पहले से ही स्पष्ट है, हम अभी भी सभी संभावित प्रवेश बिंदुओं के उपरोक्त प्रत्यक्ष गणना को संसाधित कर रहे हैं (जो, वैसे, खराब परिणाम नहीं देता है क्योंकि यह पहली नज़र में लगता है)।

बस इतना ही

मुझे उम्मीद है कि मैं अभी भी इन सवालों का जवाब देने में कामयाब रहा। लेकिन अगर अचानक नए पैदा होते हैं, या असंगत क्षण रहते हैं - आपका स्वागत है, जैसा कि वे कहते हैं :)

---

1. The तुरंत, मैं एक आरक्षण करूँगा कि उदाहरण निश्चित रूप से सिंथेटिक है और एक लिविंग सिस्टम से कुछ वास्तविक उदाहरण के बजाय औसत घटिया कोड का विश्लेषण करने के तरीके में संभावित समस्याओं का प्रदर्शन करना है। यदि पाठकों में से कोई कोड विखंडन के अपने स्वयं के संस्करण की पेशकश करना चाहता है, तो विश्लेषण प्रक्रिया पर विचार करना संभव होगा और यह बिल्कुल भी सवाल नहीं है
2. Of विश्लेषण प्रक्रिया के चरण-दर-चरण निष्पादन का वर्णन यहां तक ​​कि इस तरह के एक सरल कोड के परिणामस्वरूप समान तार्किक सूत्रों के परिवर्तनों की एक बहु-पृष्ठ श्रृंखला होगी, इसलिए, गणना यहां नहीं दी गई हैं। रुचि रखने वाले लोग लेख की शुरुआत में उल्लिखित रिपोर्ट की रिकॉर्डिंग में दृष्टिकोण और इसके व्यक्तिगत चरणों के विस्तृत विवरण के साथ खुद को परिचित कर सकते हैं।