फज़िंग: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
 
(4 intermediate revisions by 3 users not shown)
Line 2: Line 2:
{{Information security}}
{{Information security}}


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


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


== इतिहास ==
== इतिहास ==


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


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


मूल फज़ परियोजना ने 1995, 2000, 2006 और हाल ही में 2020 में योगदान दिया:
मूल फज़ परियोजना ने 1995, 2000, 2006 और हाल ही में 2020 में योगदान दिया:
* 1995:<ref name="fuzz1995"/>फ़ज़ रिविज़िटेड पेपर में चार भाग होते है।
* 1995:<ref name="fuzz1995"/>फ़ज़ रिविज़िटेड पेपर में चार भाग होते है।
*# यूनिक्स उपकरण की व्यापक विविधता और अधिक उपयोगिताओं सहित मूल कमांड लाइन अध्ययन को पुन: प्रस्तुत किया। अध्ययन से पता चला कि, यदि कुछ भी, विश्वसनीयता खराब हो गई थी। यह पहला अध्ययन था जिसमें ओपन सोर्स [[जीएनयू]] और [[लिनक्स]] उपयोगिताओं को सम्मलित किया गया था, जो रोचक रूप से वाणिज्यिक यूनिक्स उपकरण की तुलना में अधिक विश्वसनीय थे।
*# यूनिक्स उपकरण की व्यापक विविधता और अधिक उपयोगिताओं सहित मूल कमांड लाइन अध्ययन को पुन: प्रस्तुत किया था। अध्ययन से पता चला था कि विश्वसनीयता खराब हो गई थी। यह पहला अध्ययन था जिसमें ओपन सोर्स [[जीएनयू]] और [[लिनक्स]] उपयोगिताओं को सम्मलित किया गया था, जो रोचक रूप से वाणिज्यिक यूनिक्स उपकरण की तुलना में अधिक विश्वसनीय थे।
*# एक्स-विंडोज़ के अनुसार जीयूआई (विंडो आधारित) अनुप्रयोगों के फ़ज़ परीक्षण का परिचय दिया। इस अध्ययन में असंरचित और संरचित (माउस और कीबोर्ड घटनाओं के मान्य अनुक्रम) इनपुट डेटा दोनों का उपयोग किया गया। वे एक्स विंडोज अनुप्रयोगों के 25% को क्रैश करने में सक्षम थे। इसके अतिरिक्त, उन्होंने एक्स-विंडोज सर्वर का परीक्षण किया और दिखाया कि यह क्रैश के लिए लचीला था।
*# एक्स-विंडोज़ के अनुसार जीयूआई (विंडो आधारित) अनुप्रयोगों के फ़ज़ परीक्षण का परिचय दिया था। इस अध्ययन में असंरचित और संरचित (माउस और कीबोर्ड घटनाओं के मान्य अनुक्रम) इनपुट डेटा दोनों का उपयोग किया गया था। वे एक्स विंडोज अनुप्रयोगों के 25% को क्रैश करने में सक्षम थे। इसके अतिरिक्त, उन्होंने एक्स-विंडोज सर्वर का परीक्षण किया था और दिखाया कि यह क्रैश के लिए लचीला था।
*# संरचित परीक्षण इनपुट के आधार पर फिर से नेटवर्क सेवाओं की फ़ज़ परीक्षण प्रारंभ किया। इनमें से कोई भी सेवा दुर्घटनाग्रस्त नहीं हुई थी।
*# संरचित परीक्षण इनपुट के आधार पर फिर से नेटवर्क सेवाओं की फ़ज़ परीक्षण को प्रारंभ किया था। इनमें से कोई भी सेवा दुर्घटनाग्रस्त नहीं हुई थी।
*# उपकरण लाइब्रेरी रिटर्न वैल्यू के यादृच्छिक परीक्षण का परिचय दिया, विशेष रूप से फ़ंक्शन के मॉलोक परिवार से यादृच्छिक रूप से शून्य लौटता है। लगभग आधे मानक यूनिक्स प्रोग्राम ऐसे वापसी मूल्यों की ठीक से जाँच करने में विफल रहते है।
*# उपकरण लाइब्रेरी के यादृच्छिक परीक्षण का परिचय दिया कि, विशेष रूप से फ़ंक्शन के मॉलोक परिवार से यादृच्छिक रूप से शून्य लौटता है। लगभग आधे मानक यूनिक्स प्रोग्राम ऐसे वापसी मूल्यों की ठीक से जाँच करने में विफल रहते है।
* 2000:<ref name="fuzz2000"/> हाल ही में जारी किए गए [[विंडोज एनटी]] ऑपरेटिंग उपकरण के लिए एप्लाइड फज़ परीक्षण, [[Win32]] विंडो उपकरण के अनुसार चलने वाले अनुप्रयोगों का परीक्षण। वे 21% अनुप्रयोगों को क्रैश करने में सक्षम थे। फिर से, अनुप्रयोग असंरचित और संरचित (वैध कीबोर्ड और माउस ईवेंट) इनपुट दोनों के साथ परीक्षण कर रहे थे, उन अनुप्रयोगों में से लगभग आधे को क्रैश कर दिया, जिनका उन्होंने परीक्षण किया था। उन्होंने विफलताओं के कारणों की पहचान की और उन्हें पिछले अध्ययनों के समान पाया।
* 2000:<ref name="fuzz2000"/> हाल ही में जारी किए गए [[विंडोज एनटी]] ऑपरेटिंग उपकरण के लिए प्रयुक्त फज़ परीक्षण, [[Win32]] विंडो उपकरण के अनुसार चलने वाले अनुप्रयोगों का परीक्षण था। वे 21% अनुप्रयोगों को क्रैश करने में सक्षम थे। फिर से, अनुप्रयोग असंरचित और संरचित इनपुट दोनों के साथ परीक्षण कर रहे थे, उन अनुप्रयोगों में से लगभग आधे को क्रैश कर दिया था, जिनका उन्होंने परीक्षण किया था। उन्होंने विफलताओं के कारणों की पहचान की थी और उन्हें पिछले अध्ययनों के समान पाया था।
* 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> दो लोकप्रिय यूनिक्स वेरिएंट्स, एक जीएनयू/लिनक्स प्लेटफॉर्म और एक सोलारिस प्लेटफॉर्म के अनुसार 87 यूनिक्स उपयोगिताओं के लिए फ़ज़ परीक्षण लागू किया गया, जो SunOS 1990 पर 29% दुर्घटनाग्रस्त हो गया, लेकिन परीक्षण किए गए रेड हैट 6.2 पर केवल 4%सबसे आम विफलता मोड पॉइंटर अंकगणितीय था, इसके बाद रिटर्न कोड की जांच नहीं की गई और पुराने (खतरनाक) इनपुट फ़ंक्शंस का उपयोग किया गया।
* 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> दो लोकप्रिय यूनिक्स वेरिएंट्स, एक जीएनयू/लिनक्स प्लेटफॉर्म और एक सोलारिस प्लेटफॉर्म के अनुसार 87 यूनिक्स उपयोगिताओं के लिए फ़ज़ परीक्षण लागू किया गया था, जो SunOS 1990 पर 29% दुर्घटनाग्रस्त हो गया था, लेकिन परीक्षण किए गए रेड हैट 6.2 पर केवल 4% था। सबसे आम विफलता मोड पॉइंटर अंकगणितीय था, इसके बाद रिटर्न कोड की जांच नहीं की गई थी और पुराने इनपुट फ़ंक्शंस का उपयोग किया गया था।
* 2006:<ref name="fuzz2006"/> कमांड लाइन और विंडो आधारित अनुप्रयोगों दोनों के लिए [[ Mac OS X |मैक ओएस एक्स]] पर फ़ज़ परीक्षण होता है। उन्होंने 135 कमांड लाइन उपयोगिता कार्यक्रमों का परीक्षण किया, जिनमें से 7% परीक्षण किए गए। इसके अतिरिक्त, उन्होंने मैक ओएस एक्वा (उपयोगकर्ता अंतरफलक) विंडो उपकरण के अंतर्गत चलने वाले 30 अनुप्रयोगों का परीक्षण किया, जिनमें से 73% परीक्षण किए गए।
* 2006:<ref name="fuzz2006"/> कमांड लाइन और विंडो आधारित अनुप्रयोगों दोनों के लिए [[ Mac OS X |मैक ओएस एक्स]] पर फ़ज़ परीक्षण होता है। उन्होंने 135 कमांड लाइन उपयोगिता कार्यक्रमों का परीक्षण किया था, जिनमें से 7% परीक्षण किए गए थे। इसके अतिरिक्त, उन्होंने मैक ओएस एक्वा विंडो उपकरण के अंतर्गत चलने वाले 30 अनुप्रयोगों का परीक्षण किया, जिनमें से 73% परीक्षण किए गए थे।
* 2020:<ref name="fuzz2020"/> हाल ही में, उन्होंने यह देखने के लिए कि क्या मूल तकनीकें अभी भी प्रासंगिक थीं और क्या वर्तमान उपयोगिता कार्यक्रम इस प्रकार के परीक्षण के लिए प्रतिरोधी थे, क्लासिक जेनरेशनल, ब्लैक बॉक्स, वर्तमान यूनिक्स उपकरण, विशेष रूप से लिनक्स, [[FreeBSD|फ्री बीएसडी]] और मैक ओएस पर असंरचित परीक्षण लागू किया। उन्होंने प्रत्येक प्लेटफॉर्म पर लगभग 75 उपयोगिताओं का परीक्षण किया, लिनक्स पर 12% की विफलता दर, मैकओएस पर 16% और फ्रीबीएसडी पर 19%। (ध्यान दें कि ये विफलता दर समान प्रणालियों के पिछले परीक्षण के परिणामों से भी बदतर थे।) जब उन्होंने प्रत्येक विफलता का विश्लेषण किया और उन्हें वर्गीकृत किया, तो उन्होंने पाया कि विफलताओं की क्लासिक श्रेणियां, जैसे सूचक और सरणी त्रुटियां और रिटर्न कोड की जांच नहीं करना, नए परिणामों में मोटे तौर पर अभी भी उपस्थित थे। इसके अतिरिक्त, नई विफलता जटिल प्रोग्राम स्थिति और एल्गोरिदम से उत्पन्न होती है जो इनपुट आकार या जटिलता के साथ स्केल नहीं करती थी। उन्होंने हाल ही में रस्ट में लिखी गई यूनिक्स उपयोगिताओं का भी परीक्षण किया और पाया कि वे सी में लिखी गई समान विश्वसनीयता की थीं, चूंकि (उम्मीद के मुताबिक) स्मृति त्रुटियों की संभावना कम थी।
* 2020:<ref name="fuzz2020"/> हाल ही में, उन्होंने यह देखने के लिए कि क्या मूल तकनीकें अभी भी प्रासंगिक थीं और क्या वर्तमान उपयोगिता कार्यक्रम इस प्रकार के परीक्षण के लिए प्रतिरोधी थे, क्लासिक जेनरेशनल, ब्लैक बॉक्स, वर्तमान यूनिक्स उपकरण, विशेष रूप से लिनक्स, [[FreeBSD|फ्री बीएसडी]] और मैक ओएस पर असंरचित परीक्षण लागू किया था। उन्होंने प्रत्येक प्लेटफॉर्म पर लगभग 75 उपयोगिताओं का परीक्षण किया था, लिनक्स पर 12% की विफलता दर, मैकओएस पर 16% और फ्रीबीएसडी पर 19% था। जब उन्होंने प्रत्येक विफलता का विश्लेषण किया और उन्हें वर्गीकृत किया, तो उन्होंने पाया कि विफलताओं की क्लासिक श्रेणियां, जैसे सूचक और सरणी त्रुटियां और रिटर्न कोड की जांच नहीं करना, नए परिणामों में मोटे तौर पर अभी भी उपस्थित थे। इसके अतिरिक्त, नई विफलता जटिल प्रोग्राम स्थिति और एल्गोरिदम से उत्पन्न होती है जो इनपुट आकार या जटिलता के साथ स्केल नहीं करती थी। उन्होंने हाल ही में रस्ट में लिखी गई यूनिक्स उपयोगिताओं का भी परीक्षण किया और पाया कि वे सी में लिखी गई समान विश्वसनीयता की थीं, जिसमे स्मृति त्रुटियों की संभावना कम थी।


