फज़िंग: 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"/> उदाहरण के लिए, फ़ज़ कोड के लिए यह अधिक महत्वपूर्ण है जो किसी भी उपयोगकर्ता द्वारा फ़ाइल के अपलोड को संभालता है, उस कोड को फ़ज़ करना है जो कॉन्फ़िगरेशन फ़ाइल को पार्स करता है जो केवल एक विशेषाधिकार प्राप्त उपयोगकर्ता के लिए पहुंच योग्य होता है। | ||
== इतिहास == | == इतिहास == | ||
फ़ज़ शब्द की उत्पत्ति 1988 के पतन वर्ग की परियोजना से हुई | फ़ज़ शब्द की उत्पत्ति 1988 के पतन वर्ग की परियोजना से हुई थी<ref name="fuzz-cs736"/> स्नातक उन्नत ऑपरेटिंग सिस्टम वर्ग (CS736) में, विस्कॉन्सिन विश्वविद्यालय में प्रोफेसर बार्टन मिलर द्वारा पढ़ाया गया था, जिसके परिणाम बाद में 1990 में प्रकाशित हुए थे।<ref name="fuzz1990"/> यूटिलिटी के लिए स्वचालित रूप से यादृच्छिक इनपुट और कमांड-लाइन पैरामीटर उत्पन्न करने के लिए एक यूनिक्स उपयोगिता का परीक्षण करने के लिए होता है। प्रोजेक्ट को [[यूनिक्स]] कमांड लाइन कार्यक्रमों की विश्वसनीयता का परीक्षण करने के लिए डिज़ाइन किया गया था जब तक कि वे दुर्घटनाग्रस्त होने तक त्वरित उत्तराधिकार में बड़ी संख्या में यादृच्छिक इनपुट निष्पादित कर सकते है। मिलर की टीम 25 से 33 प्रतिशत उपयोगिताओं को क्रैश करने में सक्षम थी, जिनका उन्होंने परीक्षण किया था। फिर उन्होंने कारण निर्धारित करने के लिए प्रत्येक क्रैश को डिबग किया था और प्रत्येक ज्ञात विफलता को वर्गीकृत किया था। अन्य शोधकर्ताओं को अन्य सॉफ्टवेयर के साथ समान प्रयोग करने की अनुमति देने के लिए, उपकरणों के स्रोत कोड, परीक्षण प्रक्रियाओं और कच्चे परिणाम डेटा को सार्वजनिक रूप से उपलब्ध कराया गया था।<ref name="AutoDO-2"/> इस प्रारंभिक फ़ज़िंग को अब ब्लैक बॉक्स, जेनरेशनल, अनस्ट्रक्चर्ड (डंब) फ़ज़िंग कहा जाता है। | ||
1990 के इस फ़ज़ पेपर ने सुरक्षा के साथ विश्वसनीयता के संबंध को भी नोट किया: दूसरा, एक बग जो हमने पाया वह उसी प्रोग्रामिंग अभ्यास के कारण हुआ था जिसने इंटरनेट वर्म ('गेट्स फिंगर' बग) को एक सुरक्षा छेद प्रदान किया था। हमें अतिरिक्त बग मिले है जो भविष्य में सुरक्षा खामियों का संकेत दे सकते है। (नवंबर 1988 के [[मॉरिस कीड़ा]] का जिक्र करते हुए।) | 1990 के इस फ़ज़ पेपर ने सुरक्षा के साथ विश्वसनीयता के संबंध को भी नोट किया: दूसरा, एक बग जो हमने पाया वह उसी प्रोग्रामिंग अभ्यास के कारण हुआ था जिसने इंटरनेट वर्म ('गेट्स फिंगर' बग) को एक सुरक्षा छेद प्रदान किया था। हमें अतिरिक्त बग मिले है जो भविष्य में सुरक्षा खामियों का संकेत दे सकते है। (नवंबर 1988 के [[मॉरिस कीड़ा]] का जिक्र करते हुए।) | ||
| Line 14: | Line 14: | ||
मूल फज़ परियोजना ने 1995, 2000, 2006 और हाल ही में 2020 में योगदान दिया: | मूल फज़ परियोजना ने 1995, 2000, 2006 और हाल ही में 2020 में योगदान दिया: | ||
* 1995:<ref name="fuzz1995"/>फ़ज़ रिविज़िटेड पेपर में चार भाग होते है। | * 1995:<ref name="fuzz1995"/>फ़ज़ रिविज़िटेड पेपर में चार भाग होते है। | ||
*# | *# यूनिक्स सिस्टम की व्यापक विविधता और अधिक उपयोगिताओं सहित मूल कमांड लाइन अध्ययन को पुन: प्रस्तुत किया। अध्ययन से पता चला कि, अगर कुछ भी, विश्वसनीयता खराब हो गई थी। यह पहला अध्ययन था जिसमें ओपन सोर्स [[जीएनयू]] और [[लिनक्स]] उपयोगिताओं को शामिल किया गया था, जो दिलचस्प रूप से वाणिज्यिक यूनिक्स सिस्टम की तुलना में काफी अधिक विश्वसनीय थे। | ||
*# एक्स-विंडोज़ के तहत जीयूआई (विंडो आधारित) अनुप्रयोगों के फ़ज़ परीक्षण का परिचय दिया। इस अध्ययन में असंरचित और संरचित (माउस और कीबोर्ड घटनाओं के मान्य अनुक्रम) इनपुट डेटा दोनों का उपयोग किया गया। वे X-Windows अनुप्रयोगों के 25% को क्रैश करने में सक्षम थे। इसके अलावा, उन्होंने एक्स-विंडोज सर्वर का परीक्षण किया और दिखाया कि यह क्रैश के लिए लचीला था। | *# एक्स-विंडोज़ के तहत जीयूआई (विंडो आधारित) अनुप्रयोगों के फ़ज़ परीक्षण का परिचय दिया। इस अध्ययन में असंरचित और संरचित (माउस और कीबोर्ड घटनाओं के मान्य अनुक्रम) इनपुट डेटा दोनों का उपयोग किया गया। वे X-Windows अनुप्रयोगों के 25% को क्रैश करने में सक्षम थे। इसके अलावा, उन्होंने एक्स-विंडोज सर्वर का परीक्षण किया और दिखाया कि यह क्रैश के लिए लचीला था। | ||
*# संरचित परीक्षण इनपुट के आधार पर फिर से नेटवर्क सेवाओं की फ़ज़ परीक्षण की शुरुआत की। इनमें से कोई भी सेवा दुर्घटनाग्रस्त नहीं हुई थी। | *# संरचित परीक्षण इनपुट के आधार पर फिर से नेटवर्क सेवाओं की फ़ज़ परीक्षण की शुरुआत की। इनमें से कोई भी सेवा दुर्घटनाग्रस्त नहीं हुई थी। | ||
*# सिस्टम लाइब्रेरी कॉल रिटर्न वैल्यू के यादृच्छिक परीक्षण का परिचय दिया, विशेष रूप से फ़ंक्शन के मॉलोक परिवार से यादृच्छिक रूप से शून्य लौटा रहा है। लगभग आधे मानक | *# सिस्टम लाइब्रेरी कॉल रिटर्न वैल्यू के यादृच्छिक परीक्षण का परिचय दिया, विशेष रूप से फ़ंक्शन के मॉलोक परिवार से यादृच्छिक रूप से शून्य लौटा रहा है। लगभग आधे मानक यूनिक्स प्रोग्राम ऐसे वापसी मूल्यों की ठीक से जाँच करने में विफल रहे। | ||
* 2000:<ref name="fuzz2000"/>हाल ही में जारी किए गए [[विंडोज एनटी]] ऑपरेटिंग सिस्टम के लिए एप्लाइड फज़ परीक्षण, [[Win32]] विंडो सिस्टम के तहत चलने वाले अनुप्रयोगों का परीक्षण। वे 21% अनुप्रयोगों को क्रैश करने में सक्षम थे और परीक्षण किए गए अतिरिक्त 24% को लटका दिया। फिर से, अनुप्रयोग असंरचित और संरचित (वैध कीबोर्ड और माउस ईवेंट) इनपुट दोनों के साथ परीक्षण कर रहे थे, उन अनुप्रयोगों में से लगभग आधे को क्रैश कर दिया, जिनका उन्होंने परीक्षण किया था। उन्होंने विफलताओं के कारणों की पहचान की और उन्हें पिछले अध्ययनों के समान पाया। | * 2000:<ref name="fuzz2000"/>हाल ही में जारी किए गए [[विंडोज एनटी]] ऑपरेटिंग सिस्टम के लिए एप्लाइड फज़ परीक्षण, [[Win32]] विंडो सिस्टम के तहत चलने वाले अनुप्रयोगों का परीक्षण। वे 21% अनुप्रयोगों को क्रैश करने में सक्षम थे और परीक्षण किए गए अतिरिक्त 24% को लटका दिया। फिर से, अनुप्रयोग असंरचित और संरचित (वैध कीबोर्ड और माउस ईवेंट) इनपुट दोनों के साथ परीक्षण कर रहे थे, उन अनुप्रयोगों में से लगभग आधे को क्रैश कर दिया, जिनका उन्होंने परीक्षण किया था। उन्होंने विफलताओं के कारणों की पहचान की और उन्हें पिछले अध्ययनों के समान पाया। | ||
* 2001:<ref>{{cite web|url=https://pages.cs.wisc.edu/~blbowers/fuzz-2001.pdf|title=UNIX उपयोगिताओं की स्थिरता और विश्वसनीयता की जांच|website=cs.wisc.edu|access-date=3 March 2023}}</ref> दो लोकप्रिय यूनिक्स वेरिएंट्स, एक GNU/Linux प्लेटफॉर्म और एक सोलारिस प्लेटफॉर्म के तहत 87 | * 2001:<ref>{{cite web|url=https://pages.cs.wisc.edu/~blbowers/fuzz-2001.pdf|title=UNIX उपयोगिताओं की स्थिरता और विश्वसनीयता की जांच|website=cs.wisc.edu|access-date=3 March 2023}}</ref> दो लोकप्रिय यूनिक्स वेरिएंट्स, एक GNU/Linux प्लेटफॉर्म और एक सोलारिस प्लेटफॉर्म के तहत 87 यूनिक्स उपयोगिताओं के लिए फ़ज़ परीक्षण लागू किया गया, जो SunOS 1990 पर 29% दुर्घटनाग्रस्त हो गया, लेकिन परीक्षण किए गए रेड हैट 6.2 पर केवल 4%। सबसे आम विफलता मोड पॉइंटर अंकगणितीय था, इसके बाद रिटर्न कोड की जांच नहीं की गई और पुराने (खतरनाक) इनपुट फ़ंक्शंस का उपयोग किया गया। | ||
* 2006:<ref name="fuzz2006"/>कमांड लाइन और विंडो आधारित अनुप्रयोगों दोनों के लिए [[ Mac OS X ]] पर एप्लाइड फ़ज़ परीक्षण। उन्होंने 135 कमांड लाइन उपयोगिता कार्यक्रमों का परीक्षण किया, जिनमें से 7% परीक्षण किए गए। इसके अलावा, उन्होंने MacOS Aqua (उपयोगकर्ता इंटरफ़ेस) विंडो सिस्टम के अंतर्गत चलने वाले 30 अनुप्रयोगों का परीक्षण किया, जिनमें से 73% परीक्षण किए गए। | * 2006:<ref name="fuzz2006"/>कमांड लाइन और विंडो आधारित अनुप्रयोगों दोनों के लिए [[ Mac OS X |Mac OS X]] पर एप्लाइड फ़ज़ परीक्षण। उन्होंने 135 कमांड लाइन उपयोगिता कार्यक्रमों का परीक्षण किया, जिनमें से 7% परीक्षण किए गए। इसके अलावा, उन्होंने MacOS Aqua (उपयोगकर्ता इंटरफ़ेस) विंडो सिस्टम के अंतर्गत चलने वाले 30 अनुप्रयोगों का परीक्षण किया, जिनमें से 73% परीक्षण किए गए। | ||
* 2020:<ref name="fuzz2020"/>हाल ही में, उन्होंने यह देखने के लिए कि क्या मूल तकनीकें अभी भी प्रासंगिक थीं और क्या वर्तमान उपयोगिता कार्यक्रम इस प्रकार के परीक्षण के लिए प्रतिरोधी थे, क्लासिक जेनरेशनल, ब्लैक बॉक्स, वर्तमान | * 2020:<ref name="fuzz2020"/>हाल ही में, उन्होंने यह देखने के लिए कि क्या मूल तकनीकें अभी भी प्रासंगिक थीं और क्या वर्तमान उपयोगिता कार्यक्रम इस प्रकार के परीक्षण के लिए प्रतिरोधी थे, क्लासिक जेनरेशनल, ब्लैक बॉक्स, वर्तमान यूनिक्स सिस्टम, विशेष रूप से Linux, [[FreeBSD]] और MacOS पर असंरचित परीक्षण लागू किया। उन्होंने प्रत्येक प्लेटफॉर्म पर लगभग 75 उपयोगिताओं का परीक्षण किया, लिनक्स पर 12% की विफलता दर, मैकओएस पर 16% और फ्रीबीएसडी पर 19%। (ध्यान दें कि ये विफलता दर समान प्रणालियों के पिछले परीक्षण के परिणामों से भी बदतर थे।) जब उन्होंने प्रत्येक विफलता का विश्लेषण किया और उन्हें वर्गीकृत किया, तो उन्होंने पाया कि विफलताओं की क्लासिक श्रेणियां, जैसे सूचक और सरणी त्रुटियां और रिटर्न कोड की जांच नहीं करना, नए परिणामों में मोटे तौर पर अभी भी मौजूद थे। इसके अलावा, नई विफलता जटिल प्रोग्राम स्थिति और एल्गोरिदम से उत्पन्न होती है जो इनपुट आकार या जटिलता के साथ स्केल नहीं करती थी। उन्होंने हाल ही में रस्ट में लिखी गई यूनिक्स उपयोगिताओं का भी परीक्षण किया और पाया कि वे 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>) | ||
अगस्त 2016 में, [[रक्षा अग्रिम जाँच परियोजनाएं एजेंसी]] (DARPA) ने पहले [[साइबर ग्रैंड चैलेंज]] का फाइनल आयोजित किया, जो पूरी तरह से स्वचालित कैप्चर द फ़्लैग (साइबर सुरक्षा) | कैप्चर-द-फ़्लैग प्रतियोगिता थी जो 11 घंटे तक चली।<ref name="cgc">{{cite web|url=http://www.darpa.mil/program/cyber-grand-challenge |title= DARPA साइबर ग्रैंड चैलेंज|last=Walker |first=Michael |website=darpa.mil |access-date=12 March 2017}}</ref> इसका उद्देश्य स्वचालित रक्षा प्रणालियों को विकसित करना था जो [[रीयल-टाइम कंप्यूटिंग]] | रीयल-टाइम में सॉफ़्टवेयर त्रुटियों की खोज, [[शोषण (कंप्यूटर सुरक्षा)]], और [[स्वचालित बग फिक्सिंग]] सॉफ़्टवेयर त्रुटियों को विकसित कर सके। विरोधियों के सॉफ्टवेयर में खामियों को खोजने के लिए फ़ज़िंग को एक प्रभावी अपराध रणनीति के रूप में इस्तेमाल किया गया था। इसने भेद्यता का पता लगाने के स्वचालन में जबरदस्त क्षमता दिखाई। विजेता हाथापाई नामक एक प्रणाली थी<ref name="2016 results">{{cite web|url=http://www.darpa.mil/news-events/2016-08-05a |title=तबाही सीजीसी में पहले स्थान पर आती है|access-date=12 March 2017}}</ref> [[डेविड ब्रमली]] के नेतृत्व वाली टीम फॉरऑलसिक्योर द्वारा विकसित किया गया। | अगस्त 2016 में, [[रक्षा अग्रिम जाँच परियोजनाएं एजेंसी]] (DARPA) ने पहले [[साइबर ग्रैंड चैलेंज]] का फाइनल आयोजित किया, जो पूरी तरह से स्वचालित कैप्चर द फ़्लैग (साइबर सुरक्षा) | कैप्चर-द-फ़्लैग प्रतियोगिता थी जो 11 घंटे तक चली।<ref name="cgc">{{cite web|url=http://www.darpa.mil/program/cyber-grand-challenge |title= DARPA साइबर ग्रैंड चैलेंज|last=Walker |first=Michael |website=darpa.mil |access-date=12 March 2017}}</ref> इसका उद्देश्य स्वचालित रक्षा प्रणालियों को विकसित करना था जो [[रीयल-टाइम कंप्यूटिंग]] | रीयल-टाइम में सॉफ़्टवेयर त्रुटियों की खोज, [[शोषण (कंप्यूटर सुरक्षा)]], और [[स्वचालित बग फिक्सिंग]] सॉफ़्टवेयर त्रुटियों को विकसित कर सके। विरोधियों के सॉफ्टवेयर में खामियों को खोजने के लिए फ़ज़िंग को एक प्रभावी अपराध रणनीति के रूप में इस्तेमाल किया गया था। इसने भेद्यता का पता लगाने के स्वचालन में जबरदस्त क्षमता दिखाई। विजेता हाथापाई नामक एक प्रणाली थी<ref name="2016 results">{{cite web|url=http://www.darpa.mil/news-events/2016-08-05a |title=तबाही सीजीसी में पहले स्थान पर आती है|access-date=12 March 2017}}</ref> [[डेविड ब्रमली]] के नेतृत्व वाली टीम फॉरऑलसिक्योर द्वारा विकसित किया गया। | ||
| Line 35: | Line 35: | ||
दिसंबर 2016 में, Google ने OSS-Fuzz की घोषणा की जो कई सुरक्षा-महत्वपूर्ण ओपन-सोर्स परियोजनाओं की निरंतर फ़ज़िंग की अनुमति देता है।<ref name="ossfuzz"/> | दिसंबर 2016 में, Google ने OSS-Fuzz की घोषणा की जो कई सुरक्षा-महत्वपूर्ण ओपन-सोर्स परियोजनाओं की निरंतर फ़ज़िंग की अनुमति देता है।<ref name="ossfuzz"/> | ||
ब्लैक हैट 2018 में, क्रिस्टोफर डोमस ने एक प्रोसेसर में एक छिपे हुए कम किए गए निर्देश सेट कंप्यूटर कोर के अस्तित्व को उजागर करने के लिए फ़ज़िंग के उपयोग का प्रदर्शन किया।<ref name ="domas"/> | ब्लैक हैट 2018 में, क्रिस्टोफर डोमस ने एक प्रोसेसर में एक छिपे हुए कम किए गए निर्देश सेट कंप्यूटर कोर के अस्तित्व को उजागर करने के लिए फ़ज़िंग के उपयोग का प्रदर्शन किया।<ref name ="domas"/> यह कोर रिंग 3 से सुरक्षा रिंग कमांड को निष्पादित करने के लिए मौजूदा सुरक्षा जांच को बायपास करने में सक्षम था। | ||
सितंबर 2020 में, [[माइक्रोसॉफ्ट]] ने वनफज जारी किया, जो एक सेल्फ-होस्टिंग (वेब सर्विसेज) | सेल्फ-होस्टेड फ़ज़िंग-एज़-ए-सर्विस प्लेटफ़ॉर्म है जो [[सॉफ्टवेयर बग]] का पता लगाने को स्वचालित करता है।<ref>{{Cite web|url=https://www.zdnet.com/article/microsoft-windows-10-is-hardened-with-these-fuzzing-security-tools-now-theyre-open-source/|title=Microsoft: Windows 10 is hardened with these fuzzing security tools – now they're open source|date=September 15, 2020|website=ZDNet}}</ref> यह [[ खिड़कियाँ ]] और लिनक्स को सपोर्ट करता है।<ref>{{Cite web|url=https://www.infoworld.com/article/3575600/microsoft-open-sources-fuzzing-test-framework.html|title=Microsoft ओपन-सोर्स फ़ज़िंग टेस्ट फ्रेमवर्क|date=September 17, 2020|website=InfoWorld}}</ref> | सितंबर 2020 में, [[माइक्रोसॉफ्ट]] ने वनफज जारी किया, जो एक सेल्फ-होस्टिंग (वेब सर्विसेज) | सेल्फ-होस्टेड फ़ज़िंग-एज़-ए-सर्विस प्लेटफ़ॉर्म है जो [[सॉफ्टवेयर बग]] का पता लगाने को स्वचालित करता है।<ref>{{Cite web|url=https://www.zdnet.com/article/microsoft-windows-10-is-hardened-with-these-fuzzing-security-tools-now-theyre-open-source/|title=Microsoft: Windows 10 is hardened with these fuzzing security tools – now they're open source|date=September 15, 2020|website=ZDNet}}</ref> यह [[ खिड़कियाँ |खिड़कियाँ]] और लिनक्स को सपोर्ट करता है।<ref>{{Cite web|url=https://www.infoworld.com/article/3575600/microsoft-open-sources-fuzzing-test-framework.html|title=Microsoft ओपन-सोर्स फ़ज़िंग टेस्ट फ्रेमवर्क|date=September 17, 2020|website=InfoWorld}}</ref> | ||
| Line 44: | Line 44: | ||
यादृच्छिक इनपुट के साथ परीक्षण कार्यक्रम 1950 के दशक के है जब डेटा अभी भी [[पंच कार्ड युग में कंप्यूटर प्रोग्रामिंग]] पर संग्रहीत था।<ref name="weinberg"/>प्रोग्रामर कंप्यूटर प्रोग्राम के इनपुट के रूप में छिद्रित कार्ड का उपयोग करेंगे जो यादृच्छिक संख्याओं के ट्रैश या कार्ड डेक से खींचे गए थे। यदि किसी निष्पादन से अवांछित व्यवहार का पता चलता है, तो एक सॉफ़्टवेयर बग का पता चला था। | यादृच्छिक इनपुट के साथ परीक्षण कार्यक्रम 1950 के दशक के है जब डेटा अभी भी [[पंच कार्ड युग में कंप्यूटर प्रोग्रामिंग]] पर संग्रहीत था।<ref name="weinberg"/>प्रोग्रामर कंप्यूटर प्रोग्राम के इनपुट के रूप में छिद्रित कार्ड का उपयोग करेंगे जो यादृच्छिक संख्याओं के ट्रैश या कार्ड डेक से खींचे गए थे। यदि किसी निष्पादन से अवांछित व्यवहार का पता चलता है, तो एक सॉफ़्टवेयर बग का पता चला था। | ||
रैंडम इनपुट के निष्पादन को [[ यादृच्छिक परीक्षण ]] या [[ बंदर परीक्षण ]] भी कहा जाता है। | रैंडम इनपुट के निष्पादन को [[ यादृच्छिक परीक्षण |यादृच्छिक परीक्षण]] या [[ बंदर परीक्षण |बंदर परीक्षण]] भी कहा जाता है। | ||
1981 में, डुरान और Ntafos ने औपचारिक रूप से यादृच्छिक इनपुट के साथ एक कार्यक्रम के परीक्षण की प्रभावशीलता की जांच की।<ref name="duran1"/><ref name="duran2"/>जबकि यादृच्छिक परीक्षण व्यापक रूप से एक कार्यक्रम के परीक्षण का सबसे खराब साधन माना जाता था, लेखक यह दिखा सकते थे कि यह अधिक व्यवस्थित परीक्षण तकनीकों के लिए एक लागत प्रभावी विकल्प है। | 1981 में, डुरान और Ntafos ने औपचारिक रूप से यादृच्छिक इनपुट के साथ एक कार्यक्रम के परीक्षण की प्रभावशीलता की जांच की।<ref name="duran1"/><ref name="duran2"/>जबकि यादृच्छिक परीक्षण व्यापक रूप से एक कार्यक्रम के परीक्षण का सबसे खराब साधन माना जाता था, लेखक यह दिखा सकते थे कि यह अधिक व्यवस्थित परीक्षण तकनीकों के लिए एक लागत प्रभावी विकल्प है। | ||
| 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"/> | ||
एक गूंगा फजर<ref name="AutoDO-1"/><ref name="ganesh"/>इनपुट मॉडल की आवश्यकता नहीं होती है और इस प्रकार कार्यक्रमों की व्यापक विविधता को कम करने के लिए नियोजित किया जा सकता है। उदाहरण के लिए, अमेरिकन फ़ज़ी लोप (फ़ज़र) एक गूंगा म्यूटेशन-आधारित फ़ज़र है जो बिटवाइज़ ऑपरेशन द्वारा एक बीज फ़ाइल को संशोधित करता है # नहीं, दिलचस्प मूल्यों के साथ यादृच्छिक बाइट्स को प्रतिस्थापित करके, और डेटा के ब्लॉक को स्थानांतरित या हटाकर। हालांकि, एक गूंगा फजर वैध इनपुट का कम अनुपात उत्पन्न कर सकता है और प्रोग्राम के मुख्य घटकों के बजाय पार्सर कोड पर जोर दे सकता है। [[ चक्रीय अतिरिक्तता जांच ]] (CRC) के लिए एक वैध [[ अंततः, ]] के निर्माण के माध्यम से डंब फज़र्स के नुकसान को चित्रित किया जा सकता है। CRC एक [[ त्रुटि का पता लगाने वाला कोड ]] है जो यह सुनिश्चित करता है कि इनपुट फ़ाइल में निहित डेटा की डेटा अखंडता [[डेटा ट्रांसमिशन]] के दौरान संरक्षित है। एक चेकसम की गणना इनपुट डेटा पर की जाती है और फ़ाइल में दर्ज की जाती है। जब प्रोग्राम प्राप्त फ़ाइल को प्रोसेस करता है और रिकॉर्ड किया गया चेकसम पुनः गणना किए गए चेकसम से मेल नहीं खाता है, तो फ़ाइल को अमान्य के रूप में अस्वीकार कर दिया जाता है। अब, सीआरसी से अनजान एक फजर सही चेकसम उत्पन्न करने की संभावना नहीं है। हालाँकि, म्यूट म्यूटेशन-आधारित फ़ज़र द्वारा संरक्षित डेटा को संशोधित करने के बाद, उत्परिवर्तित इनपुट में एक संभावित चेकसम की पहचान करने और फिर से गणना करने का प्रयास किया जाता है।<ref>{{cite book|last1=Wang|first1=T.|last2=Wei|first2=T.|last3=Gu|first3=G.|last4=Zou|first4=W.|title=TaintScope: A Checksum-Aware Directed Fuzzing Tool for Automatic Software Vulnerability Detection|journal=2010 IEEE Symposium on Security and Privacy|date=May 2010|pages=497–512|doi=10.1109/SP.2010.37|isbn=978-1-4244-6894-2|citeseerx=10.1.1.169.7866|s2cid=11898088}}</ref> | एक गूंगा फजर<ref name="AutoDO-1"/><ref name="ganesh"/>इनपुट मॉडल की आवश्यकता नहीं होती है और इस प्रकार कार्यक्रमों की व्यापक विविधता को कम करने के लिए नियोजित किया जा सकता है। उदाहरण के लिए, अमेरिकन फ़ज़ी लोप (फ़ज़र) एक गूंगा म्यूटेशन-आधारित फ़ज़र है जो बिटवाइज़ ऑपरेशन द्वारा एक बीज फ़ाइल को संशोधित करता है # नहीं, दिलचस्प मूल्यों के साथ यादृच्छिक बाइट्स को प्रतिस्थापित करके, और डेटा के ब्लॉक को स्थानांतरित या हटाकर। हालांकि, एक गूंगा फजर वैध इनपुट का कम अनुपात उत्पन्न कर सकता है और प्रोग्राम के मुख्य घटकों के बजाय पार्सर कोड पर जोर दे सकता है। [[ चक्रीय अतिरिक्तता जांच |चक्रीय अतिरिक्तता जांच]] (CRC) के लिए एक वैध [[ अंततः, |अंततः,]] के निर्माण के माध्यम से डंब फज़र्स के नुकसान को चित्रित किया जा सकता है। CRC एक [[ त्रुटि का पता लगाने वाला कोड |त्रुटि का पता लगाने वाला कोड]] है जो यह सुनिश्चित करता है कि इनपुट फ़ाइल में निहित डेटा की डेटा अखंडता [[डेटा ट्रांसमिशन]] के दौरान संरक्षित है। एक चेकसम की गणना इनपुट डेटा पर की जाती है और फ़ाइल में दर्ज की जाती है। जब प्रोग्राम प्राप्त फ़ाइल को प्रोसेस करता है और रिकॉर्ड किया गया चेकसम पुनः गणना किए गए चेकसम से मेल नहीं खाता है, तो फ़ाइल को अमान्य के रूप में अस्वीकार कर दिया जाता है। अब, सीआरसी से अनजान एक फजर सही चेकसम उत्पन्न करने की संभावना नहीं है। हालाँकि, म्यूट म्यूटेशन-आधारित फ़ज़र द्वारा संरक्षित डेटा को संशोधित करने के बाद, उत्परिवर्तित इनपुट में एक संभावित चेकसम की पहचान करने और फिर से गणना करने का प्रयास किया जाता है।<ref>{{cite book|last1=Wang|first1=T.|last2=Wei|first2=T.|last3=Gu|first3=G.|last4=Zou|first4=W.|title=TaintScope: A Checksum-Aware Directed Fuzzing Tool for Automatic Software Vulnerability Detection|journal=2010 IEEE Symposium on Security and Privacy|date=May 2010|pages=497–512|doi=10.1109/SP.2010.37|isbn=978-1-4244-6894-2|citeseerx=10.1.1.169.7866|s2cid=11898088}}</ref> | ||
=== कार्यक्रम संरचना से अवगत === | === कार्यक्रम संरचना से अवगत === | ||
आमतौर पर, एक फ़ज़र को अधिक प्रभावी माना जाता है यदि वह उच्च स्तर का [[ कोड कवरेज़ ]] प्राप्त करता है। तर्क यह है कि यदि कोई फ़ज़र प्रोग्राम में कुछ संरचनात्मक तत्वों का प्रयोग नहीं करता है, तो यह उन [[सॉफ्टवेयर बग]] को प्रकट करने में भी सक्षम नहीं है जो इन तत्वों में छिपे हुए है। कुछ कार्यक्रम तत्वों को दूसरों की तुलना में अधिक महत्वपूर्ण माना जाता है। उदाहरण के लिए, एक डिवीजन ऑपरेटर शून्य त्रुटि से डिवीजन का कारण बन सकता है, या [[सिस्टम कॉल]] प्रोग्राम को क्रैश कर सकता है। | आमतौर पर, एक फ़ज़र को अधिक प्रभावी माना जाता है यदि वह उच्च स्तर का [[ कोड कवरेज़ |कोड कवरेज़]] प्राप्त करता है। तर्क यह है कि यदि कोई फ़ज़र प्रोग्राम में कुछ संरचनात्मक तत्वों का प्रयोग नहीं करता है, तो यह उन [[सॉफ्टवेयर बग]] को प्रकट करने में भी सक्षम नहीं है जो इन तत्वों में छिपे हुए है। कुछ कार्यक्रम तत्वों को दूसरों की तुलना में अधिक महत्वपूर्ण माना जाता है। उदाहरण के लिए, एक डिवीजन ऑपरेटर शून्य त्रुटि से डिवीजन का कारण बन सकता है, या [[सिस्टम कॉल]] प्रोग्राम को क्रैश कर सकता है। | ||
एक [[ब्लैक-बॉक्स परीक्षण]] | ब्लैक-बॉक्स फ़ज़र<ref name="AutoDO-1"/><ref name="peach"/>प्रोग्राम को [[ब्लैक बॉक्स]] के रूप में मानता है और आंतरिक प्रोग्राम संरचना से अनजान है। उदाहरण के लिए, एक यादृच्छिक परीक्षण उपकरण जो यादृच्छिक रूप से इनपुट उत्पन्न करता है, उसे ब्लैकबॉक्स फ़ज़र माना जाता है। इसलिए, एक ब्लैकबॉक्स फ़ज़र प्रति सेकंड कई सौ इनपुट निष्पादित कर सकता है, इसे आसानी से समानांतर किया जा सकता है, और मनमाने आकार के कार्यक्रमों को माप सकता है। हालांकि, ब्लैकबॉक्स फ़ज़र्स केवल सतह को खरोंच कर सकते है और उथले कीड़े को उजागर कर सकते है। इसलिए, ब्लैकबॉक्स फ़ज़र्स को विकसित करने का प्रयास किया गया है जो इनपुट दिए गए प्रोग्राम के आउटपुट को देखकर फ़ज़िंग के दौरान प्रोग्राम की आंतरिक संरचना (और व्यवहार) के बारे में सीख सकते है। उदाहरण के लिए, LearnLib एक परिमित राज्य मशीन उत्पन्न करने के लिए सक्रिय शिक्षण (मशीन लर्निंग) को नियोजित करता है जो वेब एप्लिकेशन के व्यवहार का प्रतिनिधित्व करता है। | एक [[ब्लैक-बॉक्स परीक्षण]] | ब्लैक-बॉक्स फ़ज़र<ref name="AutoDO-1"/><ref name="peach"/>प्रोग्राम को [[ब्लैक बॉक्स]] के रूप में मानता है और आंतरिक प्रोग्राम संरचना से अनजान है। उदाहरण के लिए, एक यादृच्छिक परीक्षण उपकरण जो यादृच्छिक रूप से इनपुट उत्पन्न करता है, उसे ब्लैकबॉक्स फ़ज़र माना जाता है। इसलिए, एक ब्लैकबॉक्स फ़ज़र प्रति सेकंड कई सौ इनपुट निष्पादित कर सकता है, इसे आसानी से समानांतर किया जा सकता है, और मनमाने आकार के कार्यक्रमों को माप सकता है। हालांकि, ब्लैकबॉक्स फ़ज़र्स केवल सतह को खरोंच कर सकते है और उथले कीड़े को उजागर कर सकते है। इसलिए, ब्लैकबॉक्स फ़ज़र्स को विकसित करने का प्रयास किया गया है जो इनपुट दिए गए प्रोग्राम के आउटपुट को देखकर फ़ज़िंग के दौरान प्रोग्राम की आंतरिक संरचना (और व्यवहार) के बारे में सीख सकते है। उदाहरण के लिए, LearnLib एक परिमित राज्य मशीन उत्पन्न करने के लिए सक्रिय शिक्षण (मशीन लर्निंग) को नियोजित करता है जो वेब एप्लिकेशन के व्यवहार का प्रतिनिधित्व करता है। | ||
एक [[ व्हाइट | |||