फज़िंग: Difference between revisions
From Vigyanwiki
No edit summary |
No edit summary |
||
| Line 8: | Line 8: | ||
== इतिहास == | == इतिहास == | ||
फ़ज़ शब्द की उत्पत्ति 1988 के पतन वर्ग की परियोजना से हुई थी<ref name="fuzz-cs736"/> स्नातक उन्नत ऑपरेटिंग | फ़ज़ शब्द की उत्पत्ति 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"/>हाल ही में जारी किए गए [[विंडोज एनटी]] ऑपरेटिंग | * 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 यूनिक्स उपयोगिताओं के लिए फ़ज़ परीक्षण लागू किया गया, जो 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> दो लोकप्रिय यूनिक्स वेरिएंट्स, एक GNU/Linux प्लेटफॉर्म और एक सोलारिस प्लेटफॉर्म के तहत 87 यूनिक्स उपयोगिताओं के लिए फ़ज़ परीक्षण लागू किया गया, जो SunOS 1990 पर 29% दुर्घटनाग्रस्त हो गया, लेकिन परीक्षण किए गए रेड हैट 6.2 पर केवल 4%। सबसे आम विफलता मोड पॉइंटर अंकगणितीय था, इसके बाद रिटर्न कोड की जांच नहीं की गई और पुराने (खतरनाक) इनपुट फ़ंक्शंस का उपयोग किया गया। | ||
* 2006:<ref name="fuzz2006"/>कमांड लाइन और विंडो आधारित अनुप्रयोगों दोनों के लिए [[ Mac OS X |Mac OS X]] पर एप्लाइड फ़ज़ परीक्षण। उन्होंने 135 कमांड लाइन उपयोगिता कार्यक्रमों का परीक्षण किया, जिनमें से 7% परीक्षण किए गए। इसके अलावा, उन्होंने MacOS Aqua (उपयोगकर्ता इंटरफ़ेस) विंडो | * 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> (कई इंटरनेट-फेसिंग सेवाएं, जैसे कि कुछ वेब सर्वर परिनियोजन, कुछ अनुरोधों को संसाधित करने के लिए बैश का उपयोग करती है, एक हमलावर को [[मनमाना कोड निष्पादन]] के लिए बैश के कमजोर संस्करणों का कारण बनने की अनुमति देती है। यह एक हमलावर को कंप्यूटर | सितंबर 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 33: | Line 33: | ||
सितंबर 2016 में, Microsoft ने प्रोजेक्ट स्प्रिंगफील्ड की घोषणा की, जो सॉफ्टवेयर में सुरक्षा संबंधी महत्वपूर्ण बग खोजने के लिए क्लाउड-आधारित फ़ज़ परीक्षण सेवा है।<ref name="springfield"/> | सितंबर 2016 में, Microsoft ने प्रोजेक्ट स्प्रिंगफील्ड की घोषणा की, जो सॉफ्टवेयर में सुरक्षा संबंधी महत्वपूर्ण बग खोजने के लिए क्लाउड-आधारित फ़ज़ परीक्षण सेवा है।<ref name="springfield"/> | ||
दिसंबर 2016 में, Google ने | दिसंबर 2016 में, Google ने ओएसएस-फ़ज़ की घोषणा की जो कई सुरक्षा-महत्वपूर्ण ओपन-सोर्स परियोजनाओं की निरंतर फ़ज़िंग की अनुमति देता है।<ref name="ossfuzz"/> | ||
ब्लैक हैट 2018 में, क्रिस्टोफर डोमस ने एक प्रोसेसर में एक छिपे हुए कम किए गए निर्देश सेट कंप्यूटर कोर के अस्तित्व को उजागर करने के लिए फ़ज़िंग के उपयोग का प्रदर्शन किया।<ref name ="domas"/> यह कोर रिंग 3 से सुरक्षा रिंग कमांड को निष्पादित करने के लिए मौजूदा सुरक्षा जांच को बायपास करने में सक्षम था। | ब्लैक हैट 2018 में, क्रिस्टोफर डोमस ने एक प्रोसेसर में एक छिपे हुए कम किए गए निर्देश सेट कंप्यूटर कोर के अस्तित्व को उजागर करने के लिए फ़ज़िंग के उपयोग का प्रदर्शन किया।<ref name ="domas"/> यह कोर रिंग 3 से सुरक्षा रिंग कमांड को निष्पादित करने के लिए मौजूदा सुरक्षा जांच को बायपास करने में सक्षम था। | ||
| Line 48: | Line 48: | ||
1983 में, Apple में [[स्टीव कैप्स]] ने द मंकी को विकसित किया,<ref name="hertzfeld2004"/>एक उपकरण जो [[मैकपेंट]] जैसे [[क्लासिक मैक ओएस]] अनुप्रयोगों के लिए यादृच्छिक इनपुट उत्पन्न करेगा।<ref name="AutoDO-3"/>आलंकारिक बंदर [[अनंत बंदर प्रमेय]] को संदर्भित करता है जिसमें कहा गया है कि एक बंदर एक टाइपराइटर कीबोर्ड पर यादृच्छिक रूप से असीमित समय के लिए चाबियों को मारता है, अंततः शेक्सपियर के पूरे कार्यों को टाइप करेगा। परीक्षण के मामले में, बंदर इनपुट के विशेष अनुक्रम को लिखेंगे जो दुर्घटना को ट्रिगर करेगा। | 1983 में, Apple में [[स्टीव कैप्स]] ने द मंकी को विकसित किया,<ref name="hertzfeld2004"/>एक उपकरण जो [[मैकपेंट]] जैसे [[क्लासिक मैक ओएस]] अनुप्रयोगों के लिए यादृच्छिक इनपुट उत्पन्न करेगा।<ref name="AutoDO-3"/>आलंकारिक बंदर [[अनंत बंदर प्रमेय]] को संदर्भित करता है जिसमें कहा गया है कि एक बंदर एक टाइपराइटर कीबोर्ड पर यादृच्छिक रूप से असीमित समय के लिए चाबियों को मारता है, अंततः शेक्सपियर के पूरे कार्यों को टाइप करेगा। परीक्षण के मामले में, बंदर इनपुट के विशेष अनुक्रम को लिखेंगे जो दुर्घटना को ट्रिगर करेगा। | ||
1991 में, क्रैशमे टूल जारी किया गया था, जिसका उद्देश्य बेतरतीब ढंग से चुने गए मापदंडों के साथ | 1991 में, क्रैशमे टूल जारी किया गया था, जिसका उद्देश्य बेतरतीब ढंग से चुने गए मापदंडों के साथ उपकरण कॉल को बेतरतीब ढंग से निष्पादित करके यूनिक्स और यूनिक्स जैसी [[ऑपरेटिंग सिस्टम|ऑपरेटिंग उपकरण]] की मजबूती का परीक्षण करना था।<ref name="AutoDO-4"/> | ||
== प्रकार == | == प्रकार == | ||
एक फजर को कई तरह से वर्गीकृत किया जा सकता है:<ref name="sutton"/><ref name="neystadt"/># एक फ़ज़र जनरेशन-आधारित या म्यूटेशन-आधारित हो सकता है, जो इस बात पर निर्भर करता है कि इनपुट स्क्रैच से उत्पन्न हुए है या मौजूदा इनपुट को संशोधित करके। | एक फजर को कई तरह से वर्गीकृत किया जा सकता है:<ref name="sutton"/><ref name="neystadt"/># एक फ़ज़र जनरेशन-आधारित या म्यूटेशन-आधारित हो सकता है, जो इस बात पर निर्भर करता है कि इनपुट स्क्रैच से उत्पन्न हुए है या मौजूदा इनपुट को संशोधित करके। | ||
| Line 57: | Line 57: | ||
म्यूटेशन-आधारित फ़ज़र फ़ज़िंग के दौरान बीज इनपुट के मौजूदा कॉर्पस का लाभ उठाता है। यह प्रदान किए गए बीजों को संशोधित (या बल्कि उत्परिवर्तन (आनुवांशिक एल्गोरिथम)) करके इनपुट उत्पन्न करता है।<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" />नए इनपुट उत्पन्न करने के लिए उपयोगकर्ता द्वारा प्रदान किए गए इनपुट मॉडल को लेता है। म्यूटेशन-आधारित फ़ज़र्स के विपरीत, एक पीढ़ी-आधारित फ़ज़र बीज इनपुट के कॉर्पस के अस्तित्व या गुणवत्ता पर निर्भर नहीं करता है। | |||
कुछ फ़ज़र्स में स्क्रैच से इनपुट उत्पन्न करने और मौजूदा बीजों के उत्परिवर्तन द्वारा इनपुट उत्पन्न करने के लिए दोनों करने की क्षमता होती है।<ref name="pham"/> | कुछ फ़ज़र्स में स्क्रैच से इनपुट उत्पन्न करने और मौजूदा बीजों के उत्परिवर्तन द्वारा इनपुट उत्पन्न करने के लिए दोनों करने की क्षमता होती है।<ref name="pham"/> | ||
=== इनपुट संरचना से अवगत === | === इनपुट संरचना से अवगत === | ||
| Line 69: | Line 68: | ||
एक गूंगा फजर<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 एक परिमित राज्य मशीन उत्पन्न करने के लिए सक्रिय शिक्षण (मशीन लर्निंग) को नियोजित करता है जो वेब एप्लिकेशन के व्यवहार का प्रतिनिधित्व करता है। | ||
| Line 81: | Line 78: | ||
एक [[ग्रे-बॉक्स परीक्षण]]|ग्रे-बॉक्स फ़ज़र कार्यक्रम के बारे में जानकारी इकट्ठा करने के लिए प्रोग्राम विश्लेषण के बजाय [[इंस्ट्रूमेंटेशन (कंप्यूटर प्रोग्रामिंग)]] का लाभ उठाता है। उदाहरण के लिए, AFL और libFuzzer एक इनपुट द्वारा प्रयोग किए जाने वाले [[बुनियादी ब्लॉक]] संक्रमणों का पता लगाने के लिए हल्के इंस्ट्रूमेंटेशन का उपयोग करते है। यह एक उचित प्रदर्शन ओवरहेड की ओर जाता है, लेकिन फ़ज़िंग के दौरान कोड कवरेज में वृद्धि के बारे में फ़ज़र को सूचित करता है, जो ग्रे-बॉक्स फ़ज़र्स को बेहद कुशल भेद्यता का पता लगाने वाला उपकरण बनाता है।<ref name="boehme2"/> | एक [[ग्रे-बॉक्स परीक्षण]]|ग्रे-बॉक्स फ़ज़र कार्यक्रम के बारे में जानकारी इकट्ठा करने के लिए प्रोग्राम विश्लेषण के बजाय [[इंस्ट्रूमेंटेशन (कंप्यूटर प्रोग्रामिंग)]] का लाभ उठाता है। उदाहरण के लिए, AFL और libFuzzer एक इनपुट द्वारा प्रयोग किए जाने वाले [[बुनियादी ब्लॉक]] संक्रमणों का पता लगाने के लिए हल्के इंस्ट्रूमेंटेशन का उपयोग करते है। यह एक उचित प्रदर्शन ओवरहेड की ओर जाता है, लेकिन फ़ज़िंग के दौरान कोड कवरेज में वृद्धि के बारे में फ़ज़र को सूचित करता है, जो ग्रे-बॉक्स फ़ज़र्स को बेहद कुशल भेद्यता का पता लगाने वाला उपकरण बनाता है।<ref name="boehme2"/> | ||
== उपयोग करता है == | == उपयोग करता है == | ||
| Line 103: | Line 98: | ||
=== स्थिर विश्लेषण रिपोर्ट मान्य करना === | === स्थिर विश्लेषण रिपोर्ट मान्य करना === | ||
[[स्थैतिक कार्यक्रम विश्लेषण]] किसी प्रोग्राम को वास्तव में निष्पादित किए [[गतिशील कार्यक्रम विश्लेषण]] करता है। इससे झूठी सकारात्मकता हो सकती है जहां उपकरण उस प्रोग्राम के साथ समस्याओं की रिपोर्ट करता है जो वास्तव में मौजूद नहीं है। डायनेमिक प्रोग्राम विश्लेषण के संयोजन में फ़ज़िंग का उपयोग एक इनपुट उत्पन्न करने का प्रयास करने के लिए किया जा सकता है जो वास्तव में रिपोर्ट की गई समस्या का गवाह है।<ref>{{cite book|last1=Babić|first1=Domagoj|last2=Martignoni|first2=Lorenzo|last3=McCamant|first3=Stephen|last4=Song|first4=Dawn|title=स्टेटिकली-डायरेक्टेड डायनामिक ऑटोमेटेड टेस्ट जेनरेशन|journal=Proceedings of the 2011 International Symposium on Software Testing and Analysis|year=2011|pages=12–22|doi=10.1145/2001420.2001423|publisher=ACM|isbn=9781450305624|s2cid=17344927}}</ref> | [[स्थैतिक कार्यक्रम विश्लेषण]] किसी प्रोग्राम को वास्तव में निष्पादित किए [[गतिशील कार्यक्रम विश्लेषण]] करता है। इससे झूठी सकारात्मकता हो सकती है जहां उपकरण उस प्रोग्राम के साथ समस्याओं की रिपोर्ट करता है जो वास्तव में मौजूद नहीं है। डायनेमिक प्रोग्राम विश्लेषण के संयोजन में फ़ज़िंग का उपयोग एक इनपुट उत्पन्न करने का प्रयास करने के लिए किया जा सकता है जो वास्तव में रिपोर्ट की गई समस्या का गवाह है।<ref>{{cite book|last1=Babić|first1=Domagoj|last2=Martignoni|first2=Lorenzo|last3=McCamant|first3=Stephen|last4=Song|first4=Dawn|title=स्टेटिकली-डायरेक्टेड डायनामिक ऑटोमेटेड टेस्ट जेनरेशन|journal=Proceedings of the 2011 International Symposium on Software Testing and Analysis|year=2011|pages=12–22|doi=10.1145/2001420.2001423|publisher=ACM|isbn=9781450305624|s2cid=17344927}}</ref> | ||
=== ब्राउज़र सुरक्षा === | === ब्राउज़र सुरक्षा === | ||
आधुनिक वेब ब्राउज़र व्यापक फ़ज़िंग से गुजरते है। [[Google Chrome]] का क्रोमियम (वेब ब्राउज़र) कोड क्रोम सुरक्षा टीम द्वारा 15,000 कोर के साथ लगातार फ़ज़ किया जाता है।<ref name="Security">{{cite web |last1=Sesterhenn |first1=Eric |last2=Wever |first2=Berend-Jan |last3=Orrù |first3=Michele |last4=Vervier |first4=Markus |title=ब्राउज़र सुरक्षा श्वेतपत्र|url=https://browser-security.x41-dsec.de/X41-Browser-Security-White-Paper.pdf |publisher=X41D SEC GmbH |date=19 Sep 2017}}</ref> [[Microsoft Edge]] और [[Internet Explorer]] के लिए, | आधुनिक वेब ब्राउज़र व्यापक फ़ज़िंग से गुजरते है। [[Google Chrome|गूगल क्रोम]] का क्रोमियम (वेब ब्राउज़र) कोड क्रोम सुरक्षा टीम द्वारा 15,000 कोर के साथ लगातार फ़ज़ किया जाता है।<ref name="Security">{{cite web |last1=Sesterhenn |first1=Eric |last2=Wever |first2=Berend-Jan |last3=Orrù |first3=Michele |last4=Vervier |first4=Markus |title=ब्राउज़र सुरक्षा श्वेतपत्र|url=https://browser-security.x41-dsec.de/X41-Browser-Security-White-Paper.pdf |publisher=X41D SEC GmbH |date=19 Sep 2017}}</ref> [[Microsoft Edge|माइक्रोसॉफ्ट एज]] और [[Internet Explorer|इंटरनेट इक्स्प्लोरर]] के लिए, माइक्रोसॉफ्ट ने उत्पाद विकास के दौरान 670 मशीन-वर्षों के साथ फ़ज़्ड परीक्षण किया गया था, जिससे 1 बिलियन एचटीएमएल फाइलों से 400 बिलियन से अधिक मैनिपुलेशन उत्पन्न हुए थे।<ref>{{cite web |title=Microsoft Edge के लिए सुरक्षा संवर्द्धन (IT पेशेवरों के लिए Microsoft Edge)|url=https://docs.microsoft.com/en-us/microsoft-edge/deploy/security-enhancements-microsoft-edge |publisher=[[Microsoft]] |access-date=31 August 2018 |date=15 Oct 2017}}</ref><ref name="Security"/> | ||
== उपकरण श्रंखला == | |||
एक फ़ज़र अपेक्षाकृत कम समय में बड़ी संख्या में इनपुट उत्पन्न करता है। उदाहरण के लिए, 2016 में गूगल ओएसएस-फ़ज़ प्रोजेक्ट ने एक सप्ताह में लगभग 4 [[ ट्रिलियन (छोटा पैमाना) |ट्रिलियन (छोटा पैमाना)]] इनपुट का उत्पादन किया।<ref name="ossfuzz"/>इसलिए, कई फ़ज़र्स एक [[ toolchain |उपकरण श्रृंखला]] प्रदान करते है जो अन्यथा मैन्युअल और थकाऊ कार्यों को स्वचालित करता है जो विफलता-उत्प्रेरण इनपुट की स्वचालित पीढ़ी का पालन करते है। | |||
== | |||
एक फ़ज़र अपेक्षाकृत कम समय में बड़ी संख्या में इनपुट उत्पन्न करता है। उदाहरण के लिए, 2016 में | |||