अप्रैल 2012 में, गूगल ने [[क्रोमियम वेब ब्राउज़र]] के सुरक्षा-महत्वपूर्ण घटकों के लिए क्लाउड-आधारित फ़ज़िंग आधारिक संरचना क्लस्टरफ़ज़ की घोषणा की थी।<ref name="clusterfuzz"/> यदि क्लस्टरफ़ज़ को अपलोड किए गए फ़ज़र के साथ क्रैश होने का पता चलता है, तो सुरक्षा शोधकर्ता अपने स्वयं के फ़ज़र्स अपलोड कर सकते है और बग बाउंटी एकत्र कर सकते है।
अप्रैल 2012 में, गूगल ने [[क्रोमियम वेब ब्राउज़र]] के सुरक्षा-महत्वपूर्ण घटकों के लिए क्लाउड-आधारित फ़ज़िंग आधारिक संरचना क्लस्टरफ़ज़ की घोषणा की थी।<ref name="clusterfuzz"/> यदि क्लस्टरफ़ज़ को अपलोड किए गए फ़ज़र के साथ क्रैश होने का पता चलता है, तो सुरक्षा शोधकर्ता अपने स्वयं के फ़ज़र्स अपलोड कर सकते है और बग बाउंटी एकत्र कर सकते है।
Line 27: Line 27:
सितंबर 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 में, [[रक्षा अग्रिम जाँच परियोजनाएं एजेंसी]] (दरपा) ने पहले [[साइबर ग्रैंड चैलेंज]] का फाइनल आयोजित किया, जो पूरी तरह से स्वचालित कैप्चर द फ़्लैग (साइबर सुरक्षा) | कैप्चर-द-फ़्लैग प्रतियोगिता थी जो 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 में, [[रक्षा अग्रिम जाँच परियोजनाएं एजेंसी]] (दरपा) ने पहले [[साइबर ग्रैंड चैलेंज]] का फाइनल आयोजित किया था।<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 में, माइक्रोसॉफ्ट ने प्रोजेक्ट स्प्रिंगफील्ड की घोषणा की थी, जो सॉफ्टवेयर में सुरक्षा संबंधी महत्वपूर्ण बग खोजने के लिए क्लाउड-आधारित फ़ज़ परीक्षण सेवा है।<ref name="springfield"/>
सितंबर 2016 में, माइक्रोसॉफ्ट ने प्रोजेक्ट स्प्रिंगफील्ड की घोषणा की थी, जो सॉफ्टवेयर में सुरक्षा संबंधी महत्वपूर्ण बग खोजने के लिए क्लाउड-आधारित फ़ज़ परीक्षण सेवा है।<ref name="springfield"/>
Line 44: Line 44:
रैंडम इनपुट के निष्पादन को [[ यादृच्छिक परीक्षण |यादृच्छिक परीक्षण]] या [[ बंदर परीक्षण |बंदर परीक्षण]] भी कहा जाता है।
रैंडम इनपुट के निष्पादन को [[ यादृच्छिक परीक्षण |यादृच्छिक परीक्षण]] या [[ बंदर परीक्षण |बंदर परीक्षण]] भी कहा जाता है।


