फज़िंग: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
Line 2: Line 2:
{{Information security}}
{{Information security}}


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


सुरक्षा के उद्देश्य से, एक [[विश्वास सीमा]] को पार करने वाला इनपुट अक्सर सबसे उपयोगी होता है।<ref name="neystadt"/>उदाहरण के लिए, फ़ज़ कोड के लिए यह अधिक महत्वपूर्ण है जो किसी भी उपयोगकर्ता द्वारा फ़ाइल के अपलोड को संभालता है, उस कोड को फ़ज़ करना है जो कॉन्फ़िगरेशन फ़ाइल को पार्स करता है जो केवल एक विशेषाधिकार प्राप्त उपयोगकर्ता के लिए पहुंच योग्य है।
सुरक्षा के उद्देश्य से, एक [[विश्वास सीमा]] को पार करने वाला इनपुट अक्सर सबसे उपयोगी होता है।<ref name="neystadt"/>उदाहरण के लिए, फ़ज़ कोड के लिए यह अधिक महत्वपूर्ण है जो किसी भी उपयोगकर्ता द्वारा फ़ाइल के अपलोड को संभालता है, उस कोड को फ़ज़ करना है जो कॉन्फ़िगरेशन फ़ाइल को पार्स करता है जो केवल एक विशेषाधिकार प्राप्त उपयोगकर्ता के लिए पहुंच योग्य है।
Line 10: Line 10:
फ़ज़ शब्द की उत्पत्ति 1988 के पतन वर्ग की परियोजना से हुई है<ref name="fuzz-cs736"/>स्नातक उन्नत ऑपरेटिंग सिस्टम वर्ग (CS736) में, विस्कॉन्सिन विश्वविद्यालय में प्रोफेसर बार्टन मिलर द्वारा पढ़ाया गया, जिसके परिणाम बाद में 1990 में प्रकाशित हुए।<ref name="fuzz1990"/>यूटिलिटी के लिए स्वचालित रूप से यादृच्छिक इनपुट और कमांड-लाइन पैरामीटर उत्पन्न करने के लिए एक UNIX उपयोगिता का परीक्षण करने के लिए। प्रोजेक्ट को [[यूनिक्स]] कमांड लाइन कार्यक्रमों की विश्वसनीयता का परीक्षण करने के लिए डिज़ाइन किया गया था जब तक कि वे दुर्घटनाग्रस्त होने तक त्वरित उत्तराधिकार में बड़ी संख्या में यादृच्छिक इनपुट निष्पादित कर सकें। मिलर की टीम 25 से 33 प्रतिशत उपयोगिताओं को क्रैश करने में सक्षम थी, जिनका उन्होंने परीक्षण किया था। फिर उन्होंने कारण निर्धारित करने के लिए प्रत्येक क्रैश को डिबग किया और प्रत्येक ज्ञात विफलता को वर्गीकृत किया। अन्य शोधकर्ताओं को अन्य सॉफ्टवेयर के साथ समान प्रयोग करने की अनुमति देने के लिए, उपकरणों के स्रोत कोड, परीक्षण प्रक्रियाओं और कच्चे परिणाम डेटा को सार्वजनिक रूप से उपलब्ध कराया गया।<ref name="AutoDO-2"/>इस शुरुआती फ़ज़िंग को अब ब्लैक बॉक्स, जेनरेशनल, अनस्ट्रक्चर्ड (डंब) फ़ज़िंग कहा जाएगा।
फ़ज़ शब्द की उत्पत्ति 1988 के पतन वर्ग की परियोजना से हुई है<ref name="fuzz-cs736"/>स्नातक उन्नत ऑपरेटिंग सिस्टम वर्ग (CS736) में, विस्कॉन्सिन विश्वविद्यालय में प्रोफेसर बार्टन मिलर द्वारा पढ़ाया गया, जिसके परिणाम बाद में 1990 में प्रकाशित हुए।<ref name="fuzz1990"/>यूटिलिटी के लिए स्वचालित रूप से यादृच्छिक इनपुट और कमांड-लाइन पैरामीटर उत्पन्न करने के लिए एक UNIX उपयोगिता का परीक्षण करने के लिए। प्रोजेक्ट को [[यूनिक्स]] कमांड लाइन कार्यक्रमों की विश्वसनीयता का परीक्षण करने के लिए डिज़ाइन किया गया था जब तक कि वे दुर्घटनाग्रस्त होने तक त्वरित उत्तराधिकार में बड़ी संख्या में यादृच्छिक इनपुट निष्पादित कर सकें। मिलर की टीम 25 से 33 प्रतिशत उपयोगिताओं को क्रैश करने में सक्षम थी, जिनका उन्होंने परीक्षण किया था। फिर उन्होंने कारण निर्धारित करने के लिए प्रत्येक क्रैश को डिबग किया और प्रत्येक ज्ञात विफलता को वर्गीकृत किया। अन्य शोधकर्ताओं को अन्य सॉफ्टवेयर के साथ समान प्रयोग करने की अनुमति देने के लिए, उपकरणों के स्रोत कोड, परीक्षण प्रक्रियाओं और कच्चे परिणाम डेटा को सार्वजनिक रूप से उपलब्ध कराया गया।<ref name="AutoDO-2"/>इस शुरुआती फ़ज़िंग को अब ब्लैक बॉक्स, जेनरेशनल, अनस्ट्रक्चर्ड (डंब) फ़ज़िंग कहा जाएगा।


1990 के इस फ़ज़ पेपर ने सुरक्षा के साथ विश्वसनीयता के संबंध को भी नोट किया: दूसरा, एक बग जो हमने पाया वह उसी प्रोग्रामिंग अभ्यास के कारण हुआ था जिसने इंटरनेट वर्म ('गेट्स फिंगर' बग) को एक सुरक्षा छेद प्रदान किया था। हमें अतिरिक्त बग मिले हैं जो भविष्य में सुरक्षा खामियों का संकेत दे सकते हैं। (नवंबर 1988 के [[मॉरिस कीड़ा]] का जिक्र करते हुए।)
1990 के इस फ़ज़ पेपर ने सुरक्षा के साथ विश्वसनीयता के संबंध को भी नोट किया: दूसरा, एक बग जो हमने पाया वह उसी प्रोग्रामिंग अभ्यास के कारण हुआ था जिसने इंटरनेट वर्म ('गेट्स फिंगर' बग) को एक सुरक्षा छेद प्रदान किया था। हमें अतिरिक्त बग मिले है जो भविष्य में सुरक्षा खामियों का संकेत दे सकते है। (नवंबर 1988 के [[मॉरिस कीड़ा]] का जिक्र करते हुए।)


