फज़िंग

From Vigyanwiki
श्रृंखला का हिस्सा
सूचना सुरक्षा
vectorial version
सुरक्षा संबंधित श्रेणियां
थ्रेट्स
डिफेंसेस

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

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

इतिहास

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

प्रकार

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

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

उपस्थित इनपुट बीजों का पुन: उपयोग

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

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

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

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

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

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

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

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

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

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

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

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

उपयोग करता है

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

बग उजागर करना

बग को उजागर करने के लिए, एक फजर को अप्रत्याशित (बग्गी) प्रोग्राम व्यवहार से अपेक्षित (सामान्य) को अलग करने में सक्षम होता है। चूँकि, एक मशीन हमेशा बग को फीचर से अलग नहीं कर सकता है। स्वचालित सॉफ़्टवेयर परीक्षण में, इसे परीक्षण ऑरेकल समस्या भी कहा जाता है।[48][49]

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

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

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

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

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

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

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

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

उपकरण श्रंखला

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

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

Main article: बग ट्राइएज

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

  • शोषक
  • संभवतः शोषक
  • संभवतः शोषक नहीं, या
  • अज्ञात।

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

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

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

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

See also: अमेरिकन फ़ज़ी लोप (फ़ज़र) § फोर्क्स

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

नाम सफेद/ग्रे/ब्लैक-बॉक्स स्मार्ट / गूंगा विवरण इसमें लिखा हुआ लाइसेंस
एएफएल[64][65] ग्रे गूंगा सी अपाचे 2.0


एएफएल ++[66] ग्रे गूंगा सी अपाचे 2.0


एएफएलफास्ट[67] ग्रे गूंगा सी अपाचे 2.0


अंगोरा[68] ग्रे गूंगा सी++ अपाचे 2.0
हाँगफ़ज़[69][70] ग्रे गूंगा सी अपाचे 2.0
क्यूएसवाईएम[71] [?] [?] [?] [?]
सिमसीसी[72] सफेद[73] [?] सी++ जीपीएल, एलजीपीएल
टी-फ़ज़[74] [?] [?] [?] [?]
वीउज़र[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=172151’