1981 में, डुरान और नताफोस ने औपचारिक रूप से यादृच्छिक इनपुट के साथ एक कार्यक्रम के परीक्षण की प्रभावशीलता की जांच की थी।<ref name="duran1"/><ref name="duran2"/>जबकि यादृच्छिक परीक्षण व्यापक रूप से एक कार्यक्रम के परीक्षण का सबसे खराब साधन माना जाता था, लेखक यह दिखा सकते थे कि यह अधिक व्यवस्थित परीक्षण तकनीकों के लिए एक लागत प्रभावी विकल्प है।
1981 में, डुरान और नताफोस ने औपचारिक रूप से यादृच्छिक इनपुट के साथ एक कार्यक्रम के परीक्षण की प्रभावशीलता की जांच की थी।<ref name="duran1"/><ref name="duran2"/> जबकि यादृच्छिक परीक्षण व्यापक रूप से एक कार्यक्रम के परीक्षण का सबसे खराब साधन माना जाता था, लेखक यह दिखा सकते थे कि यह अधिक व्यवस्थित परीक्षण तकनीकों के लिए एक लागत प्रभावी विकल्प है।


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


1991 में, क्रैशमे उपकरण जारी किया गया था, जिसका उद्देश्य बेतरतीब ढंग से चुने गए मापदंडों के साथ उपकरण को बेतरतीब ढंग से निष्पादित करके यूनिक्स और यूनिक्स जैसी [[ऑपरेटिंग सिस्टम|ऑपरेटिंग उपकरण]] की मजबूती का परीक्षण करना था।<ref name="AutoDO-4"/>
1991 में, क्रैशमे उपकरण जारी किया गया था, जिसका उद्देश्य बेतरतीब ढंग से चुने गए मापदंडों के साथ उपकरण को बेतरतीब ढंग से निष्पादित करके यूनिक्स और यूनिक्स जैसी [[ऑपरेटिंग सिस्टम|ऑपरेटिंग उपकरण]] की मजबूती का परीक्षण करना था।<ref name="AutoDO-4"/>
== प्रकार ==
== प्रकार ==
एक फजर को कई तरह से वर्गीकृत किया जा सकता है:<ref name="sutton"/><ref name="neystadt"/> एक फ़ज़र जनरेशन-आधारित या म्यूटेशन-आधारित हो सकता है, जो इस बात पर निर्भर करता है कि इनपुट स्क्रैच से उत्पन्न हुए है या उपस्थिता इनपुट को संशोधित करता है।
एक फजर को कई तरह से वर्गीकृत किया जा सकता है:<ref name="sutton"/><ref name="neystadt"/> एक फ़ज़र जनरेशन-आधारित या उत्परिवर्तन-आधारित हो सकता है, जो इस बात पर निर्भर करता है कि इनपुट स्क्रैच से उत्पन्न हुए है या उपस्थिता इनपुट को संशोधित करता है।
# एक फजर गूंगा (असंरचित) या स्मार्ट (संरचित) हो सकता है, यह इस बात पर निर्भर करता है कि वह इनपुट संरचना से अवगत होता है या नही होता है।
# एक फजर गूंगा (असंरचित) या स्मार्ट (संरचित) हो सकता है, यह इस बात पर निर्भर करता है कि वह इनपुट संरचना से अवगत होता है या नही होता है।
# एक फ़ज़र सफ़ेद-, ग्रे- या ब्लैक-बॉक्स हो सकता है, यह इस बात पर निर्भर करता है कि वह प्रोग्राम संरचना से अवगत होता है या नही होता है।
# एक फ़ज़र सफ़ेद-, ग्रे- या ब्लैक-बॉक्स हो सकता है, यह इस बात पर निर्भर करता है कि वह प्रोग्राम संरचना से अवगत होता है या नही होता है।
Line 56: Line 56:
=== उपस्थित इनपुट बीजों का पुन: उपयोग ===
=== उपस्थित इनपुट बीजों का पुन: उपयोग ===