मूल फज़ परियोजना ने 1995, 2000, 2006 और हाल ही में 2020 में योगदान दिया:
मूल फज़ परियोजना ने 1995, 2000, 2006 और हाल ही में 2020 में योगदान दिया:
* 1995:<ref name="fuzz1995"/>फ़ज़ रिविज़िटेड पेपर में चार भाग होते हैं।
* 1995:<ref name="fuzz1995"/>फ़ज़ रिविज़िटेड पेपर में चार भाग होते है।
*# UNIX सिस्टम की व्यापक विविधता और अधिक उपयोगिताओं सहित मूल कमांड लाइन अध्ययन को पुन: प्रस्तुत किया। अध्ययन से पता चला कि, अगर कुछ भी, विश्वसनीयता खराब हो गई थी। यह पहला अध्ययन था जिसमें ओपन सोर्स [[जीएनयू]] और [[लिनक्स]] उपयोगिताओं को शामिल किया गया था, जो दिलचस्प रूप से वाणिज्यिक यूनिक्स सिस्टम की तुलना में काफी अधिक विश्वसनीय थे।
*# UNIX सिस्टम की व्यापक विविधता और अधिक उपयोगिताओं सहित मूल कमांड लाइन अध्ययन को पुन: प्रस्तुत किया। अध्ययन से पता चला कि, अगर कुछ भी, विश्वसनीयता खराब हो गई थी। यह पहला अध्ययन था जिसमें ओपन सोर्स [[जीएनयू]] और [[लिनक्स]] उपयोगिताओं को शामिल किया गया था, जो दिलचस्प रूप से वाणिज्यिक यूनिक्स सिस्टम की तुलना में काफी अधिक विश्वसनीय थे।
*# एक्स-विंडोज़ के तहत जीयूआई (विंडो आधारित) अनुप्रयोगों के फ़ज़ परीक्षण का परिचय दिया। इस अध्ययन में असंरचित और संरचित (माउस और कीबोर्ड घटनाओं के मान्य अनुक्रम) इनपुट डेटा दोनों का उपयोग किया गया। वे X-Windows अनुप्रयोगों के 25% को क्रैश करने में सक्षम थे। इसके अलावा, उन्होंने एक्स-विंडोज सर्वर का परीक्षण किया और दिखाया कि यह क्रैश के लिए लचीला था।
*# एक्स-विंडोज़ के तहत जीयूआई (विंडो आधारित) अनुप्रयोगों के फ़ज़ परीक्षण का परिचय दिया। इस अध्ययन में असंरचित और संरचित (माउस और कीबोर्ड घटनाओं के मान्य अनुक्रम) इनपुट डेटा दोनों का उपयोग किया गया। वे X-Windows अनुप्रयोगों के 25% को क्रैश करने में सक्षम थे। इसके अलावा, उन्होंने एक्स-विंडोज सर्वर का परीक्षण किया और दिखाया कि यह क्रैश के लिए लचीला था।
Line 23: Line 23:
* 2020:<ref name="fuzz2020"/>हाल ही में, उन्होंने यह देखने के लिए कि क्या मूल तकनीकें अभी भी प्रासंगिक थीं और क्या वर्तमान उपयोगिता कार्यक्रम इस प्रकार के परीक्षण के लिए प्रतिरोधी थे, क्लासिक जेनरेशनल, ब्लैक बॉक्स, वर्तमान UNIX सिस्टम, विशेष रूप से Linux, [[FreeBSD]] और MacOS पर असंरचित परीक्षण लागू किया। उन्होंने प्रत्येक प्लेटफॉर्म पर लगभग 75 उपयोगिताओं का परीक्षण किया, लिनक्स पर 12% की विफलता दर, मैकओएस पर 16% और फ्रीबीएसडी पर 19%। (ध्यान दें कि ये विफलता दर समान प्रणालियों के पिछले परीक्षण के परिणामों से भी बदतर थे।) जब उन्होंने प्रत्येक विफलता का विश्लेषण किया और उन्हें वर्गीकृत किया, तो उन्होंने पाया कि विफलताओं की क्लासिक श्रेणियां, जैसे सूचक और सरणी त्रुटियां और रिटर्न कोड की जांच नहीं करना, नए परिणामों में मोटे तौर पर अभी भी मौजूद थे। इसके अलावा, नई विफलता जटिल प्रोग्राम स्थिति और एल्गोरिदम से उत्पन्न होती है जो इनपुट आकार या जटिलता के साथ स्केल नहीं करती थी। उन्होंने हाल ही में रस्ट में लिखी गई UNIX उपयोगिताओं का भी परीक्षण किया और पाया कि वे C में लिखी गई समान विश्वसनीयता की थीं, हालांकि (उम्मीद के मुताबिक) स्मृति त्रुटियों की संभावना कम थी।
* 2020:<ref name="fuzz2020"/>हाल ही में, उन्होंने यह देखने के लिए कि क्या मूल तकनीकें अभी भी प्रासंगिक थीं और क्या वर्तमान उपयोगिता कार्यक्रम इस प्रकार के परीक्षण के लिए प्रतिरोधी थे, क्लासिक जेनरेशनल, ब्लैक बॉक्स, वर्तमान UNIX सिस्टम, विशेष रूप से Linux, [[FreeBSD]] और MacOS पर असंरचित परीक्षण लागू किया। उन्होंने प्रत्येक प्लेटफॉर्म पर लगभग 75 उपयोगिताओं का परीक्षण किया, लिनक्स पर 12% की विफलता दर, मैकओएस पर 16% और फ्रीबीएसडी पर 19%। (ध्यान दें कि ये विफलता दर समान प्रणालियों के पिछले परीक्षण के परिणामों से भी बदतर थे।) जब उन्होंने प्रत्येक विफलता का विश्लेषण किया और उन्हें वर्गीकृत किया, तो उन्होंने पाया कि विफलताओं की क्लासिक श्रेणियां, जैसे सूचक और सरणी त्रुटियां और रिटर्न कोड की जांच नहीं करना, नए परिणामों में मोटे तौर पर अभी भी मौजूद थे। इसके अलावा, नई विफलता जटिल प्रोग्राम स्थिति और एल्गोरिदम से उत्पन्न होती है जो इनपुट आकार या जटिलता के साथ स्केल नहीं करती थी। उन्होंने हाल ही में रस्ट में लिखी गई UNIX उपयोगिताओं का भी परीक्षण किया और पाया कि वे C में लिखी गई समान विश्वसनीयता की थीं, हालांकि (उम्मीद के मुताबिक) स्मृति त्रुटियों की संभावना कम थी।


