फज़िंग

From Vigyanwiki
Revision as of 00:37, 12 May 2023 by alpha>Indicwiki (Created page with "{{Short description|Automated software testing technique}} {{Information security}} [[कंप्यूटर प्रोग्रामिंग]] और सॉफ्...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
श्रृंखला का हिस्सा
सूचना सुरक्षा
vectorial version
सुरक्षा संबंधित श्रेणियां
थ्रेट्स
डिफेंसेस

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

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

इतिहास

फ़ज़ शब्द की उत्पत्ति 1988 के पतन वर्ग की परियोजना से हुई है[2]स्नातक उन्नत ऑपरेटिंग सिस्टम वर्ग (CS736) में, विस्कॉन्सिन विश्वविद्यालय में प्रोफेसर बार्टन मिलर द्वारा पढ़ाया गया, जिसके परिणाम बाद में 1990 में प्रकाशित हुए।[3]यूटिलिटी के लिए स्वचालित रूप से यादृच्छिक इनपुट और कमांड-लाइन पैरामीटर उत्पन्न करने के लिए एक UNIX उपयोगिता का परीक्षण करने के लिए। प्रोजेक्ट को यूनिक्स कमांड लाइन कार्यक्रमों की विश्वसनीयता का परीक्षण करने के लिए डिज़ाइन किया गया था जब तक कि वे दुर्घटनाग्रस्त होने तक त्वरित उत्तराधिकार में बड़ी संख्या में यादृच्छिक इनपुट निष्पादित कर सकें। मिलर की टीम 25 से 33 प्रतिशत उपयोगिताओं को क्रैश करने में सक्षम थी, जिनका उन्होंने परीक्षण किया था। फिर उन्होंने कारण निर्धारित करने के लिए प्रत्येक क्रैश को डिबग किया और प्रत्येक ज्ञात विफलता को वर्गीकृत किया। अन्य शोधकर्ताओं को अन्य सॉफ्टवेयर के साथ समान प्रयोग करने की अनुमति देने के लिए, उपकरणों के स्रोत कोड, परीक्षण प्रक्रियाओं और कच्चे परिणाम डेटा को सार्वजनिक रूप से उपलब्ध कराया गया।[4]इस शुरुआती फ़ज़िंग को अब ब्लैक बॉक्स, जेनरेशनल, अनस्ट्रक्चर्ड (डंब) फ़ज़िंग कहा जाएगा।

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

मूल फज़ परियोजना ने 1995, 2000, 2006 और हाल ही में 2020 में योगदान दिया:

  • 1995:[5]फ़ज़ रिविज़िटेड पेपर में चार भाग होते हैं।
    1. UNIX सिस्टम की व्यापक विविधता और अधिक उपयोगिताओं सहित मूल कमांड लाइन अध्ययन को पुन: प्रस्तुत किया। अध्ययन से पता चला कि, अगर कुछ भी, विश्वसनीयता खराब हो गई थी। यह पहला अध्ययन था जिसमें ओपन सोर्स जीएनयू और लिनक्स उपयोगिताओं को शामिल किया गया था, जो दिलचस्प रूप से वाणिज्यिक यूनिक्स सिस्टम की तुलना में काफी अधिक विश्वसनीय थे।
    2. एक्स-विंडोज़ के तहत जीयूआई (विंडो आधारित) अनुप्रयोगों के फ़ज़ परीक्षण का परिचय दिया। इस अध्ययन में असंरचित और संरचित (माउस और कीबोर्ड घटनाओं के मान्य अनुक्रम) इनपुट डेटा दोनों का उपयोग किया गया। वे X-Windows अनुप्रयोगों के 25% को क्रैश करने में सक्षम थे। इसके अलावा, उन्होंने एक्स-विंडोज सर्वर का परीक्षण किया और दिखाया कि यह क्रैश के लिए लचीला था।
    3. संरचित परीक्षण इनपुट के आधार पर फिर से नेटवर्क सेवाओं की फ़ज़ परीक्षण की शुरुआत की। इनमें से कोई भी सेवा दुर्घटनाग्रस्त नहीं हुई थी।
    4. सिस्टम लाइब्रेरी कॉल रिटर्न वैल्यू के यादृच्छिक परीक्षण का परिचय दिया, विशेष रूप से फ़ंक्शन के मॉलोक परिवार से यादृच्छिक रूप से शून्य लौटा रहा है। लगभग आधे मानक UNIX प्रोग्राम ऐसे वापसी मूल्यों की ठीक से जाँच करने में विफल रहे।
  • 2000:[6]हाल ही में जारी किए गए विंडोज एनटी ऑपरेटिंग सिस्टम के लिए एप्लाइड फज़ परीक्षण, Win32 विंडो सिस्टम के तहत चलने वाले अनुप्रयोगों का परीक्षण। वे 21% अनुप्रयोगों को क्रैश करने में सक्षम थे और परीक्षण किए गए अतिरिक्त 24% को लटका दिया। फिर से, अनुप्रयोग असंरचित और संरचित (वैध कीबोर्ड और माउस ईवेंट) इनपुट दोनों के साथ परीक्षण कर रहे थे, उन अनुप्रयोगों में से लगभग आधे को क्रैश कर दिया, जिनका उन्होंने परीक्षण किया था। उन्होंने विफलताओं के कारणों की पहचान की और उन्हें पिछले अध्ययनों के समान पाया।
  • 2001:[7] दो लोकप्रिय यूनिक्स वेरिएंट्स, एक GNU/Linux प्लेटफॉर्म और एक सोलारिस प्लेटफॉर्म के तहत 87 UNIX उपयोगिताओं के लिए फ़ज़ परीक्षण लागू किया गया, जो SunOS 1990 पर 29% दुर्घटनाग्रस्त हो गया, लेकिन परीक्षण किए गए रेड हैट 6.2 पर केवल 4%। सबसे आम विफलता मोड पॉइंटर अंकगणितीय था, इसके बाद रिटर्न कोड की जांच नहीं की गई और पुराने (खतरनाक) इनपुट फ़ंक्शंस का उपयोग किया गया।
  • 2006:[8]कमांड लाइन और विंडो आधारित अनुप्रयोगों दोनों के लिए Mac OS X पर एप्लाइड फ़ज़ परीक्षण। उन्होंने 135 कमांड लाइन उपयोगिता कार्यक्रमों का परीक्षण किया, जिनमें से 7% परीक्षण किए गए। इसके अलावा, उन्होंने MacOS Aqua (उपयोगकर्ता इंटरफ़ेस) विंडो सिस्टम के अंतर्गत चलने वाले 30 अनुप्रयोगों का परीक्षण किया, जिनमें से 73% परीक्षण किए गए।
  • 2020:[9]हाल ही में, उन्होंने यह देखने के लिए कि क्या मूल तकनीकें अभी भी प्रासंगिक थीं और क्या वर्तमान उपयोगिता कार्यक्रम इस प्रकार के परीक्षण के लिए प्रतिरोधी थे, क्लासिक जेनरेशनल, ब्लैक बॉक्स, वर्तमान UNIX सिस्टम, विशेष रूप से Linux, FreeBSD और MacOS पर असंरचित परीक्षण लागू किया। उन्होंने प्रत्येक प्लेटफॉर्म पर लगभग 75 उपयोगिताओं का परीक्षण किया, लिनक्स पर 12% की विफलता दर, मैकओएस पर 16% और फ्रीबीएसडी पर 19%। (ध्यान दें कि ये विफलता दर समान प्रणालियों के पिछले परीक्षण के परिणामों से भी बदतर थे।) जब उन्होंने प्रत्येक विफलता का विश्लेषण किया और उन्हें वर्गीकृत किया, तो उन्होंने पाया कि विफलताओं की क्लासिक श्रेणियां, जैसे सूचक और सरणी त्रुटियां और रिटर्न कोड की जांच नहीं करना, नए परिणामों में मोटे तौर पर अभी भी मौजूद थे। इसके अलावा, नई विफलता जटिल प्रोग्राम स्थिति और एल्गोरिदम से उत्पन्न होती है जो इनपुट आकार या जटिलता के साथ स्केल नहीं करती थी। उन्होंने हाल ही में रस्ट में लिखी गई UNIX उपयोगिताओं का भी परीक्षण किया और पाया कि वे C में लिखी गई समान विश्वसनीयता की थीं, हालांकि (उम्मीद के मुताबिक) स्मृति त्रुटियों की संभावना कम थी।

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

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

अप्रैल 2015 में, हन्नो बॉक ने दिखाया कि कैसे फजर एएफएल 2014 हार्टब्लीड भेद्यता को ढूंढ सकता था।[14][15] (अप्रैल 2014 में हार्दिक भेद्यता का खुलासा किया गया था। यह एक गंभीर भेद्यता है जो विरोधियों को अन्यथा एन्क्रिप्टेड संचार को समझने की अनुमति देती है। भेद्यता को गलती से ओपनएसएसएल में पेश किया गया था जो परिवहन परत सुरक्षा को लागू करता है और इंटरनेट पर अधिकांश सर्वरों द्वारा उपयोग किया जाता है। शोडान (वेबसाइट) ने अप्रैल 2016 में 238,000 मशीनों के अभी भी असुरक्षित होने की सूचना दी;[16] जनवरी 2017 में 200,000।[17])

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

सितंबर 2016 में, Microsoft ने प्रोजेक्ट स्प्रिंगफील्ड की घोषणा की, जो सॉफ्टवेयर में सुरक्षा संबंधी महत्वपूर्ण बग खोजने के लिए क्लाउड-आधारित फ़ज़ परीक्षण सेवा है।[20]

दिसंबर 2016 में, Google ने OSS-Fuzz की घोषणा की जो कई सुरक्षा-महत्वपूर्ण ओपन-सोर्स परियोजनाओं की निरंतर फ़ज़िंग की अनुमति देता है।[21]

ब्लैक हैट 2018 में, क्रिस्टोफर डोमस ने एक प्रोसेसर में एक छिपे हुए कम किए गए निर्देश सेट कंप्यूटर कोर के अस्तित्व को उजागर करने के लिए फ़ज़िंग के उपयोग का प्रदर्शन किया।[22] यह कोर रिंग 3 से सुरक्षा रिंग कमांड को निष्पादित करने के लिए मौजूदा सुरक्षा जांच को बायपास करने में सक्षम था।

सितंबर 2020 में, माइक्रोसॉफ्ट ने वनफज जारी किया, जो एक सेल्फ-होस्टिंग (वेब ​​सर्विसेज) | सेल्फ-होस्टेड फ़ज़िंग-एज़-ए-सर्विस प्लेटफ़ॉर्म है जो सॉफ्टवेयर बग का पता लगाने को स्वचालित करता है।[23] यह खिड़कियाँ और लिनक्स को सपोर्ट करता है।[24]


प्रारंभिक यादृच्छिक परीक्षण

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

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

1981 में, डुरान और Ntafos ने औपचारिक रूप से यादृच्छिक इनपुट के साथ एक कार्यक्रम के परीक्षण की प्रभावशीलता की जांच की।[26][27]जबकि यादृच्छिक परीक्षण व्यापक रूप से एक कार्यक्रम के परीक्षण का सबसे खराब साधन माना जाता था, लेखक यह दिखा सकते थे कि यह अधिक व्यवस्थित परीक्षण तकनीकों के लिए एक लागत प्रभावी विकल्प है।

1983 में, Apple में स्टीव कैप्स ने द मंकी को विकसित किया,[28]एक उपकरण जो मैकपेंट जैसे क्लासिक मैक ओएस अनुप्रयोगों के लिए यादृच्छिक इनपुट उत्पन्न करेगा।[29]आलंकारिक बंदर अनंत बंदर प्रमेय को संदर्भित करता है जिसमें कहा गया है कि एक बंदर एक टाइपराइटर कीबोर्ड पर यादृच्छिक रूप से असीमित समय के लिए चाबियों को मारता है, अंततः शेक्सपियर के पूरे कार्यों को टाइप करेगा। परीक्षण के मामले में, बंदर इनपुट के विशेष अनुक्रम को लिखेंगे जो दुर्घटना को ट्रिगर करेगा।

1991 में, क्रैशमे टूल जारी किया गया था, जिसका उद्देश्य बेतरतीब ढंग से चुने गए मापदंडों के साथ सिस्टम कॉल को बेतरतीब ढंग से निष्पादित करके यूनिक्स और यूनिक्स जैसी ऑपरेटिंग सिस्टम की मजबूती का परीक्षण करना था।[30]


प्रकार

एक फजर को कई तरह से वर्गीकृत किया जा सकता है:[31][1]# एक फ़ज़र जनरेशन-आधारित या म्यूटेशन-आधारित हो सकता है, जो इस बात पर निर्भर करता है कि इनपुट स्क्रैच से उत्पन्न हुए हैं या मौजूदा इनपुट को संशोधित करके।

  1. एक फजर गूंगा (असंरचित) या स्मार्ट (संरचित) हो सकता है, यह इस बात पर निर्भर करता है कि वह इनपुट संरचना से अवगत है या नहीं।
  2. एक फ़ज़र सफ़ेद-, ग्रे- या ब्लैक-बॉक्स हो सकता है, यह इस बात पर निर्भर करता है कि वह प्रोग्राम संरचना से अवगत है या नहीं।

मौजूदा इनपुट बीजों का पुन: उपयोग

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

कुछ फ़ज़र्स में स्क्रैच से इनपुट उत्पन्न करने और मौजूदा बीजों के उत्परिवर्तन द्वारा इनपुट उत्पन्न करने के लिए दोनों करने की क्षमता होती है।[35]


इनपुट संरचना से अवगत

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

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

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


कार्यक्रम संरचना से अवगत

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

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

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

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


उपयोग करता है

फ़ज़िंग का उपयोग ज्यादातर सुरक्षा-महत्वपूर्ण कार्यक्रमों में भेद्यता (कंप्यूटिंग) को उजागर करने के लिए एक स्वचालित तकनीक के रूप में किया जाता है जो दुर्भावनापूर्ण इरादे से शोषण (कंप्यूटर सुरक्षा) हो सकता है।[10][20][21]अधिक सामान्यतः, फ़ज़िंग का उपयोग उनकी अनुपस्थिति के बजाय बग की उपस्थिति को प्रदर्शित करने के लिए किया जाता है। बग को खोजे बिना कई हफ्तों तक फ़ज़िंग अभियान चलाना कार्यक्रम को सही साबित नहीं करता है।[47] आखिरकार, प्रोग्राम अभी भी उस इनपुट के लिए विफल हो सकता है जिसे अभी तक निष्पादित नहीं किया गया है; सभी आदानों के लिए एक कार्यक्रम को क्रियान्वित करना निषेधात्मक रूप से महंगा है। यदि उद्देश्य किसी प्रोग्राम को सभी इनपुट के लिए सही साबित करना है, तो एक औपचारिक विनिर्देश मौजूद होना चाहिए और औपचारिक तरीकों से तकनीकों का उपयोग किया जाना चाहिए।

बग उजागर करना

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

फ़ज़र को क्रैश के अलावा अन्य विफलताओं के प्रति अधिक संवेदनशील बनाने के लिए, विफलता का पता चलने पर प्रोग्राम को क्रैश करने वाले अभिकथनों को इंजेक्ट करने के लिए सैनिटाइज़र का उपयोग किया जा सकता है।[50][51] विभिन्न प्रकार के कीड़ों के लिए अलग-अलग सैनिटाइज़र हैं:

  • स्मृति संबंधी त्रुटियों का पता लगाने के लिए, जैसे कि बफर ओवरफ्लो और उपयोग-बाद-मुक्त (मेमोरी डिबगर्स जैसे पता प्रक्षालक का उपयोग करके),
  • दौड़ की स्थिति और गतिरोध का पता लगाने के लिए (थ्रेडसैनिटाइज़र),
  • अपरिभाषित व्यवहार का पता लगाने के लिए (अपरिभाषित व्यवहार सैनिटाइज़र),
  • मेमोरी लीक (लीकसैनिटाइज़र) का पता लगाने के लिए, या
  • नियंत्रण-प्रवाह अखंडता (CFISanitizer) की जांच करने के लिए।

यदि कोई संदर्भ कार्यान्वयन उपलब्ध है तो अंतर बग का पता लगाने के लिए फ़ज़िंग का भी उपयोग किया जा सकता है। स्वचालित प्रतिगमन परीक्षण के लिए,[52] उत्पन्न इनपुट एक ही प्रोग्राम के दो सॉफ्टवेयर वर्जनिंग पर निष्पादित होते हैं। स्वचालित अंतर परीक्षण के लिए,[53] जेनरेट किए गए इनपुट एक ही प्रोग्राम के दो कार्यान्वयन पर निष्पादित होते हैं (उदाहरण के लिए, lighttpd और httpd दोनों एक वेब सर्वर के कार्यान्वयन हैं)। यदि दो वेरिएंट एक ही इनपुट के लिए अलग-अलग आउटपुट देते हैं, तो एक छोटी गाड़ी हो सकती है और इसकी अधिक बारीकी से जांच की जानी चाहिए।

स्थिर विश्लेषण रिपोर्ट मान्य करना

स्थैतिक कार्यक्रम विश्लेषण किसी प्रोग्राम को वास्तव में निष्पादित किए गतिशील कार्यक्रम विश्लेषण करता है। इससे झूठी सकारात्मकता हो सकती है जहां उपकरण उस प्रोग्राम के साथ समस्याओं की रिपोर्ट करता है जो वास्तव में मौजूद नहीं है। डायनेमिक प्रोग्राम विश्लेषण के संयोजन में फ़ज़िंग का उपयोग एक इनपुट उत्पन्न करने का प्रयास करने के लिए किया जा सकता है जो वास्तव में रिपोर्ट की गई समस्या का गवाह है।[54]


ब्राउज़र सुरक्षा

आधुनिक वेब ब्राउज़र व्यापक फ़ज़िंग से गुजरते हैं। Google Chrome का क्रोमियम (वेब ​​​​ब्राउज़र) कोड क्रोम सुरक्षा टीम द्वारा 15,000 कोर के साथ लगातार फ़ज़ किया जाता है।[55] Microsoft Edge और Internet Explorer के लिए, Microsoft ने उत्पाद विकास के दौरान 670 मशीन-वर्षों के साथ फ़ज़्ड परीक्षण किया, जिससे 1 बिलियन HTML फ़ाइलों से 400 बिलियन से अधिक DOM मैनिपुलेशन उत्पन्न हुए।[56][55]


टूलचैन

एक फ़ज़र अपेक्षाकृत कम समय में बड़ी संख्या में इनपुट उत्पन्न करता है। उदाहरण के लिए, 2016 में Google OSS-fuzz प्रोजेक्ट ने एक सप्ताह में लगभग 4 ट्रिलियन (छोटा पैमाना) इनपुट का उत्पादन किया।[21]इसलिए, कई फ़ज़र्स एक toolchain प्रदान करते हैं जो अन्यथा मैन्युअल और थकाऊ कार्यों को स्वचालित करता है जो विफलता-उत्प्रेरण इनपुट की स्वचालित पीढ़ी का पालन करते हैं।

स्वचालित बग ट्राइएज

Main article: Bug triage

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

  • शोषक
  • शायद शोषक
  • शायद शोषक नहीं, या
  • अज्ञात।

पहले रिपोर्ट न किए गए, ट्राइएज्ड बग बग ट्रैकिंग सिस्टम को स्वचालित रूप से क्रैश रिपोर्टिंग कर सकते हैं। उदाहरण के लिए, OSS-Fuzz कई सुरक्षा-महत्वपूर्ण सॉफ़्टवेयर परियोजनाओं के लिए बड़े पैमाने पर, लंबे समय तक चलने वाले फ़ज़िंग अभियान चलाता है, जहाँ प्रत्येक पहले से अप्रतिबंधित, विशिष्ट बग सीधे बग ट्रैकर को रिपोर्ट किया जाता है।[21]OSS-Fuzz बग ट्रैकर स्वचालित रूप से कमजोर सॉफ़्टवेयर के सॉफ्टवेयर अनुरक्षक को सूचित करता है और नियमित अंतराल में जाँच करता है कि क्या बग को अपलोड किए गए न्यूनतम विफलता-उत्प्रेरण इनपुट का उपयोग करके सबसे हाल के सॉफ़्टवेयर संस्करण में ठीक किया गया है।

स्वचालित इनपुट न्यूनीकरण

स्वचालित इनपुट न्यूनीकरण (या टेस्ट केस रिडक्शन) विफलता-उत्प्रेरण इनपुट के उस हिस्से को अलग करने के लिए एक स्वचालित डिबगिंग तकनीक है जो वास्तव में विफलता को प्रेरित कर रही है।[59][60]यदि विफलता-उत्प्रेरण इनपुट बड़ा है और अधिकतर विकृत है, तो डेवलपर के लिए यह समझना मुश्किल हो सकता है कि वास्तव में बग का कारण क्या है। विफलता-उत्प्रेरण इनपुट को देखते हुए, एक स्वचालित न्यूनीकरण उपकरण मूल बग को पुन: उत्पन्न करते हुए जितना संभव हो उतने इनपुट बाइट्स को हटा देगा। उदाहरण के लिए, डेल्टा डिबगिंग एक स्वचालित इनपुट न्यूनीकरण तकनीक है जो इस तरह के न्यूनतम इनपुट को खोजने के लिए एक विस्तारित द्विआधारी खोज एल्गोरिथ्म को नियोजित करती है।[61]


लोकप्रिय फ़ज़र्स की सूची

See also: American fuzzy lop (fuzzer) § Forks

शैक्षिक साहित्य में लोकप्रिय, व्यापक रूप से उपयोग किए जाने वाले या समान के रूप में वर्णित फ़ज़र्स की सूची निम्नलिखित है।[62][63]

Name White/gray/black-box Smart/dumb Description Written in License
AFL[64][65] Gray Dumb C Apache 2.0


AFL++[66] Gray Dumb C Apache 2.0


AFLFast[67] Gray Dumb C Apache 2.0


Angora[68] Gray Dumb C++ Apache 2.0
honggfuzz[69][70] Gray Dumb C Apache 2.0
QSYM[71] [?] [?] [?] [?]
SymCC[72] White[73] [?] C++ GPL, LGPL


T-Fuzz[74] [?] [?] [?] [?]
VUzzer[75] [?] [?] [?] [?]


यह भी देखें

संदर्भ

  1. ↑ 1.0 1.1 John Neystadt (February 2008). "Automated Penetration Testing with White-Box Fuzzing". Microsoft. Retrieved 2009-05-14.
  2. ↑ Barton P. Miller (September 1988). "Fall 1988 CS736 Project List" (PDF). Computer Sciences Department, University of Wisconsin-Madison. Retrieved 2020-12-30.
  3. ↑ Barton P. Miller; Lars Fredriksen; Bryan So (December 1990). "An Empirical Study of the Reliability of UNIX Utilities". Communications of the ACM. 33 (11): 32-44. doi:10.1145/96267.96279. S2CID 14313707.
  4. ↑ "Fuzz Testing of Application Reliability". University of Wisconsin-Madison. Retrieved 2020-12-30.
  5. ↑ Barton P. Miller; David Koski; Cjin P. Lee; Vivekananda Maganty; Ravbi Murthy; Ajitkumar Natarajan; Jeff Steidl (April 1995). "Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services" (PDF). Computer Sciences Technical Report #1268, University of Wisconsin-Madison.
  6. ↑ Justin Forrester; Barton P. Miller (September 2000). "An Empirical Study of the Robustness of Windows NT Applications Using Random Testing" (PDF). 4th USENIX Windows Systems Symposium.
  7. ↑ "UNIX उपयोगिताओं की स्थिरता और विश्वसनीयता की जांच" (PDF). cs.wisc.edu. Retrieved 3 March 2023.
  8. ↑ Barton P. Miller; Gregory Cooksey; Fredrick Moore (July 2006). "An Empirical Study of the Robustness of MacOS Applications Using Random Testing" (PDF). First International Workshop on Random Testing.
  9. ↑ Barton P. Miller; Mengxiao Zhang; Elisa Heymann (2021). "The Relevance of Classic Fuzz Testing:Have We Solved This One?". IEEE Transactions on Software Engineering. 48 (6): 1. arXiv:2008.06537. doi:10.1109/TSE.2020.3047766. S2CID 221139874.
  10. ↑ 10.0 10.1 "Announcing ClusterFuzz". Retrieved 2017-03-09.
  11. ↑ Perlroth, Nicole (25 September 2014). "सुरक्षा विशेषज्ञ बैश में 'शेलशॉक' सॉफ्टवेयर बग के महत्वपूर्ण होने की अपेक्षा करते हैं". The New York Times. Retrieved 25 September 2014.
  12. ↑ Zalewski, Michał (1 October 2014). "Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78)". lcamtuf's blog. Retrieved 13 March 2017.
  13. ↑ Seltzer, Larry (29 September 2014). "शेलशॉक हार्टब्लीड को महत्वहीन बना देता है". ZDNet. Retrieved 29 September 2014.
  14. ↑ Böck, Hanno. "Fuzzing: Wie man Heartbleed hätte finden können (in German)". Golem.de (in Deutsch). Retrieved 13 March 2017.
  15. ↑ Böck, Hanno. "हार्टब्लीड कैसे पाया जा सकता था (अंग्रेज़ी में)". Hanno's blog. Retrieved 13 March 2017.
  16. ↑ "Search engine for the internet of things – devices still vulnerable to Heartbleed". shodan.io. Retrieved 13 March 2017.
  17. ↑ "Heartbleed Report (2017-01)". shodan.io. Retrieved 10 July 2017.
  18. ↑ Walker, Michael. "DARPA साइबर ग्रैंड चैलेंज". darpa.mil. Retrieved 12 March 2017.
  19. ↑ "तबाही सीजीसी में पहले स्थान पर आती है". Retrieved 12 March 2017.
  20. ↑ 20.0 20.1 "Announcing Project Springfield". 2016-09-26. Retrieved 2017-03-08.
  21. ↑ 21.0 21.1 21.2 21.3 "Announcing OSS-Fuzz". Retrieved 2017-03-08.
  22. ↑ Christopher Domas (August 2018). "GOD MODE UNLOCKED - Hardware Backdoors in x86 CPUs". Retrieved 2018-09-03.
  23. ↑ "Microsoft: Windows 10 is hardened with these fuzzing security tools – now they're open source". ZDNet. September 15, 2020.
  24. ↑ "Microsoft ओपन-सोर्स फ़ज़िंग टेस्ट फ्रेमवर्क". InfoWorld. September 17, 2020.
  25. ↑ Gerald M. Weinberg (2017-02-05). "Fuzz Testing and Fuzz History". Retrieved 2017-02-06.
  26. ↑ Joe W. Duran; Simeon C. Ntafos (1981-03-09). A report on random testing. Icse '81. Proceedings of the ACM SIGSOFT International Conference on Software Engineering (ICSE'81). pp. 179–183. ISBN 9780897911467.
  27. ↑ Joe W. Duran; Simeon C. Ntafos (1984-07-01). "An Evaluation of Random Testing". IEEE Transactions on Software Engineering. IEEE Transactions on Software Engineering (TSE) (4): 438–444. doi:10.1109/TSE.1984.5010257. S2CID 17208399.
  28. ↑ Andy Hertzfeld (2004). Revolution in the Valley:The Insanely Great Story of How the Mac Was Made?. O'Reily Press. ISBN 978-0596007195.
  29. ↑ "Macintosh Stories: Monkey Lives". Folklore.org. 1999-02-22. Retrieved 2010-05-28.
  30. ↑ "crashme". CodePlex. Retrieved 2021-05-21.
  31. ↑ Michael Sutton; Adam Greene; Pedram Amini (2007). Fuzzing: Brute Force Vulnerability Discovery. Addison-Wesley. ISBN 978-0-321-44611-4.
  32. ↑ Offutt, Jeff; Xu, Wuzhi (2004). "डेटा गड़बड़ी का उपयोग करके वेब सेवाओं के लिए टेस्ट केस तैयार करना". Workshop on Testing, Analysis and Verification of Web Services. 29 (5): 1–10. doi:10.1145/1022494.1022529. S2CID 52854851.
  33. ↑ Rebert, Alexandre; Cha, Sang Kil; Avgerinos, Thanassis; Foote, Jonathan; Warren, David; Grieco, Gustavo; Brumley, David (2014). "फ़ज़िंग के लिए बीज चयन का अनुकूलन" (PDF). Proceedings of the 23rd USENIX Conference on Security Symposium: 861–875.
  34. ↑ 34.0 34.1 34.2 Patrice Godefroid; Adam Kiezun; Michael Y. Levin. "Grammar-based Whitebox Fuzzing" (PDF). Microsoft Research.
  35. ↑ 35.0 35.1 35.2 Van-Thuan Pham; Marcel Böhme; Abhik Roychoudhury (2016-09-07). "Model-based whitebox fuzzing for program binaries". Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering - ASE 2016. Proceedings of Automated Software Engineering (ASE'16). pp. 543–553. doi:10.1145/2970276.2970316. ISBN 9781450338455. S2CID 5809364.
  36. ↑ 36.0 36.1 36.2 "Peach Fuzzer". Retrieved 2017-03-08.
  37. ↑ Greg Banks; Marco Cova; Viktoria Felmetsger; Kevin Almeroth; Richard Kemmerer; Giovanni Vigna. SNOOZE: Toward a Stateful NetwOrk prOtocol fuzZEr. Proceedings of the Information Security Conference (ISC'06).
  38. ↑ Osbert Bastani; Rahul Sharma; Alex Aiken; Percy Liang (June 2017). Synthesizing Program Input Grammars. Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 2017). arXiv:1608.01723. Bibcode:2016arXiv160801723B.
  39. ↑ "VDA Labs - Evolutionary Fuzzing System". Archived from the original on 2015-11-05. Retrieved 2009-05-14.
  40. ↑ 40.0 40.1 Ari Takanen; Jared D. Demott; Charles Miller (31 January 2018). Fuzzing for Software Security Testing and Quality Assurance, Second Edition. Artech House. p. 15. ISBN 978-1-63081-519-6. full document available (archived September 19, 2018)
  41. ↑ 41.0 41.1 Vijay Ganesh; Tim Leek; Martin Rinard (2009-05-16). "Taint-based directed whitebox fuzzing". IEEE. Proceedings of the ACM SIGSOFT International Conference on Software Engineering (ICSE'09).
  42. ↑ Wang, T.; Wei, T.; Gu, G.; Zou, W. (May 2010). TaintScope: A Checksum-Aware Directed Fuzzing Tool for Automatic Software Vulnerability Detection. pp. 497–512. CiteSeerX 10.1.1.169.7866. doi:10.1109/SP.2010.37. ISBN 978-1-4244-6894-2. S2CID 11898088. {{cite book}}: |journal= ignored (help)
  43. ↑ Patrice Godefroid; Michael Y. Levin; David Molnar (2008-02-08). "Automated Whitebox Fuzz Testing" (PDF). Proceedings of Network and Distributed Systems Symposium (NDSS'08).
  44. ↑ Marcel Böhme; Soumya Paul (2015-10-05). "A Probabilistic Analysis of the Efficiency of Automated Software Testing". IEEE Transactions on Software Engineering. 42 (4): 345–360. doi:10.1109/TSE.2015.2487274. S2CID 15927031.
  45. ↑ Nick Stephens; John Grosen; Christopher Salls; Andrew Dutcher; Ruoyu Wang; Jacopo Corbetta; Yan Shoshitaishvili; Christopher Kruegel; Giovanni Vigna (2016-02-24). Driller: Augmenting. Fuzzing Through Selective Symbolic Execution (PDF). Proceedings of Network and Distributed Systems Symposium (NDSS'16).
  46. ↑ Marcel Böhme; Van-Thuan Pham; Abhik Roychoudhury (2016-10-28). "Coverage-based Greybox Fuzzing as Markov Chain". Coverage-based Greybox Fuzzing as a Markov Chain. Proceedings of the ACM Conference on Computer and Communications Security (CCS'16). pp. 1032–1043. doi:10.1145/2976749.2978428. ISBN 9781450341394. S2CID 3344888.
  47. ↑ Hamlet, Richard G.; Taylor, Ross (December 1990). "विभाजन परीक्षण आत्मविश्वास को प्रेरित नहीं करता है". IEEE Transactions on Software Engineering. 16 (12): 1402–1411. doi:10.1109/32.62448.
  48. ↑ Weyuker, Elaine J. (1 November 1982). "गैर-परीक्षण योग्य कार्यक्रमों के परीक्षण पर". The Computer Journal. 25 (4): 465–470. doi:10.1093/comjnl/25.4.465.
  49. ↑ Barr, Earl T.; Harman, Mark; McMinn, Phil; Shahbaz, Muzammil; Yoo, Shin (1 May 2015). "The Oracle Problem in Software Testing: A Survey" (PDF). IEEE Transactions on Software Engineering. 41 (5): 507–525. doi:10.1109/TSE.2014.2372785. S2CID 7165993.
  50. ↑ "बजना संकलक प्रलेखन". clang.llvm.org. Retrieved 13 March 2017.
  51. ↑ "जीएनयू जीसीसी प्रक्षालक विकल्प". gcc.gnu.org. Retrieved 13 March 2017.
  52. ↑ Orso, Alessandro; Xie, Tao (2008). BERT: BEhavioral Regression Testing. pp. 36–42. doi:10.1145/1401827.1401835. ISBN 9781605580548. S2CID 7506576. {{cite book}}: |journal= ignored (help)
  53. ↑ McKeeman, William M. (1998). "सॉफ्टवेयर के लिए विभेदक परीक्षण" (PDF). Digital Technical Journal. 10 (1): 100–107.
  54. ↑ Babić, Domagoj; Martignoni, Lorenzo; McCamant, Stephen; Song, Dawn (2011). स्टेटिकली-डायरेक्टेड डायनामिक ऑटोमेटेड टेस्ट जेनरेशन. pp. 12–22. doi:10.1145/2001420.2001423. ISBN 9781450305624. S2CID 17344927. {{cite book}}: |journal= ignored (help)
  55. ↑ 55.0 55.1 Sesterhenn, Eric; Wever, Berend-Jan; Orrù, Michele; Vervier, Markus (19 Sep 2017). "ब्राउज़र सुरक्षा श्वेतपत्र" (PDF). X41D SEC GmbH.
  56. ↑ "Microsoft Edge के लिए सुरक्षा संवर्द्धन (IT पेशेवरों के लिए Microsoft Edge)". Microsoft. 15 Oct 2017. Retrieved 31 August 2018.
  57. ↑ "सीईआरटी ट्राइएज टूल्स". CERT Division of the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU). Retrieved 14 March 2017.
  58. ↑ "माइक्रोसॉफ्ट! शोषक क्रैश विश्लेषक". CodePlex. Retrieved 14 March 2017.
  59. ↑ "Test Case Reduction". 2011-07-18.
  60. ↑ "IBM Test Case Reduction Techniques". 2011-07-18. Archived from the original on 2016-01-10. Retrieved 2011-07-18.
  61. ↑ Zeller, Andreas; Hildebrandt, Ralf (February 2002). "विफलता-प्रेरक इनपुट को सरल बनाना और अलग करना". IEEE Transactions on Software Engineering. 28 (2): 183–200. CiteSeerX 10.1.1.180.3357. doi:10.1109/32.988498. ISSN 0098-5589. Retrieved 14 March 2017.
  62. ↑ Hazimeh, Ahmad; Herrera, Adrian; Payer, Mathias (2021-06-15). "Magma: A Ground-Truth Fuzzing Benchmark". Proceedings of the ACM on Measurement and Analysis of Computing Systems. 4 (3): 49:1–49:29. arXiv:2009.01120. doi:10.1145/3428334. S2CID 227230949.
  63. ↑ Li, Yuwei; Ji, Shouling; Chen, Yuan; Liang, Sizhuang; Lee, Wei-Han; Chen, Yueyao; Lyu, Chenyang; Wu, Chunming; Beyah, Raheem; Cheng, Peng; Lu, Kangjie; Wang, Ting (2021). {UNIFUZZ}: A Holistic and Pragmatic {Metrics-Driven} Platform for Evaluating Fuzzers (in English). pp. 2777–2794. ISBN 978-1-939133-24-3.
  64. ↑ Hazimeh, Herrera & Payer 2021, p. 1: "We evaluate seven widely-used mutation-based fuzzers (AFL, ...)".
  65. ↑ Li et al. 2021, p. 1: "Using UniFuzz, we conduct in-depth evaluations of several prominent fuzzers including AFL, ...".
  66. ↑ Hazimeh, Herrera & Payer 2021, p. 1: "We evaluate seven widely-used mutation-based fuzzers (..., AFL++, ...)".
  67. ↑ Li et al. 2021, p. 1: "Using UniFuzz, we conduct in-depth evaluations of several prominent fuzzers including AFL, AFLFast, ...".
  68. ↑ Li et al. 2021, p. 1: "Using UniFuzz, we conduct in-depth evaluations of several prominent fuzzers including AFL, ..., Angora, ...".
  69. ↑ Hazimeh, Herrera & Payer 2021, p. 1: "We evaluate seven widely-used mutation-based fuzzers (..., honggfuzz, ...)".
  70. ↑ Li et al. 2021, p. 1: "Using UniFuzz, we conduct in-depth evaluations of several prominent fuzzers including AFL, ..., Honggfuzz, ...".
  71. ↑ Li et al. 2021, p. 1: "Using UniFuzz, we conduct in-depth evaluations of several prominent fuzzers including AFL, ..., QSYM, ...".
  72. ↑ Hazimeh, Herrera & Payer 2021, p. 1: "We evaluate seven widely-used mutation-based fuzzers (..., and SymCC-AFL)".
  73. ↑ Hazimeh, Herrera & Payer 2021, p. 14.
  74. ↑ Li et al. 2021, p. 1: "Using UniFuzz, we conduct in-depth evaluations of several prominent fuzzers including AFL, ..., T-Fuzz, ...".
  75. ↑ Li et al. 2021, p. 1: "Using UniFuzz, we conduct in-depth evaluations of several prominent fuzzers including AFL, ..., and VUzzer64.".


अग्रिम पठन


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=फज़िंग&oldid=171272’