म्यूटेशन-आधारित फ़ज़र फ़ज़िंग के दौरान बीज इनपुट के उपस्थिता कॉर्पस का लाभ उठाता है। यह प्रदान किए गए बीजों को संशोधित (या जबकि उत्परिवर्तन (आनुवांशिक एल्गोरिथम)) करके इनपुट उत्पन्न करता है।<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> उदाहरण के लिए, छवि लाइब्रेरी को फ़ज़ करते समय, उपयोगकर्ता मान्य [[पोर्टेबल नेटवर्क ग्राफ़िक्स]] छवि फ़ाइलों का एक सेट बीज के रूप में प्रदान करता है, जबकि एक उत्परिवर्तन-आधारित फ़ज़र इन बीजों को प्रत्येक बीज के अर्ध-वैध वेरिएंट का उत्पादन करने के लिए संशोधित करता है। बीज फ़ाइलों के कॉर्पस में हजारों संभावित समान इनपुट हो सकते है। स्वचालित बीज चयन (या परीक्षण सूट में कमी) उपयोगकर्ताओं को फ़ज़ अभियान के दौरान पाए जाने वाले बगों की कुल संख्या को अधिकतम करने के लिए सर्वोत्तम बीज चुनने की अनुमति देता है।<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" />नए इनपुट उत्पन्न करने के लिए उपयोगकर्ता द्वारा प्रदान किए गए इनपुट मॉडल को लेता है। उत्परिवर्तन-आधारित फ़ज़र्स के विपरीत, एक पीढ़ी-आधारित फ़ज़र बीज इनपुट के कॉर्पस के अस्तित्व या गुणवत्ता पर निर्भर नहीं करता है।