अप्रैल 2012 में, Google ने [[क्रोमियम वेब ब्राउज़र]] के सुरक्षा-महत्वपूर्ण घटकों के लिए क्लाउड-आधारित फ़ज़िंग इंफ्रास्ट्रक्चर क्लस्टरफ़ज़ की घोषणा की।<ref name="clusterfuzz"/>यदि ClusterFuzz को अपलोड किए गए फ़ज़र के साथ क्रैश होने का पता चलता है, तो सुरक्षा शोधकर्ता अपने स्वयं के फ़ज़र्स अपलोड कर सकते हैं और बग बाउंटी एकत्र कर सकते हैं।
अप्रैल 2012 में, Google ने [[क्रोमियम वेब ब्राउज़र]] के सुरक्षा-महत्वपूर्ण घटकों के लिए क्लाउड-आधारित फ़ज़िंग इंफ्रास्ट्रक्चर क्लस्टरफ़ज़ की घोषणा की।<ref name="clusterfuzz"/>यदि ClusterFuzz को अपलोड किए गए फ़ज़र के साथ क्रैश होने का पता चलता है, तो सुरक्षा शोधकर्ता अपने स्वयं के फ़ज़र्स अपलोड कर सकते है और बग बाउंटी एकत्र कर सकते है।


सितंबर 2014 में, [[शेलशॉक (सॉफ्टवेयर बग)]]<ref name="NYT-20140925-NP">{{cite news |last=Perlroth |first=Nicole |title=सुरक्षा विशेषज्ञ बैश में 'शेलशॉक' सॉफ्टवेयर बग के महत्वपूर्ण होने की अपेक्षा करते हैं|url=https://www.nytimes.com/2014/09/26/technology/security-experts-expect-shellshock-software-bug-to-be-significant.html |date=25 September 2014 |work=[[The New York Times]] |access-date=25 September 2014}}</ref> व्यापक रूप से उपयोग किए जाने वाले यूनिक्स [[बैश (यूनिक्स शेल)]] [[ खोल (कंप्यूटिंग) ]] में [[सुरक्षा बग]]ों के परिवार के रूप में खुलासा किया गया था; शेलशॉक की अधिकांश भेद्यताएं [[अमेरिकन फ़ज़ी लोप (फ़ज़र)]]फ़ज़र) का उपयोग करके पाई गईं।<ref>{{cite web|url=http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html|title=Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78)|date=1 October 2014|website=lcamtuf's blog|last1=Zalewski|first1=Michał|access-date=13 March 2017}}</ref> (कई इंटरनेट-फेसिंग सेवाएं, जैसे कि कुछ वेब सर्वर परिनियोजन, कुछ अनुरोधों को संसाधित करने के लिए बैश का उपयोग करती हैं, एक हमलावर को [[मनमाना कोड निष्पादन]] के लिए बैश के कमजोर संस्करणों का कारण बनने की अनुमति देती हैं। यह एक हमलावर को कंप्यूटर सिस्टम पर अनधिकृत पहुंच प्राप्त करने की अनुमति दे सकता है।<ref name="ZDN-20140929">{{cite web|last=Seltzer |first=Larry |title=शेलशॉक हार्टब्लीड को महत्वहीन बना देता है|url=http://www.zdnet.com/shellshock-makes-heartbleed-look-insignificant-7000034143/ |date=29 September 2014 |publisher=[[ZDNet]] |access-date=29 September 2014}}</ref>)
सितंबर 2014 में, [[शेलशॉक (सॉफ्टवेयर बग)]]<ref name="NYT-20140925-NP">{{cite news |last=Perlroth |first=Nicole |title=सुरक्षा विशेषज्ञ बैश में 'शेलशॉक' सॉफ्टवेयर बग के महत्वपूर्ण होने की अपेक्षा करते हैं|url=https://www.nytimes.com/2014/09/26/technology/security-experts-expect-shellshock-software-bug-to-be-significant.html |date=25 September 2014 |work=[[The New York Times]] |access-date=25 September 2014}}</ref> व्यापक रूप से उपयोग किए जाने वाले यूनिक्स [[बैश (यूनिक्स शेल)]] [[ खोल (कंप्यूटिंग) ]] में [[सुरक्षा बग]]ों के परिवार के रूप में खुलासा किया गया था; शेलशॉक की अधिकांश भेद्यताएं [[अमेरिकन फ़ज़ी लोप (फ़ज़र)]]फ़ज़र) का उपयोग करके पाई गईं।<ref>{{cite web|url=http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html|title=Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78)|date=1 October 2014|website=lcamtuf's blog|last1=Zalewski|first1=Michał|access-date=13 March 2017}}</ref> (कई इंटरनेट-फेसिंग सेवाएं, जैसे कि कुछ वेब सर्वर परिनियोजन, कुछ अनुरोधों को संसाधित करने के लिए बैश का उपयोग करती है, एक हमलावर को [[मनमाना कोड निष्पादन]] के लिए बैश के कमजोर संस्करणों का कारण बनने की अनुमति देती है। यह एक हमलावर को कंप्यूटर सिस्टम पर अनधिकृत पहुंच प्राप्त करने की अनुमति दे सकता है।<ref name="ZDN-20140929">{{cite web|last=Seltzer |first=Larry |title=शेलशॉक हार्टब्लीड को महत्वहीन बना देता है|url=http://www.zdnet.com/shellshock-makes-heartbleed-look-insignificant-7000034143/ |date=29 September 2014 |publisher=[[ZDNet]] |access-date=29 September 2014}}</ref>)


अप्रैल 2015 में, हन्नो बॉक ने दिखाया कि कैसे फजर एएफएल 2014 हार्टब्लीड भेद्यता को ढूंढ सकता था।<ref>{{cite web|last1=Böck|first1=Hanno|title=Fuzzing: Wie man Heartbleed hätte finden können (in German)|url=http://www.golem.de/news/fuzzing-wie-man-heartbleedhaette-finden-koennen-1504-113345.html|website=Golem.de|access-date=13 March 2017|language=de-DE}}</ref><ref>{{cite web|last1=Böck|first1=Hanno|title=हार्टब्लीड कैसे पाया जा सकता था (अंग्रेज़ी में)|url=https://blog.hboeck.de/archives/868-How-Heartbleed-couldve-been-found.html|website=Hanno's blog|access-date=13 March 2017}}</ref> (अप्रैल 2014 में [[ हार्दिक ]] भेद्यता का खुलासा किया गया था। यह एक गंभीर भेद्यता है जो विरोधियों को अन्यथा [[एन्क्रिप्टेड संचार]] को समझने की अनुमति देती है। भेद्यता को गलती से [[ओपनएसएसएल]] में पेश किया गया था जो [[ परिवहन परत सुरक्षा ]] को लागू करता है और इंटरनेट पर अधिकांश सर्वरों द्वारा उपयोग किया जाता है। [[शोडान (वेबसाइट)]] ने अप्रैल 2016 में 238,000 मशीनों के अभी भी असुरक्षित होने की सूचना दी;<ref>{{cite web|url=https://www.shodan.io/report/89bnfUyJ|title=Search engine for the internet of things – devices still vulnerable to Heartbleed|website=shodan.io|access-date=13 March 2017}}</ref> जनवरी 2017 में 200,000।<ref>{{cite web|url=https://www.shodan.io/report/DCPO7BkV|title=Heartbleed Report (2017-01)|website=shodan.io|access-date=10 July 2017}}</ref>)
अप्रैल 2015 में, हन्नो बॉक ने दिखाया कि कैसे फजर एएफएल 2014 हार्टब्लीड भेद्यता को ढूंढ सकता था।<ref>{{cite web|last1=Böck|first1=Hanno|title=Fuzzing: Wie man Heartbleed hätte finden können (in German)|url=http://www.golem.de/news/fuzzing-wie-man-heartbleedhaette-finden-koennen-1504-113345.html|website=Golem.de|access-date=13 March 2017|language=de-DE}}</ref><ref>{{cite web|last1=Böck|first1=Hanno|title=हार्टब्लीड कैसे पाया जा सकता था (अंग्रेज़ी में)|url=https://blog.hboeck.de/archives/868-How-Heartbleed-couldve-been-found.html|website=Hanno's blog|access-date=13 March 2017}}</ref> (अप्रैल 2014 में [[ हार्दिक ]] भेद्यता का खुलासा किया गया था। यह एक गंभीर भेद्यता है जो विरोधियों को अन्यथा [[एन्क्रिप्टेड संचार]] को समझने की अनुमति देती है। भेद्यता को गलती से [[ओपनएसएसएल]] में पेश किया गया था जो [[ परिवहन परत सुरक्षा ]] को लागू करता है और इंटरनेट पर अधिकांश सर्वरों द्वारा उपयोग किया जाता है। [[शोडान (वेबसाइट)]] ने अप्रैल 2016 में 238,000 मशीनों के अभी भी असुरक्षित होने की सूचना दी;<ref>{{cite web|url=https://www.shodan.io/report/89bnfUyJ|title=Search engine for the internet of things – devices still vulnerable to Heartbleed|website=shodan.io|access-date=13 March 2017}}</ref> जनवरी 2017 में 200,000।<ref>{{cite web|url=https://www.shodan.io/report/DCPO7BkV|title=Heartbleed Report (2017-01)|website=shodan.io|access-date=10 July 2017}}</ref>)
Line 42: Line 42:
== प्रारंभिक यादृच्छिक परीक्षण ==
== प्रारंभिक यादृच्छिक परीक्षण ==


यादृच्छिक इनपुट के साथ परीक्षण कार्यक्रम 1950 के दशक के हैं जब डेटा अभी भी [[पंच कार्ड युग में कंप्यूटर प्रोग्रामिंग]] पर संग्रहीत था।<ref name="weinberg"/>प्रोग्रामर कंप्यूटर प्रोग्राम के इनपुट के रूप में छिद्रित कार्ड का उपयोग करेंगे जो यादृच्छिक संख्याओं के ट्रैश या कार्ड डेक से खींचे गए थे। यदि किसी निष्पादन से अवांछित व्यवहार का पता चलता है, तो एक सॉफ़्टवेयर बग का पता चला था।
यादृच्छिक इनपुट के साथ परीक्षण कार्यक्रम 1950 के दशक के है जब डेटा अभी भी [[पंच कार्ड युग में कंप्यूटर प्रोग्रामिंग]] पर संग्रहीत था।<ref name="weinberg"/>प्रोग्रामर कंप्यूटर प्रोग्राम के इनपुट के रूप में छिद्रित कार्ड का उपयोग करेंगे जो यादृच्छिक संख्याओं के ट्रैश या कार्ड डेक से खींचे गए थे। यदि किसी निष्पादन से अवांछित व्यवहार का पता चलता है, तो एक सॉफ़्टवेयर बग का पता चला था।


रैंडम इनपुट के निष्पादन को [[ यादृच्छिक परीक्षण ]] या [[ बंदर परीक्षण ]] भी कहा जाता है।
रैंडम इनपुट के निष्पादन को [[ यादृच्छिक परीक्षण ]] या [[ बंदर परीक्षण ]] भी कहा जाता है।
Line 54: Line 54:


== प्रकार ==
== प्रकार ==
एक फजर को कई तरह से वर्गीकृत किया जा सकता है:<ref name="sutton"/><ref name="neystadt"/># एक फ़ज़र जनरेशन-आधारित या म्यूटेशन-आधारित हो सकता है, जो इस बात पर निर्भर करता है कि इनपुट स्क्रैच से उत्पन्न हुए हैं या मौजूदा इनपुट को संशोधित करके।
एक फजर को कई तरह से वर्गीकृत किया जा सकता है:<ref name="sutton"/><ref name="neystadt"/># एक फ़ज़र जनरेशन-आधारित या म्यूटेशन-आधारित हो सकता है, जो इस बात पर निर्भर करता है कि इनपुट स्क्रैच से उत्पन्न हुए है या मौजूदा इनपुट को संशोधित करके।
# एक फजर गूंगा (असंरचित) या स्मार्ट (संरचित) हो सकता है, यह इस बात पर निर्भर करता है कि वह इनपुट संरचना से अवगत है या नहीं।
# एक फजर गूंगा (असंरचित) या स्मार्ट (संरचित) हो सकता है, यह इस बात पर निर्भर करता है कि वह इनपुट संरचना से अवगत है या नहीं।
# एक फ़ज़र सफ़ेद-, ग्रे- या ब्लैक-बॉक्स हो सकता है, यह इस बात पर निर्भर करता है कि वह प्रोग्राम संरचना से अवगत है या नहीं।
# एक फ़ज़र सफ़ेद-, ग्रे- या ब्लैक-बॉक्स हो सकता है, यह इस बात पर निर्भर करता है कि वह प्रोग्राम संरचना से अवगत है या नहीं।
Line 60: Line 60:
=== मौजूदा इनपुट बीजों का पुन: उपयोग ===
=== मौजूदा इनपुट बीजों का पुन: उपयोग ===


म्यूटेशन-आधारित फ़ज़र फ़ज़िंग के दौरान बीज इनपुट के मौजूदा कॉर्पस का लाभ उठाता है। यह प्रदान किए गए बीजों को संशोधित (या बल्कि उत्परिवर्तन (आनुवांशिक एल्गोरिथम)) करके इनपुट उत्पन्न करता है।<ref>{{cite journal|last1=Offutt|first1=Jeff|last2=Xu|first2=Wuzhi|title=डेटा गड़बड़ी का उपयोग करके वेब सेवाओं के लिए टेस्ट केस तैयार करना|journal=Workshop on Testing, Analysis and Verification of Web Services|year=2004|volume=29|issue=5|pages=1–10|doi=10.1145/1022494.1022529|s2cid=52854851|url=https://dl.acm.org/citation.cfm?id=1022529}}</ref> उदाहरण के लिए, छवि लाइब्रेरी [[libpng]] को फ़ज़ करते समय, उपयोगकर्ता मान्य [[पोर्टेबल नेटवर्क ग्राफ़िक्स]] छवि फ़ाइलों का एक सेट बीज के रूप में प्रदान करेगा, जबकि एक उत्परिवर्तन-आधारित फ़ज़र इन बीजों को प्रत्येक बीज के अर्ध-वैध वेरिएंट का उत्पादन करने के लिए संशोधित करेगा। बीज फ़ाइलों के कॉर्पस में हजारों संभावित समान इनपुट हो सकते हैं। स्वचालित बीज चयन (या परीक्षण सूट में कमी) उपयोगकर्ताओं को फ़ज़ अभियान के दौरान पाए जाने वाले बगों की कुल संख्या को अधिकतम करने के लिए सर्वोत्तम बीज चुनने की अनुमति देता है।<ref>{{cite journal|last1=Rebert|first1=Alexandre|last2=Cha|first2=Sang Kil|last3=Avgerinos|first3=Thanassis|last4=Foote|first4=Jonathan|last5=Warren|first5=David|last6=Grieco|first6=Gustavo|last7=Brumley|first7=David|title=फ़ज़िंग के लिए बीज चयन का अनुकूलन|journal=Proceedings of the 23rd USENIX Conference on Security Symposium|year=2014|pages=861–875|url=https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-rebert.pdf}}</ref>
म्यूटेशन-आधारित फ़ज़र फ़ज़िंग के दौरान बीज इनपुट के मौजूदा कॉर्पस का लाभ उठाता है। यह प्रदान किए गए बीजों को संशोधित (या बल्कि उत्परिवर्तन (आनुवांशिक एल्गोरिथम)) करके इनपुट उत्पन्न करता है।<ref>{{cite journal|last1=Offutt|first1=Jeff|last2=Xu|first2=Wuzhi|title=डेटा गड़बड़ी का उपयोग करके वेब सेवाओं के लिए टेस्ट केस तैयार करना|journal=Workshop on Testing, Analysis and Verification of Web Services|year=2004|volume=29|issue=5|pages=1–10|doi=10.1145/1022494.1022529|s2cid=52854851|url=https://dl.acm.org/citation.cfm?id=1022529}}</ref> उदाहरण के लिए, छवि लाइब्रेरी [[libpng]] को फ़ज़ करते समय, उपयोगकर्ता मान्य [[पोर्टेबल नेटवर्क ग्राफ़िक्स]] छवि फ़ाइलों का एक सेट बीज के रूप में प्रदान करेगा, जबकि एक उत्परिवर्तन-आधारित फ़ज़र इन बीजों को प्रत्येक बीज के अर्ध-वैध वेरिएंट का उत्पादन करने के लिए संशोधित करेगा। बीज फ़ाइलों के कॉर्पस में हजारों संभावित समान इनपुट हो सकते है। स्वचालित बीज चयन (या परीक्षण सूट में कमी) उपयोगकर्ताओं को फ़ज़ अभियान के दौरान पाए जाने वाले बगों की कुल संख्या को अधिकतम करने के लिए सर्वोत्तम बीज चुनने की अनुमति देता है।<ref>{{cite journal|last1=Rebert|first1=Alexandre|last2=Cha|first2=Sang Kil|last3=Avgerinos|first3=Thanassis|last4=Foote|first4=Jonathan|last5=Warren|first5=David|last6=Grieco|first6=Gustavo|last7=Brumley|first7=David|title=फ़ज़िंग के लिए बीज चयन का अनुकूलन|journal=Proceedings of the 23rd USENIX Conference on Security Symposium|year=2014|pages=861–875|url=https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-rebert.pdf}}</ref>
पीढ़ी-आधारित फ़ज़र स्क्रैच से इनपुट उत्पन्न करता है। उदाहरण के लिए, एक स्मार्ट जनरेशन-आधारित फ़ज़र<ref name="AutoDO-14"/>नए इनपुट उत्पन्न करने के लिए उपयोगकर्ता द्वारा प्रदान किए गए इनपुट मॉडल को लेता है। म्यूटेशन-आधारित फ़ज़र्स के विपरीत, एक पीढ़ी-आधारित फ़ज़र बीज इनपुट के कॉर्पस के अस्तित्व या गुणवत्ता पर निर्भर नहीं करता है।
पीढ़ी-आधारित फ़ज़र स्क्रैच से इनपुट उत्पन्न करता है। उदाहरण के लिए, एक स्मार्ट जनरेशन-आधारित फ़ज़र<ref name="AutoDO-14"/>नए इनपुट उत्पन्न करने के लिए उपयोगकर्ता द्वारा प्रदान किए गए इनपुट मॉडल को लेता है। म्यूटेशन-आधारित फ़ज़र्स के विपरीत, एक पीढ़ी-आधारित फ़ज़र बीज इनपुट के कॉर्पस के अस्तित्व या गुणवत्ता पर निर्भर नहीं करता है।


Line 68: Line 68:
=== इनपुट संरचना से अवगत ===
=== इनपुट संरचना से अवगत ===


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


एक स्मार्ट (मॉडल-आधारित,<ref name="pham"/>व्याकरण आधारित,<ref name="AutoDO-14"/><ref name="peach"/>या प्रोटोकॉल आधारित<ref>{{cite conference|title=SNOOZE: Toward a Stateful NetwOrk prOtocol fuzZEr|url=http://dl.acm.org/citation.cfm?id=2079962|author1=Greg Banks|author2=Marco Cova|author3=Viktoria Felmetsger|author4=Kevin Almeroth|author5=Richard Kemmerer|author6=Giovanni Vigna|publisher=Proceedings of the Information Security Conference (ISC'06)}}</ref>) फजर वैध इनपुट का अधिक अनुपात उत्पन्न करने के लिए इनपुट मॉडल का लाभ उठाता है। उदाहरण के लिए, यदि इनपुट को [[सार वाक्य रचना का पेड़]] के रूप में मॉडल किया जा सकता है, तो एक स्मार्ट म्यूटेशन-आधारित फ़ज़र<ref name="peach"/>पूर्ण सबट्री को एक नोड से दूसरे में ले जाने के लिए रैंडम [[ कार्यक्रम परिवर्तन ]] को नियोजित करेगा। यदि इनपुट को एक औपचारिक व्याकरण, एक स्मार्ट पीढ़ी-आधारित फजर द्वारा तैयार किया जा सकता है<ref name="AutoDO-14"/>व्याकरण के संबंध में मान्य इनपुट उत्पन्न करने के लिए [[उत्पादन (कंप्यूटर विज्ञान)]] को तुरंत चालू करेगा। हालांकि, आम तौर पर इनपुट मॉडल को स्पष्ट रूप से प्रदान किया जाना चाहिए, जो कि मॉडल के मालिकाना, अज्ञात या बहुत जटिल होने पर करना मुश्किल है। यदि वैध और अमान्य इनपुट का एक बड़ा कोष उपलब्ध है, तो एक [[व्याकरण प्रेरण]] तकनीक, जैसे कि [[ एंग्लुइन फंड ]] का एल* एल्गोरिथम, एक इनपुट मॉडल उत्पन्न करने में सक्षम होगा।<ref name="aiken"/><ref name="AutoDO-15"/>
एक स्मार्ट (मॉडल-आधारित,<ref name="pham"/>व्याकरण आधारित,<ref name="AutoDO-14"/><ref name="peach"/>या प्रोटोकॉल आधारित<ref>{{cite conference|title=SNOOZE: Toward a Stateful NetwOrk prOtocol fuzZEr|url=http://dl.acm.org/citation.cfm?id=2079962|author1=Greg Banks|author2=Marco Cova|author3=Viktoria Felmetsger|author4=Kevin Almeroth|author5=Richard Kemmerer|author6=Giovanni Vigna|publisher=Proceedings of the Information Security Conference (ISC'06)}}</ref>) फजर वैध इनपुट का अधिक अनुपात उत्पन्न करने के लिए इनपुट मॉडल का लाभ उठाता है। उदाहरण के लिए, यदि इनपुट को [[सार वाक्य रचना का पेड़]] के रूप में मॉडल किया जा सकता है, तो एक स्मार्ट म्यूटेशन-आधारित फ़ज़र<ref name="peach"/>पूर्ण सबट्री को एक नोड से दूसरे में ले जाने के लिए रैंडम [[ कार्यक्रम परिवर्तन ]] को नियोजित करेगा। यदि इनपुट को एक औपचारिक व्याकरण, एक स्मार्ट पीढ़ी-आधारित फजर द्वारा तैयार किया जा सकता है<ref name="AutoDO-14"/>व्याकरण के संबंध में मान्य इनपुट उत्पन्न करने के लिए [[उत्पादन (कंप्यूटर विज्ञान)]] को तुरंत चालू करेगा। हालांकि, आम तौर पर इनपुट मॉडल को स्पष्ट रूप से प्रदान किया जाना चाहिए, जो कि मॉडल के मालिकाना, अज्ञात या बहुत जटिल होने पर करना मुश्किल है। यदि वैध और अमान्य इनपुट का एक बड़ा कोष उपलब्ध है, तो एक [[व्याकरण प्रेरण]] तकनीक, जैसे कि [[ एंग्लुइन फंड ]] का एल* एल्गोरिथम, एक इनपुट मॉडल उत्पन्न करने में सक्षम होगा।<ref name="aiken"/><ref name="AutoDO-15"/>
Line 76: Line 76:


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


एक [[ब्लैक-बॉक्स परीक्षण]] | ब्लैक-बॉक्स फ़ज़र<ref name="AutoDO-1"/><ref name="peach"/>प्रोग्राम को [[ब्लैक बॉक्स]] के रूप में मानता है और आंतरिक प्रोग्राम संरचना से अनजान है। उदाहरण के लिए, एक यादृच्छिक परीक्षण उपकरण जो यादृच्छिक रूप से इनपुट उत्पन्न करता है, उसे ब्लैकबॉक्स फ़ज़र माना जाता है। इसलिए, एक ब्लैकबॉक्स फ़ज़र प्रति सेकंड कई सौ इनपुट निष्पादित कर सकता है, इसे आसानी से समानांतर किया जा सकता है, और मनमाने आकार के कार्यक्रमों को माप सकता है। हालांकि, ब्लैकबॉक्स फ़ज़र्स केवल सतह को खरोंच कर सकते हैं और उथले कीड़े को उजागर कर सकते हैं। इसलिए, ब्लैकबॉक्स फ़ज़र्स को विकसित करने का प्रयास किया गया है जो इनपुट दिए गए प्रोग्राम के आउटपुट को देखकर फ़ज़िंग के दौरान प्रोग्राम की आंतरिक संरचना (और व्यवहार) के बारे में सीख सकते हैं। उदाहरण के लिए, LearnLib एक परिमित राज्य मशीन उत्पन्न करने के लिए सक्रिय शिक्षण (मशीन लर्निंग) को नियोजित करता है जो वेब एप्लिकेशन के व्यवहार का प्रतिनिधित्व करता है।
एक [[ब्लैक-बॉक्स परीक्षण]] | ब्लैक-बॉक्स फ़ज़र<ref name="AutoDO-1"/><ref name="peach"/>प्रोग्राम को [[ब्लैक बॉक्स]] के रूप में मानता है और आंतरिक प्रोग्राम संरचना से अनजान है। उदाहरण के लिए, एक यादृच्छिक परीक्षण उपकरण जो यादृच्छिक रूप से इनपुट उत्पन्न करता है, उसे ब्लैकबॉक्स फ़ज़र माना जाता है। इसलिए, एक ब्लैकबॉक्स फ़ज़र प्रति सेकंड कई सौ इनपुट निष्पादित कर सकता है, इसे आसानी से समानांतर किया जा सकता है, और मनमाने आकार के कार्यक्रमों को माप सकता है। हालांकि, ब्लैकबॉक्स फ़ज़र्स केवल सतह को खरोंच कर सकते है और उथले कीड़े को उजागर कर सकते है। इसलिए, ब्लैकबॉक्स फ़ज़र्स को विकसित करने का प्रयास किया गया है जो इनपुट दिए गए प्रोग्राम के आउटपुट को देखकर फ़ज़िंग के दौरान प्रोग्राम की आंतरिक संरचना (और व्यवहार) के बारे में सीख सकते है। उदाहरण के लिए, LearnLib एक परिमित राज्य मशीन उत्पन्न करने के लिए सक्रिय शिक्षण (मशीन लर्निंग) को नियोजित करता है जो वेब एप्लिकेशन के व्यवहार का प्रतिनिधित्व करता है।


एक [[ व्हाइट-बॉक्स परीक्षण ]] | व्हाइट-बॉक्स फ़ज़र<ref name="ganesh"/><ref name="pham"/>कोड कवरेज को व्यवस्थित रूप से बढ़ाने या कुछ महत्वपूर्ण प्रोग्राम स्थानों तक पहुंचने के लिए प्रोग्राम विश्लेषण का लाभ उठाता है। उदाहरण के लिए, ऋषि<ref name="buzzfuzz"/>कार्यक्रम में व्यवस्थित रूप से विभिन्न रास्तों का पता लगाने के लिए सांकेतिक निष्पादन का लाभ उठाता है (एक तकनीक जिसे [[शंक्वाकार निष्पादन]] के रूप में जाना जाता है)।
एक [[ व्हाइट-बॉक्स परीक्षण ]] | व्हाइट-बॉक्स फ़ज़र<ref name="ganesh"/><ref name="pham"/>कोड कवरेज को व्यवस्थित रूप से बढ़ाने या कुछ महत्वपूर्ण प्रोग्राम स्थानों तक पहुंचने के लिए प्रोग्राम विश्लेषण का लाभ उठाता है। उदाहरण के लिए, ऋषि<ref name="buzzfuzz"/>कार्यक्रम में व्यवस्थित रूप से विभिन्न रास्तों का पता लगाने के लिए सांकेतिक निष्पादन का लाभ उठाता है (एक तकनीक जिसे [[शंक्वाकार निष्पादन]] के रूप में जाना जाता है)।
यदि मॉडल-आधारित विनिर्देश | प्रोग्राम का विनिर्देश उपलब्ध है, तो एक व्हाइटबॉक्स फ़ज़र इनपुट उत्पन्न करने के लिए मॉडल-आधारित परीक्षण से तकनीकों का लाभ उठा सकता है और प्रोग्राम विनिर्देश के विरुद्ध प्रोग्राम आउटपुट की जाँच कर सकता है।
यदि मॉडल-आधारित विनिर्देश | प्रोग्राम का विनिर्देश उपलब्ध है, तो एक व्हाइटबॉक्स फ़ज़र इनपुट उत्पन्न करने के लिए मॉडल-आधारित परीक्षण से तकनीकों का लाभ उठा सकता है और प्रोग्राम विनिर्देश के विरुद्ध प्रोग्राम आउटपुट की जाँच कर सकता है।
एक व्हाइटबॉक्स फ़ज़र उन बग्स को उजागर करने में बहुत प्रभावी हो सकता है जो प्रोग्राम में गहराई तक छिपे होते हैं। हालांकि, विश्लेषण के लिए इस्तेमाल किया जाने वाला समय (कार्यक्रम या इसके विनिर्देश का) निषेधात्मक हो सकता है। यदि व्हाइटबॉक्स फ़ज़र एक इनपुट उत्पन्न करने में अपेक्षाकृत अधिक समय लेता है, तो एक ब्लैकबॉक्स फ़ज़र अधिक कुशल होगा।<ref name="boehme"/>इसलिए, ब्लैकबॉक्स फ़ज़र्स की दक्षता और व्हाइटबॉक्स फ़ज़र्स की प्रभावशीलता को संयोजित करने का प्रयास किया जाता है।<ref name="driller"/>
एक व्हाइटबॉक्स फ़ज़र उन बग्स को उजागर करने में बहुत प्रभावी हो सकता है जो प्रोग्राम में गहराई तक छिपे होते है। हालांकि, विश्लेषण के लिए इस्तेमाल किया जाने वाला समय (कार्यक्रम या इसके विनिर्देश का) निषेधात्मक हो सकता है। यदि व्हाइटबॉक्स फ़ज़र एक इनपुट उत्पन्न करने में अपेक्षाकृत अधिक समय लेता है, तो एक ब्लैकबॉक्स फ़ज़र अधिक कुशल होगा।<ref name="boehme"/>इसलिए, ब्लैकबॉक्स फ़ज़र्स की दक्षता और व्हाइटबॉक्स फ़ज़र्स की प्रभावशीलता को संयोजित करने का प्रयास किया जाता है।<ref name="driller"/>


एक [[ग्रे-बॉक्स परीक्षण]]|ग्रे-बॉक्स फ़ज़र कार्यक्रम के बारे में जानकारी इकट्ठा करने के लिए प्रोग्राम विश्लेषण के बजाय [[इंस्ट्रूमेंटेशन (कंप्यूटर प्रोग्रामिंग)]] का लाभ उठाता है। उदाहरण के लिए, AFL और libFuzzer एक इनपुट द्वारा प्रयोग किए जाने वाले [[बुनियादी ब्लॉक]] संक्रमणों का पता लगाने के लिए हल्के इंस्ट्रूमेंटेशन का उपयोग करते हैं। यह एक उचित प्रदर्शन ओवरहेड की ओर जाता है, लेकिन फ़ज़िंग के दौरान कोड कवरेज में वृद्धि के बारे में फ़ज़र को सूचित करता है, जो ग्रे-बॉक्स फ़ज़र्स को बेहद कुशल भेद्यता का पता लगाने वाला उपकरण बनाता है।<ref name="boehme2"/>
एक [[ग्रे-बॉक्स परीक्षण]]|ग्रे-बॉक्स फ़ज़र कार्यक्रम के बारे में जानकारी इकट्ठा करने के लिए प्रोग्राम विश्लेषण के बजाय [[इंस्ट्रूमेंटेशन (कंप्यूटर प्रोग्रामिंग)]] का लाभ उठाता है। उदाहरण के लिए, AFL और libFuzzer एक इनपुट द्वारा प्रयोग किए जाने वाले [[बुनियादी ब्लॉक]] संक्रमणों का पता लगाने के लिए हल्के इंस्ट्रूमेंटेशन का उपयोग करते है। यह एक उचित प्रदर्शन ओवरहेड की ओर जाता है, लेकिन फ़ज़िंग के दौरान कोड कवरेज में वृद्धि के बारे में फ़ज़र को सूचित करता है, जो ग्रे-बॉक्स फ़ज़र्स को बेहद कुशल भेद्यता का पता लगाने वाला उपकरण बनाता है।<ref name="boehme2"/>




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


फ़ज़र को क्रैश के अलावा अन्य विफलताओं के प्रति अधिक संवेदनशील बनाने के लिए, विफलता का पता चलने पर प्रोग्राम को क्रैश करने वाले अभिकथनों को इंजेक्ट करने के लिए सैनिटाइज़र का उपयोग किया जा सकता है।<ref>{{cite web|title=बजना संकलक प्रलेखन|url=https://clang.llvm.org/docs/index.html|website=clang.llvm.org|access-date=13 March 2017}}</ref><ref>{{cite web|title=जीएनयू जीसीसी प्रक्षालक विकल्प|url=https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/Instrumentation-Options.html#index-fsanitize_003daddress-947|website=gcc.gnu.org|access-date=13 March 2017}}</ref> विभिन्न प्रकार के कीड़ों के लिए अलग-अलग सैनिटाइज़र हैं:
फ़ज़र को क्रैश के अलावा अन्य विफलताओं के प्रति अधिक संवेदनशील बनाने के लिए, विफलता का पता चलने पर प्रोग्राम को क्रैश करने वाले अभिकथनों को इंजेक्ट करने के लिए सैनिटाइज़र का उपयोग किया जा सकता है।<ref>{{cite web|title=बजना संकलक प्रलेखन|url=https://clang.llvm.org/docs/index.html|website=clang.llvm.org|access-date=13 March 2017}}</ref><ref>{{cite web|title=जीएनयू जीसीसी प्रक्षालक विकल्प|url=https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/Instrumentation-Options.html#index-fsanitize_003daddress-947|website=gcc.gnu.org|access-date=13 March 2017}}</ref> विभिन्न प्रकार के कीड़ों के लिए अलग-अलग सैनिटाइज़र है:
* स्मृति संबंधी त्रुटियों का पता लगाने के लिए, जैसे कि बफर ओवरफ्लो और उपयोग-बाद-मुक्त ([[मेमोरी डिबगर]]्स जैसे [[पता प्रक्षालक]] का उपयोग करके),
* स्मृति संबंधी त्रुटियों का पता लगाने के लिए, जैसे कि बफर ओवरफ्लो और उपयोग-बाद-मुक्त ([[मेमोरी डिबगर]]्स जैसे [[पता प्रक्षालक]] का उपयोग करके),
* [[दौड़ की स्थिति]] और [[गतिरोध]] का पता लगाने के लिए (थ्रेडसैनिटाइज़र),
* [[दौड़ की स्थिति]] और [[गतिरोध]] का पता लगाने के लिए (थ्रेडसैनिटाइज़र),
Line 103: Line 103:
*[[ नियंत्रण-प्रवाह अखंडता ]] (CFISanitizer) की जांच करने के लिए।
*[[ नियंत्रण-प्रवाह अखंडता ]] (CFISanitizer) की जांच करने के लिए।


यदि कोई [[संदर्भ कार्यान्वयन]] उपलब्ध है तो अंतर बग का पता लगाने के लिए फ़ज़िंग का भी उपयोग किया जा सकता है। स्वचालित [[प्रतिगमन परीक्षण]] के लिए,<ref>{{cite book|last1=Orso|first1=Alessandro|last2=Xie|first2=Tao|title=BERT: BEhavioral Regression Testing|journal=Proceedings of the 2008 International Workshop on Dynamic Analysis (WODA 2008)|year=2008|pages=36–42|doi=10.1145/1401827.1401835|publisher=ACM|isbn=9781605580548|s2cid=7506576}}</ref> उत्पन्न इनपुट एक ही प्रोग्राम के दो [[सॉफ्टवेयर वर्जनिंग]] प