कुछ फ़ज़र्स में स्क्रैच से इनपुट उत्पन्न करने और उपस्थिता बीजों के उत्परिवर्तन द्वारा इनपुट उत्पन्न करने के लिए दोनों करने की क्षमता होती है।<ref name="pham"/>
कुछ फ़ज़र्स में स्क्रैच से इनपुट उत्पन्न करने और उपस्थिता बीजों के उत्परिवर्तन द्वारा इनपुट उत्पन्न करने के लिए दोनों करने की क्षमता होती है।<ref name="pham"/>
=== इनपुट संरचना से अवगत ===
=== इनपुट संरचना से अवगत ===


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


एक स्मार्ट (मॉडल-आधारित,<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"/>इनपुट मॉडल की आवश्यकता नहीं होती है और इस प्रकार कार्यक्रमों की व्यापक विविधता को कम करने के लिए नियोजित किया जाता है। उदाहरण के लिए, अमेरिकन फ़ज़ी लोप (फ़ज़र) एक गूंगा म्यूटेशन-आधारित फ़ज़र होता है जो बिटवाइज़ ऑपरेशन द्वारा एक बीज फ़ाइल को संशोधित करता है, रोचक मूल्यों के साथ यादृच्छिक बाइट्स को प्रतिस्थापित करके, और डेटा के ब्लॉक को स्थानांतरित या हटाता है। चूंकि, एक गूंगा फजर वैध इनपुट का कम अनुपात उत्पन्न कर सकता है और प्रोग्राम के मुख्य घटकों के अतिरिक्त पार्सर कोड पर जोर देता है। [[ चक्रीय अतिरिक्तता जांच |चक्रीय अतिरिक्तता जांच]] (सीआरसी) के लिए एक वैध [[ अंततः, |अंततः,]] के निर्माण के माध्यम से डंब फज़र्स के नुकसान को चित्रित किया जाता है। सीआरसी एक [[ त्रुटि का पता लगाने वाला कोड |त्रुटि का पता लगाने वाला कोड]] है जो यह सुनिश्चित करता है कि इनपुट फ़ाइल में निहित डेटा की डेटा अखंडता [[डेटा ट्रांसमिशन|डेटा संचरण]] के दौरान संरक्षित है। एक चेकसम की गणना इनपुट डेटा पर की जाती है और फ़ाइल में अंकित की जाती है। जब प्रोग्राम प्राप्त फ़ाइल को प्रोसेस करता है और रिकॉर्ड किया गया चेकसम पुनः गणना किए गए चेकसम से मेल नहीं खाता है, तो फ़ाइल को अमान्य के रूप में अस्वीकार कर दिया जाता है। अब, सीआरसी से अनजान एक फजर सही चेकसम उत्पन्न करने की संभावना नही होती है। चूँकि, म्यूट म्यूटेशन-आधारित फ़ज़र द्वारा संरक्षित डेटा को संशोधित करने के बाद,