التشويش

📅 آخر تحديث: ١٩ يوليو ٢٠٢٦
✍️ نُشر في: ١٩ يوليو ٢٠٢٦
📷 يحتوي على 1 صور
الموسوعة الحرة
برنامج اختباري لـ American Fuzzy Lop 's afl-fuzz

في مجال البرمجة وتطوير البرمجيات ، يُعدّ اختبار التشويش ( Fuzzing ) أسلوبًا آليًا لاختبار البرمجيات ، يتضمن إدخال بيانات غير صالحة أو غير متوقعة أو عشوائية إلى برنامج حاسوبي . ثم يُراقَب البرنامج بحثًا عن استثناءات مثل الأعطال ، أو فشل تأكيدات التعليمات البرمجية المضمنة ، أو تسريبات الذاكرة المحتملة . عادةً ما تُستخدم أدوات اختبار التشويش لاختبار البرامج التي تستقبل مدخلات مُهيكلة. تُحدَّد هذه الهيكلية، كما في تنسيق ملف أو بروتوكول ، وتُميِّز بين المدخلات الصالحة وغير الصالحة. تُولِّد أداة اختبار التشويش الفعّالة مدخلات شبه صالحة، وهي "صالحة بما يكفي" بمعنى أنها لا تُرفض مباشرةً من قِبَل المُحلِّل، ولكنها تُسبِّب سلوكيات غير متوقعة في أجزاء أعمق من البرنامج، وهي "غير صالحة بما يكفي" لكشف حالات استثنائية لم تُعالَج بشكل صحيح.

لأغراض أمنية، غالباً ما تكون المدخلات التي تتجاوز حدود الثقة هي الأكثر فائدة. [ 1 ] على سبيل المثال، من الأهمية بمكان اختبار الكود الذي يتعامل مع ملف تم تحميله من قبل أي مستخدم، بدلاً من اختبار الكود الذي يحلل ملف تكوين لا يمكن الوصول إليه إلا من قبل مستخدم ذي صلاحيات.

تاريخ

مصطلح "الاختبار الضبابي" (fuzz) نشأ من مشروع دراسي عام 1988 [ 2 ] ضمن مقرر أنظمة التشغيل المتقدمة (CS736) لطلاب الدراسات العليا، والذي كان يُدرّسه البروفيسور بارتون ميلر في جامعة ويسكونسن ، ونُشرت نتائجه لاحقًا عام 1990. [ 3 ] [ 4 ] كان الهدف من هذا المشروع اختبار موثوقية أداة يونكس المصممة لتوليد مُدخلات عشوائية ومعاملات سطر أوامر تلقائيًا. صُمم المشروع لاختبار موثوقية برامج سطر أوامر يونكس من خلال تنفيذ عدد كبير من المُدخلات العشوائية بتتابع سريع حتى تتعطل. تمكن فريق ميلر من تعطيل ما بين 25 و33% من الأدوات التي اختبروها. ثم قاموا بتصحيح كل عطل لتحديد السبب وتصنيف كل حالة فشل مُكتشفة. ولتمكين الباحثين الآخرين من إجراء تجارب مماثلة مع برامج أخرى، أُتيحت شفرة المصدر للأدوات وإجراءات الاختبار وبيانات النتائج الأولية للعموم. [ 5 ] يُطلق على هذا الاختبار المبكر الآن اسم اختبار الصندوق الأسود، والاختبار التوليدي، والاختبار غير المنظم (الغبي أو "الكلاسيكي").

بحسب البروفيسور بارتون ميلر، "أثناء كتابة وصف المشروع، احتجت إلى تسمية هذا النوع من الاختبارات. أردت اسماً يوحي بشعور البيانات العشوائية وغير المنظمة. بعد تجربة عدة أفكار، استقرت على مصطلح "الضبابية". [ 4 ]

كان من أهم إسهامات هذا العمل المبكر وجود نظام أوراكل بسيط (يكاد يكون مبسطًا). يُعتبر البرنامج فاشلاً في الاختبار إذا تعطل أو توقف عند إدخال بيانات عشوائية، ويُعتبر ناجحًا في غير ذلك. مع أن بناء أنظمة أوراكل الاختبار قد يكون صعبًا، إلا أن نظام أوراكل هذا الاختبار المبكر كان بسيطًا وسهل التطبيق.

في أبريل 2012، أعلنت جوجل عن ClusterFuzz، وهي بنية تحتية سحابية لاختبار أمان المكونات الحساسة لمتصفح الويب Chromium . [ 6 ] يمكن لباحثي الأمن تحميل أدوات الاختبار الخاصة بهم والحصول على مكافآت مالية إذا اكتشف ClusterFuzz عطلاً في أداة الاختبار التي تم تحميلها.

في سبتمبر 2014، تم الكشف عن ثغرة Shellshock [ 7 ] كمجموعة من الثغرات الأمنية في بيئة Bash البرمجية واسعة الانتشار في أنظمة UNIX ؛ وقد تم اكتشاف معظم ثغرات Shellshock باستخدام أداة اختبار الثغرات AFL . [ 8 ] (تستخدم العديد من الخدمات المتصلة بالإنترنت، مثل بعض خوادم الويب، بيئة Bash لمعالجة طلبات معينة، مما يسمح للمهاجم بالتسبب في تنفيذ أوامر عشوائية في إصدارات Bash المعرضة للثغرات . وهذا بدوره قد يُمكّن المهاجم من الوصول غير المصرح به إلى نظام الحاسوب. [ 9 ] )

في أبريل 2015، أوضح هانو بوك كيف كان بإمكان أداة اختبار الثغرات AFL اكتشاف ثغرة Heartbleed التي ظهرت عام 2014. [ 10 ] [ 11 ] ( تم الكشف عن ثغرة Heartbleed في أبريل 2014. وهي ثغرة خطيرة تسمح للمهاجمين بفك تشفير الاتصالات المشفرة . وقد أُدخلت هذه الثغرة عن طريق الخطأ إلى مكتبة OpenSSL التي تُطبّق بروتوكول TLS وتستخدمها غالبية الخوادم على الإنترنت. وأفادت منصة Shodan بوجود 238,000 جهاز لا تزال عرضة لهذه الثغرة في أبريل 2016؛ [ 12 ] و200,000 جهاز في يناير 2017. [ 13 ] )

في أغسطس/آب 2016، عقدت وكالة مشاريع البحوث الدفاعية المتقدمة (DARPA) نهائيات التحدي السيبراني الكبير الأول ، وهي مسابقة آلية بالكامل تعتمد على أسلوب "التقاط العلم" واستمرت 11 ساعة. [ 14 ] كان الهدف هو تطوير أنظمة دفاع آلية قادرة على اكتشاف ثغرات البرمجيات واستغلالها وتصحيحها في الوقت الفعلي . استُخدم اختبار البرمجيات العشوائي (Fuzzing) كاستراتيجية هجومية فعّالة لاكتشاف الثغرات في برمجيات الخصوم، وقد أظهر إمكانات هائلة في أتمتة اكتشاف نقاط الضعف. فاز بالمسابقة نظام يُدعى "Mayhem" [ 15 ] طوّره فريق ForAllSecure بقيادة ديفيد بروملي .

في سبتمبر 2016، أعلنت مايكروسوفت عن مشروع سبرينغفيلد، وهو خدمة اختبار عشوائي قائمة على الحوسبة السحابية لاكتشاف الأخطاء الأمنية الحرجة في البرامج. [ 16 ]

في ديسمبر 2016، أعلنت جوجل عن OSS-Fuzz الذي يسمح بإجراء اختبارات مستمرة على العديد من مشاريع المصادر المفتوحة ذات الأهمية الأمنية البالغة. [ 17 ]

في مؤتمر بلاك هات 2018، عرض كريستوفر دوماس استخدام تقنية اختبار البرمجيات العشوائي (fuzzing) للكشف عن وجود نواة RISC مخفية في المعالج. [ 18 ] وقد تمكنت هذه النواة من تجاوز إجراءات التحقق الأمني ​​الحالية لتنفيذ أوامر المستوى 0 من المستوى 3.

في سبتمبر 2020، أطلقت مايكروسوفت منصة OneFuzz ، وهي منصة اختبار برمجيات ذاتية الاستضافة تعمل كخدمة، وتُسهّل اكتشاف أخطاء البرمجيات . [ 19 ] تدعم المنصة نظامي التشغيل ويندوز ولينكس. [ 20 ] تم أرشفة المنصة بعد ثلاث سنوات، في 1 نوفمبر 2023. [ 21 ]

الاختبار العشوائي المبكر

يعود تاريخ اختبار البرامج باستخدام مدخلات عشوائية إلى خمسينيات القرن الماضي، عندما كانت البيانات لا تزال تُخزن على بطاقات مثقبة . [ 22 ] كان المبرمجون يستخدمون بطاقات مثقبة تُسحب من سلة المهملات أو من مجموعات بطاقات الأرقام العشوائية كمدخلات لبرامج الحاسوب. إذا كشف التنفيذ عن سلوك غير مرغوب فيه، فهذا يعني اكتشاف خطأ برمجي .

يُطلق على تنفيذ المدخلات العشوائية أيضًا اسم الاختبار العشوائي أو اختبار القرد أو تصحيح الأخطاء مونت كارلو [ 23 ] (على غرار طرق مونت كارلو ).

في عام 1981، قام دوران ونتافوس بدراسة رسمية لفعالية اختبار برنامج باستخدام مدخلات عشوائية. [ 24 ] [ 25 ] على الرغم من أن الاختبار العشوائي كان يُنظر إليه على نطاق واسع على أنه أسوأ وسيلة لاختبار برنامج، إلا أن الباحثين استطاعوا إثبات أنه بديل فعال من حيث التكلفة لتقنيات الاختبار الأكثر منهجية.

في عام ١٩٨٣، طوّر ستيف كابس في شركة آبل أداة "القرد" [ ٢٦ ] ، وهي أداة تُولّد مدخلات عشوائية لتطبيقات نظام التشغيل ماك الكلاسيكية ، مثل برنامج ماك بينت [ ٢٧ ] . يشير مصطلح "القرد" هنا مجازيًا إلى نظرية القرد اللانهائي ، التي تنص على أن قردًا يضغط عشوائيًا على مفاتيح لوحة مفاتيح آلة كاتبة لفترة غير محدودة سيتمكن في النهاية من كتابة جميع أعمال شكسبير. في حالة الاختبار، كان القرد يكتب تسلسلًا محددًا من المدخلات يؤدي إلى تعطل النظام.

في عام 1991، تم إصدار أداة crashme، والتي كانت تهدف إلى اختبار متانة أنظمة التشغيل Unix والأنظمة الشبيهة بـ Unix عن طريق تنفيذ استدعاءات النظام بشكل عشوائي باستخدام معلمات مختارة عشوائيًا. [ 28 ]

الأنواع

يمكن تصنيف أداة اختبار التشويش بعدة طرق: [ 29 ] [ 1 ]

  1. يمكن أن يكون برنامج اختبار التشويش قائمًا على التوليد أو قائمًا على الطفرة اعتمادًا على ما إذا كانت المدخلات يتم إنشاؤها من الصفر أو عن طريق تعديل المدخلات الموجودة.
  2. يمكن أن يكون جهاز اختبار التشويش غبيًا (غير منظم) أو ذكيًا (منظمًا) اعتمادًا على ما إذا كان على دراية ببنية الإدخال.
  3. يمكن أن يكون برنامج الفحص العشوائي (fuzzer) من نوع الصندوق الأبيض أو الرمادي أو الأسود، وذلك اعتمادًا على ما إذا كان على دراية ببنية البرنامج أم لا.

إعادة استخدام بذور الإدخال الموجودة

يستفيد نظام اختبار البرمجيات القائم على الطفرات من مجموعة بيانات موجودة مسبقًا من المدخلات الأولية أثناء عملية الاختبار. ويقوم هذا النظام بتوليد المدخلات عن طريق تعديل (أو بالأحرى تحوير ) المدخلات الأولية المُقدمة. [ 30 ] على سبيل المثال، عند اختبار مكتبة الصور libpng ، يُقدم المستخدم مجموعة من ملفات صور PNG صالحة كمدخلات أولية، بينما يقوم نظام اختبار البرمجيات القائم على الطفرات بتعديل هذه المدخلات الأولية لإنتاج نسخ شبه صالحة من كل مدخل أولي. قد تحتوي مجموعة ملفات المدخلات الأولية على آلاف المدخلات المتشابهة المحتملة. يتيح الاختيار التلقائي للمدخلات الأولية (أو تقليل مجموعة الاختبار) للمستخدمين اختيار أفضل المدخلات الأولية لزيادة إجمالي عدد الأخطاء المكتشفة أثناء حملة الاختبار. [ 31 ]

يقوم مُختبِر الأجيال بتوليد المدخلات من الصفر. على سبيل المثال، يأخذ مُختبِر الأجيال الذكي [ 32 ] نموذج الإدخال الذي قدمه المستخدم لتوليد مدخلات جديدة. على عكس مُختبِرات الطفرة، لا يعتمد مُختبِر الأجيال على وجود أو جودة مجموعة من المدخلات الأولية.

تتمتع بعض أدوات اختبار التشويش بالقدرة على القيام بالأمرين معاً، أي توليد المدخلات من الصفر وتوليد المدخلات عن طريق تعديل البذور الموجودة. [ 33 ]

على دراية ببنية الإدخال

تُستخدم أدوات اختبار البرمجيات عادةً لتوليد مدخلات للبرامج التي تستقبل مدخلات مُهيكلة، مثل ملف ، أو سلسلة من أحداث لوحة المفاتيح أو الفأرة ، أو سلسلة من الرسائل . يُميّز هذا الهيكل المدخلات الصحيحة التي يقبلها البرنامج ويعالجها عن المدخلات غير الصحيحة التي يرفضها البرنامج فورًا. يمكن تحديد ما يُعتبر مدخلًا صحيحًا بشكل صريح في نموذج الإدخال. من أمثلة نماذج الإدخال: القواعد النحوية الرسمية ، وتنسيقات الملفات ، ونماذج واجهة المستخدم الرسومية ، وبروتوكولات الشبكة . حتى العناصر التي لا تُعتبر عادةً مدخلات يمكن اختبارها، مثل محتويات قواعد البيانات ، والذاكرة المشتركة ، ومتغيرات البيئة ، أو التداخل الدقيق للخيوط . تُولّد أداة اختبار البرمجيات الفعّالة مدخلات شبه صحيحة، وهي "صحيحة بما يكفي" بحيث لا يرفضها المُحلل اللغوي مباشرةً ، و"غير صحيحة بما يكفي" بحيث تُثير حالات استثنائية وتُفعّل سلوكيات برمجية مثيرة للاهتمام.

تستفيد أداة الفحص الذكي (القائم على النموذج، [ 33 ] أو القواعد، [ 32 ] [ 34 ] أو البروتوكول [ 35 ] ) من نموذج الإدخال لتوليد نسبة أكبر من المدخلات الصحيحة. على سبيل المثال، إذا أمكن نمذجة الإدخال كشجرة بناء جملة مجردة ، فإن أداة الفحص الذكي القائمة على الطفرات [ 34 ] ستستخدم تحويلات عشوائية لنقل الأشجار الفرعية الكاملة من عقدة إلى أخرى. أما إذا أمكن نمذجة الإدخال بقواعد نحوية رسمية ، فإن أداة الفحص الذكي القائمة على التوليد [ 32 ] ستُفعّل قواعد الإنتاج لتوليد مدخلات صحيحة وفقًا لتلك القواعد. مع ذلك، يتطلب الأمر عادةً توفير نموذج الإدخال بشكل صريح، وهو أمر يصعب تحقيقه عندما يكون النموذج خاصًا أو غير معروف أو معقدًا للغاية. في حال توفر مجموعة كبيرة من المدخلات الصحيحة وغير الصحيحة، يمكن لتقنية استقراء القواعد ، مثل خوارزمية L* الخاصة بأنجلوين ، توليد نموذج إدخال. [ 36 ] [ 37 ]

لا يتطلب برنامج الفحص البسيط [ 38 ] [ 39 ] نموذج الإدخال، وبالتالي يمكن استخدامه لفحص مجموعة أوسع من البرامج. على سبيل المثال، AFL هو برنامج فحص بسيط يعتمد على الطفرات، حيث يُعدّل ملفًا أوليًا عن طريق قلب بتات عشوائية ، واستبدال بايتات عشوائية بقيم "مُثيرة للاهتمام"، ونقل أو حذف كتل من البيانات. مع ذلك، قد يُولّد برنامج الفحص البسيط نسبة أقل من المدخلات الصحيحة، ويُجهد كود المُحلِّل بدلاً من المكونات الرئيسية للبرنامج. يُمكن توضيح عيب برامج الفحص البسيطة من خلال إنشاء مجموع اختباري صحيح لفحص التكرار الدوري (CRC). فحص التكرار الدوري هو رمز لكشف الأخطاء يضمن الحفاظ على سلامة البيانات الموجودة في ملف الإدخال أثناء الإرسال . يتم حساب مجموع اختباري على بيانات الإدخال وتسجيله في الملف. عندما يُعالج البرنامج الملف المُستلم، ولا يتطابق المجموع الاختباري المُسجل مع المجموع الاختباري المُعاد حسابه، يتم رفض الملف باعتباره غير صالح. من غير المرجح أن يقوم برنامج اختبار عشوائي لا يتعرف على رمز التحقق الدوري (CRC) بتوليد مجموع التحقق الصحيح. ومع ذلك، تُبذل محاولات لتحديد وإعادة حساب مجموع التحقق المحتمل في المدخلات المُعدَّلة، بمجرد أن يقوم برنامج اختبار عشوائي بسيط يعتمد على التعديل بتعديل البيانات المحمية. [ 40 ]

على دراية ببنية البرنامج

عادةً، يُعتبر برنامج فحص الأخطاء أكثر فعالية إذا حقق تغطيةً أكبر للكود . والسبب في ذلك هو أنه إذا لم يختبر البرنامج عناصر هيكلية معينة فيه، فلن يتمكن من كشف الأخطاء الكامنة فيها. بعض عناصر البرنامج أكثر أهمية من غيرها. على سبيل المثال، قد يتسبب عامل القسمة في خطأ القسمة على صفر ، أو قد يؤدي استدعاء نظام إلى تعطل البرنامج.

يتعامل مُختبِر الصندوق الأسود [ 38 ] [ 34 ] مع البرنامج كصندوق أسود ، ولا يُدرك بنيته الداخلية. على سبيل المثال، تُعتبر أداة الاختبار العشوائي التي تُولّد مُدخلات عشوائية مُختبِر صندوق أسود. وبالتالي، يُمكن لمُختبِر الصندوق الأسود تنفيذ مئات المُدخلات في الثانية، كما يُمكن موازاته بسهولة، ويُمكن توسيعه ليشمل برامج ذات أحجام مُختلفة. مع ذلك، قد لا يكشف مُختبِر الصندوق الأسود إلا عن الثغرات السطحية. لذلك، تُبذل جهود لتطوير مُختبِرات صندوق أسود قادرة على التعلّم تدريجيًا عن البنية الداخلية (وسلوك) البرنامج أثناء عملية الاختبار، وذلك من خلال مُراقبة مُخرجات البرنامج عند إدخال مُدخلات مُعينة. على سبيل المثال، تستخدم مكتبة LearnLib التعلّم النشط لإنشاء آلة تُمثل سلوك تطبيق ويب.

يستفيد مُختبِر الصندوق الأبيض [ 39 ] [ 33 ] من تحليل البرنامج لزيادة تغطية الكود بشكل منهجي أو للوصول إلى مواقع حرجة مُحددة في البرنامج. على سبيل المثال، يستفيد SAGE [ 41 ] من التنفيذ الرمزي لاستكشاف مسارات مختلفة في البرنامج بشكل منهجي (وهي تقنية تُعرف بالتنفيذ الرمزي ). إذا كانت مواصفات البرنامج مُتاحة، فقد يستفيد مُختبِر الصندوق الأبيض من تقنيات الاختبار القائم على النموذج لتوليد مُدخلات وفحص مُخرجات البرنامج مُقارنةً بمواصفاته. يُمكن أن يكون مُختبِر الصندوق الأبيض فعالاً للغاية في كشف الأخطاء المُختبئة في أعماق البرنامج. مع ذلك، قد يُصبح الوقت المُستغرق في التحليل (للبرنامج أو مواصفاته) مُكلفًا للغاية. إذا استغرق مُختبِر الصندوق الأبيض وقتًا طويلاً نسبيًا لتوليد مُدخل، فسيكون مُختبِر الصندوق الأسود أكثر كفاءة. [ 42 ] لذا، تُبذل محاولات للجمع بين كفاءة مُختبِرات الصندوق الأسود وفعالية مُختبِرات الصندوق الأبيض. [ 43 ]

تعتمد أدوات فحص الثغرات الأمنية ذات الصندوق الرمادي على أدوات القياس بدلاً من تحليل البرنامج لاستخلاص معلومات عنه. على سبيل المثال، تستخدم كل من AFL وlibFuzzer أدوات قياس خفيفة لتتبع انتقالات الكتل الأساسية التي يُجريها مُدخل ما. يؤدي هذا إلى زيادة طفيفة في الأداء، ولكنه يُعلم أداة الفحص بزيادة تغطية الكود أثناء الفحص، مما يجعل أدوات فحص الثغرات الأمنية ذات الصندوق الرمادي أدوات فعالة للغاية في اكتشاف الثغرات الأمنية. [ 44 ]

الاستخدامات

يُستخدم اختبار البرمجيات العشوائي (Fuzzing) في الغالب كتقنية آلية لكشف الثغرات الأمنية في البرامج الحساسة أمنيًا، والتي قد تُستغل لأغراض خبيثة. [ 6 ] [ 16 ] [ 17 ] وبشكل عام، يُستخدم اختبار البرمجيات العشوائي لإثبات وجود الأخطاء البرمجية لا عدم وجودها. فإجراء حملة اختبار عشوائي لعدة أسابيع دون العثور على خطأ لا يُثبت صحة البرنامج. [ 45 ] ففي النهاية، قد يفشل البرنامج مع مُدخل لم يُنفذ بعد؛ إذ أن تنفيذ البرنامج لجميع المُدخلات مُكلف للغاية. إذا كان الهدف هو إثبات صحة البرنامج لجميع المُدخلات، فلا بد من وجود مواصفات رسمية واستخدام تقنيات من الأساليب الرسمية .

كشف الأخطاء

للكشف عن الأخطاء البرمجية، يجب أن يكون برنامج الفحص العشوائي قادرًا على التمييز بين السلوك المتوقع (الطبيعي) والسلوك غير المتوقع (الذي يحتوي على أخطاء). مع ذلك، لا يستطيع الجهاز دائمًا التمييز بين الخطأ والميزة. في اختبار البرمجيات الآلي ، يُطلق على هذه المشكلة أيضًا اسم " مشكلة مرجع الاختبار ". [ 46 ] [ 47 ]

عادةً، يميز برنامج اختبار الثغرات بين المدخلات التي تتسبب في حدوث أعطال وتلك التي لا تتسبب بها، وذلك في غياب المواصفات ، مستخدمًا مقياسًا بسيطًا وموضوعيًا. يمكن تحديد الأعطال بسهولة، وقد تشير إلى ثغرات أمنية محتملة (مثل هجمات حجب الخدمة أو تنفيذ تعليمات برمجية عشوائية ). مع ذلك، فإن عدم حدوث عطل لا يعني بالضرورة عدم وجود ثغرة أمنية. على سبيل المثال، قد يتعطل برنامج مكتوب بلغة C أو لا يتعطل عند حدوث خطأ في تجاوز سعة المخزن المؤقت . في الواقع، سلوك البرنامج غير محدد .

لجعل أداة اختبار الأخطاء أكثر حساسية للأعطال الأخرى غير الانهيارات، يمكن استخدام أدوات التنظيف لإدخال تأكيدات تؤدي إلى انهيار البرنامج عند اكتشاف عطل. [ 48 ] [ 49 ] توجد أدوات تنظيف مختلفة لأنواع مختلفة من الأخطاء:

يمكن استخدام اختبار التشويش (Fuzzing) أيضًا للكشف عن الأخطاء "التفاضلية" في حال توفر تطبيق مرجعي . في اختبار الانحدار الآلي [ 50 ] ، تُنفَّذ المدخلات المُولَّدة على نسختين من البرنامج نفسه. أما في اختبار التفاضل الآلي [ 51 ] ، فتُنفَّذ المدخلات المُولَّدة على تطبيقين للبرنامج نفسه (على سبيل المثال، يُعد كل من lighttpd و httpd تطبيقين لخادم ويب). إذا أنتجت النسختان مخرجات مختلفة لنفس المدخلات، فقد تكون إحداهما معيبة، ويجب فحصها بدقة أكبر.

التحقق من صحة تقارير التحليل الثابت

يُحلل تحليل البرامج الثابت البرنامج دون تنفيذه فعليًا. قد يؤدي ذلك إلى نتائج إيجابية خاطئة، حيث تُبلغ الأداة عن مشاكل في البرنامج غير موجودة في الواقع. يمكن استخدام اختبار التشويه (Fuzzing) بالتزامن مع تحليل البرامج الديناميكي لمحاولة توليد مدخلات تُظهر المشكلة المُبلغ عنها بالفعل. [ 52 ]

أمان المتصفح

تخضع متصفحات الويب الحديثة لاختبارات عشوائية مكثفة. يقوم فريق أمان جوجل كروم باختبار شفرة كروميوم الخاصة به باستمرار باستخدام 15000 نواة معالجة. [ 53 ] أما بالنسبة لمتصفحي مايكروسوفت إيدج (القديم) وإنترنت إكسبلورر ، فقد أجرت مايكروسوفت اختبارات عشوائية استغرقت 670 سنة حاسوبية خلال تطوير المنتج، مما أدى إلى توليد أكثر من 400 مليار عملية معالجة لنموذج كائن المستند (DOM) من مليار ملف HTML. [ 54 ] [ 53 ]  

مجموعة الأدوات

يُنتج برنامج اختبار البرمجيات العشوائي (fuzzer) عددًا كبيرًا من المدخلات في وقت قصير نسبيًا. على سبيل المثال، في عام 2016، أنتج مشروع Google OSS-fuzz حوالي 4 تريليونات مدخل أسبوعيًا. [ 17 ] ولذلك، توفر العديد من برامج اختبار البرمجيات العشوائي سلسلة أدوات تُؤتمت المهام اليدوية الشاقة التي تلي التوليد الآلي للمدخلات المُسببة للأعطال.

فرز الأخطاء الآلي

يُستخدم الفرز الآلي للأخطاء البرمجية لتجميع عدد كبير من المدخلات المُسببة للأعطال حسب السبب الجذري ، ولتحديد أولوية كل خطأ على حدة حسب شدته. يُنتج برنامج فحص الأخطاء عددًا كبيرًا من المدخلات، وقد يكشف العديد منها عن نفس الخطأ البرمجي . بعض هذه الأخطاء فقط حرجة أمنيًا ، ويجب معالجتها بأولوية أعلى. على سبيل المثال، يُوفر مركز تنسيق الاستجابة لحوادث أمن الحاسوب (CERT) أدوات فرز أخطاء لينكس التي تُصنف المدخلات المُسببة للأعطال حسب تتبع المكدس الناتج ، وتُدرج كل مجموعة وفقًا لاحتمالية استغلالها . [ 55 ] طوّر مركز أبحاث أمن مايكروسوفت (MSEC) أداة "!exploitable" التي تُنشئ أولًا قيمة تجزئة للمدخل المُسبب للأعطال لتحديد تفرده، ثم تُحدد تصنيفًا لإمكانية استغلاله. [ 56 ]

  • قابل للاستغلال
  • قابل للاستغلال على الأرجح
  • ربما غير قابل للاستغلال، أو
  • مجهول.

قد يتم الإبلاغ تلقائيًا عن الأخطاء التي لم يتم الإبلاغ عنها سابقًا والتي تم تصنيفها إلى نظام تتبع الأخطاء . على سبيل المثال، يُجري مشروع OSS-Fuzz حملات اختبار واسعة النطاق وطويلة الأمد لعدة مشاريع برمجية بالغة الأهمية من الناحية الأمنية، حيث يتم الإبلاغ عن كل خطأ مختلف لم يتم الإبلاغ عنه سابقًا مباشرةً إلى نظام تتبع الأخطاء. [ 17 ] يقوم نظام تتبع الأخطاء في OSS-Fuzz بإبلاغ القائم بالصيانة تلقائيًا بالبرنامج المعرض للخطر، ويتحقق على فترات منتظمة مما إذا كان قد تم إصلاح الخطأ في أحدث مراجعة باستخدام المدخلات المُصغّرة التي تُسبب الفشل والتي تم تحميلها.

تقليل المدخلات تلقائيًا

يُعدّ تقليل حجم المدخلات تلقائيًا (أو تقليل حالات الاختبار) أسلوبًا آليًا لتصحيح الأخطاء، يهدف إلى عزل الجزء من المدخلات المُسببة للخطأ الذي يُؤدي إليه فعليًا. [ 57 ] [ 58 ] إذا كانت المدخلات المُسببة للخطأ كبيرة الحجم، ومعظمها غير صحيح، فقد يصعب على المطور فهم سبب الخطأ بدقة. وبناءً على هذه المدخلات، تقوم أداة التقليل الآلي بإزالة أكبر عدد ممكن من بايتات المدخلات مع الحفاظ على إمكانية إعادة إنتاج الخطأ الأصلي. على سبيل المثال، يُعدّ تصحيح الأخطاء التفاضلي أسلوبًا آليًا لتقليل حجم المدخلات، يستخدم خوارزمية بحث ثنائي مُوسّعة للعثور على هذا الحد الأدنى من المدخلات. [ 59 ]

فيما يلي قائمة بأدوات اختبار الثغرات الأمنية التي وُصفت بأنها "شائعة" أو "واسعة الاستخدام" أو ما شابه ذلك في الأدبيات الأكاديمية. [ 60 ] [ 61 ]

اسمصندوق أبيض/رمادي/أسودذكي/غبيوصفمكتوب فيرخصة
AFL [ 62 ] [ 63 ]رماديأحمقجأباتشي 2.0
AFL++ [ 64 ]رماديأحمقجأباتشي 2.0
AFLFast [ 65 ]رماديأحمقجأباتشي 2.0
أنغورا [ 66 ]رماديأحمقلغة سي++أباتشي 2.0
honggfuzz [ 67 ] [ 68 ]رماديأحمقجأباتشي 2.0
QSYM [ 69 ][ ؟ ][ ؟ ][ ؟ ][ ؟ ]
SymCC [ 70 ]أبيض [ 71 ][ ؟ ]لغة سي++رخصة جنو العمومية (GPL) ، رخصة جنو العمومية الصغرى (LGPL)
تي-فز [ 72 ][ ؟ ][ ؟ ][ ؟ ][ ؟ ]
VUzzer [ 73 ][ ؟ ][ ؟ ][ ؟ ][ ؟ ]
سيزكالررمادييذهبأباتشي 2.0
LibFuzzerأبيضأحمقلغة سي++أباتشي 2.0

انظر أيضاً

مراجع

  1. 1 2 جون نيستادت (فبراير 2008). "اختبار الاختراق الآلي باستخدام اختبار الصندوق الأبيض" . مايكروسوفت . تم الاسترجاع في 14 مايو 2009 .
  2. ↑ بارتون ب. ميلر (سبتمبر 1988). "قائمة مشاريع CS736 لخريف 1988" (ملف PDF) . قسم علوم الحاسوب، جامعة ويسكونسن-ماديسون . تاريخ الاسترجاع: 30 ديسمبر 2020 .
  3. ↑ بارتون ب. ميلر؛ لارس فريدريكسن؛ برايان سو (ديسمبر 1990). "دراسة تجريبية لموثوقية أدوات يونكس" . مجلة اتصالات رابطة مكائن ​​الحوسبة . 33 (11): 32-44 . doi : 10.1145/96267.96279 . S2CID 14313707 . 
  4. 1 2 ميلر، بارتون (أبريل 2008). "مقدمة لكتاب اختبار التشويش" . قسم علوم الحاسوب، جامعة ويسكونسن-ماديسون . تم الاطلاع عليه بتاريخ 29 مارس 2024 .
  5. ↑ "اختبارات التحقق من موثوقية التطبيقات" . جامعة ويسكونسن-ماديسون . تم الاطلاع عليه بتاريخ 30 ديسمبر 2020 .
  6. 1 2 "الإعلان عن ClusterFuzz" . تم الاسترجاع في 2017-03-09 .
  7. ↑ بيرلروث، نيكول (25 سبتمبر 2014). "خبراء الأمن يتوقعون أن تكون ثغرة "شل شوك" البرمجية في باش ذات أهمية بالغة" . صحيفة نيويورك تايمز . تاريخ الاسترجاع: 25 سبتمبر 2014 .
  8. ↑ زاليفسكي، ميخال (1 أكتوبر 2014). "ثغرة باش: ثغرتا تنفيذ التعليمات البرمجية عن بُعد الأخريان، أو كيف تغلّبنا على الإصلاح الأصلي (CVE-2014-6277 و'78)" . مدونة lcamtuf . تاريخ الاطلاع: 13 مارس 2017 .
  9. ↑ سيلتزر، لاري (29 سبتمبر 2014). "لعبة شيلشوك تجعل لعبة هارت بليد تبدو ضئيلة الأهمية" . زد نت . تم الاطلاع عليه بتاريخ 29 سبتمبر 2014 .
  10. ↑ بوك، هانو. "Fuzzing: Wie man Heartbleed hätte finden können (بالألمانية)" . Golem.de (باللغة الألمانية) . تم الاسترجاع في 13 مارس 2017 .
  11. ↑ بوك، هانو. "كيف كان من الممكن اكتشاف ثغرة نزيف القلب (باللغة الإنجليزية)" . مدونة هانو . تم الاطلاع عليه بتاريخ 13 مارس 2017 .
  12. ↑ "محرك بحث لإنترنت الأشياء - الأجهزة لا تزال عرضة لثغرة Heartbleed" . shodan.io . تم ​​الاطلاع عليه بتاريخ 13 مارس 2017 .
  13. ↑ "تقرير ثغرة نزيف القلب (يناير 2017)" . shodan.io . مؤرشف من الأصل بتاريخ 23 يناير 2017. تم الاطلاع عليه بتاريخ 10 يوليو 2017 .
  14. ↑ ووكر، مايكل. "تحدي داربا السيبراني الكبير" . darpa.mil . تم الاطلاع عليه بتاريخ 12 مارس 2017 .
  15. ↑ "الفوضى تحتل المرتبة الأولى في CGC" . تم الاطلاع عليه بتاريخ 12 مارس 2017 .
  16. 1 2 "الإعلان عن مشروع سبرينغفيلد" . 2016-09-26 . تم الاسترجاع في 2017-03-08 .
  17. 1 2 3 4 "الإعلان عن OSS-Fuzz" . تم الاطلاع عليه بتاريخ 2017-03-08 .
  18. ↑ كريستوفر دوماس (أغسطس 2018). "فتح وضع الإله - أبواب خلفية في معالجات x86" . تم الاسترجاع في 3 سبتمبر 2018 .
  19. ↑ "مايكروسوفت: تم تعزيز نظام ويندوز 10 بأدوات الأمان هذه بتقنية الفحص العشوائي - وهي الآن مفتوحة المصدر" . ZDNet . 15 سبتمبر 2020.
  20. ↑ "إطار عمل اختبار التشويش مفتوح المصدر من مايكروسوفت" . إنفوورلد . 17 سبتمبر 2020.
  21. ↑ مايكروسوفت/ون فز ، مايكروسوفت، 3 مارس 2024 ، تم الاطلاع عليه بتاريخ 6 مارس 2024
  22. ↑ جيرالد م. واينبرغ (2017-02-05). "اختبارات التشويش وتاريخها" . تم الاطلاع عليه بتاريخ 2017-02-06 .
  23. ↑ بيل، ر. تشارلز (1983-02-01). "تصحيح الأخطاء باستخدام مونت كارلو: دليل موجز" . مجلة اتصالات رابطة مكائن ​​الحوسبة . 26 (2): 126-127 . doi : 10.1145/358024.35805 . تاريخ الاسترجاع: 2026-05-18 .
  24. ↑ جو دبليو. دوران؛ سيميون سي. نتافوس (9 مارس 1981). تقرير عن الاختبار العشوائي . وقائع المؤتمر الدولي لهندسة البرمجيات (ICSE'81) التابع لجمعية ACM SIGSOFT. الصفحات 179-183 . ISBN  9780897911467.
  25. ↑ جو دبليو. دوران؛ سيميون سي. نتافوس (1984-07-01). "تقييم الاختبار العشوائي". معاملات IEEE في هندسة البرمجيات (4): 438-444 . doi : 10.1109/TSE.1984.5010257 . S2CID 17208399 . 
  26. ↑ آندي هيرتزفيلد (2004). ثورة في وادي السيليكون: القصة المذهلة لكيفية صنع جهاز ماك؟ دار نشر أورايلي. رقم ISBN 978-0596007195.
  27. ↑ "قصص ماكنتوش: حياة القرد" . Folklore.org. 22-02-1999 . تم الاطلاع عليه بتاريخ 28-05-2010 .
  28. ↑ "crashme" . CodePlex . تم الاسترجاع في 21-05-2021 .
  29. ↑ مايكل ساتون؛ آدم غرين؛ بيدرام أميني (2007). اختبار الثغرات الأمنية: اكتشاف الثغرات الأمنية باستخدام القوة الغاشمة . أديسون-ويسلي. ISBN 978-0-321-44611-4.
  30. ↑ أوفوت، جيف؛ شو، ووزي (2004). "توليد حالات اختبار لخدمات الويب باستخدام اضطراب البيانات" . ملاحظات هندسة البرمجيات ACM SIGSOFT . 29 (5): 1-10 . doi : 10.1145/1022494.1022529 . S2CID 52854851 . 
  31. ↑ ريبرت، ألكسندر؛ تشا، سانغ كيل؛ أفغيرينوس، ثاناسيس؛ فوت، جوناثان؛ وارين، ديفيد؛ غريكو، غوستافو؛ بروملي، ديفيد (2014). "تحسين اختيار البذور لاختبار البرمجيات العشوائي" (ملف PDF) . وقائع المؤتمر الثالث والعشرين لندوة USENIX حول الأمن : 861-875 .
  32. 1 2 3 باتريس غودفرويد؛ آدم كيزون؛ مايكل واي. ليفين. "اختبار التشويش القائم على القواعد النحوية" (ملف PDF) . أبحاث مايكروسوفت.
  33. 1 2 3 فان-ثوان فام؛ مارسيل بومه؛ أبهيك رويتشودري (2016-09-07). "اختبار الصندوق الأبيض القائم على النموذج لملفات البرامج الثنائية". وقائع المؤتمر الدولي الحادي والثلاثين لهندسة البرمجيات الآلية IEEE/ACM - ASE 2016. وقائع هندسة البرمجيات الآلية (ASE'16). الصفحات 543-553 . doi : 10.1145/2970276.2970316 . ISBN  9781450338455. S2CID 5809364 . 
  34. 1 2 3 "Peach Fuzzer" . تم الاسترجاع في 2017-03-08 .
  35. ↑ غريغ بانكس؛ ماركو كوفا؛ فيكتوريا فيلميتسغر؛ كيفن ألميروث ؛ ريتشارد كيميرر؛ جيوفاني فيغنا. SNOOZE: نحو أداة اختبار بروتوكولات الشبكات ذات الحالة . وقائع مؤتمر أمن المعلومات (ISC'06).
  36. ↑ أوزبرت باستاني؛ راهول شارما؛ أليكس أيكن؛ بيرسي ليانغ (يونيو 2017). توليف قواعد إدخال البرامج . وقائع مؤتمر ACM SIGPLAN حول تصميم وتنفيذ لغات البرمجة (PLDI 2017). arXiv : 1608.01723 . Bibcode : 2016arXiv160801723B .
  37. ↑ "مختبرات VDA - نظام اختبار البرمجيات التطوري" . مؤرشف من الأصل بتاريخ 2015-11-05 . تم الاطلاع عليه بتاريخ 2009-05-14 .
  38. 1 2 آري تاكانين؛ جاريد د. ديموت؛ تشارلز ميلر (31 يناير 2018). اختبار التشويش لاختبار أمان البرمجيات وضمان الجودة، الطبعة الثانية . دار أرتيك هاوس. ص 15. ISBN  978-1-63081-519-6.الوثيقة الكاملة متاحة ( مؤرشفة بتاريخ 19 سبتمبر 2018)
  39. 1 2 غانيش، فيجاي؛ ليك، تيم؛ رينارد، مارتن (2009). "اختبار الصندوق الأبيض الموجه القائم على التلوث" . المؤتمر الدولي الحادي والثلاثون لهندسة البرمجيات IEEE لعام 2009. الصفحات 474-484 . doi : 10.1109/ICSE.2009.5070546 . hdl : 1721.1/59320 . ISBN  978-1-4244-3453-4.
  40. ↑ وانغ، ت.؛ وي، ت.؛ غو، غ.؛ زو، و. (مايو 2010). "TaintScope: أداة اختبار عشوائي موجهة تراعي المجموع الاختباري للكشف التلقائي عن ثغرات البرمجيات". ندوة IEEE للأمن والخصوصية لعام 2010. الصفحات 497-512 . CiteSeerX 10.1.1.169.7866 . doi : 10.1109/SP.2010.37 . ISBN   978-1-4244-6894-2. S2CID 11898088 . 
  41. ↑ باتريس غودفرويد؛ مايكل واي. ليفين؛ ديفيد مولنار (2008-02-08). "اختبار التشويش الآلي ذو الصندوق الأبيض" (ملف PDF) . وقائع ندوة الشبكات والأنظمة الموزعة (NDSS'08).
  42. ↑ مارسيل بومه؛ سوميا بول (5 أكتوبر 2015). "تحليل احتمالي لكفاءة اختبار البرمجيات الآلي". معاملات IEEE في هندسة البرمجيات . 42 (4): 345-360 . doi : 10.1109/TSE.2015.2487274 . S2CID 15927031 . 
  43. ↑ نيك ستيفنز؛ جون غروسن؛ كريستوفر سالز؛ أندرو دوتشر؛ رويو وانغ؛ جاكوبو كوربيتا؛ يان شوشيتايشفيلي؛ كريستوفر كرويغل؛ جيوفاني فيغنا (24 فبراير 2016). دريلر: تعزيز. اختبار التشويش من خلال التنفيذ الرمزي الانتقائي (ملف PDF) . وقائع ندوة الشبكات والأنظمة الموزعة (NDSS'16).
  44. ↑ مارسيل بوم؛ فان-ثوان فام؛ أبهيك رويتشودري (28-10-2016). "اختبار التشويش الرمادي القائم على التغطية كسلسلة ماركوف". وقائع مؤتمر ACM SIGSAC لأمن الحاسوب والاتصالات لعام 2016. وقائع مؤتمر ACM لأمن الحاسوب والاتصالات (CCS'16). الصفحات 1032-1043 . doi : 10.1145/2976749.2978428 . ISBN  9781450341394. S2CID 3344888 . 
  45. ↑ هاملت، ريتشارد ج.؛ تايلور، روس (ديسمبر 1990). "اختبار التقسيم لا يُوحي بالثقة". معاملات IEEE في هندسة البرمجيات . 16 (12): 1402-1411 . doi : 10.1109/32.62448 .
  46. ↑ ويوكر، إيلين ج. (1 نوفمبر 1982). "حول اختبار البرامج غير القابلة للاختبار" . مجلة الكمبيوتر . 25 (4): 465-470 . doi : 10.1093/comjnl/25.4.465 .
  47. ↑ بار، إيرل ت.؛ هارمان، مارك؛ ماكمين، فيل؛ شهباز، مزمل؛ يو، شين (1 مايو 2015). "مشكلة أوراكل في اختبار البرمجيات: دراسة استقصائية" (ملف PDF) . مجلة IEEE للمعاملات في هندسة البرمجيات . 41 (5): 507-525 . Bibcode : 2015ITSEn..41..507B . doi : 10.1109/TSE.2014.2372785 . S2CID 7165993 . 
  48. ↑ "وثائق مُصرّف Clang" . clang.llvm.org . تم الاطلاع عليه بتاريخ 13 مارس 2017 .
  49. ↑ "خيارات مُعقِّم GNU GCC" . gcc.gnu.org . تم الاطلاع عليه بتاريخ 13 مارس 2017 .
  50. ↑ أورسو، أليساندرو؛ شي، تاو (2008). "BERT: اختبار الانحدار السلوكي". وقائع ورشة العمل الدولية لعام 2008 حول التحليل الديناميكي: عُقدت بالتزامن مع ندوة ACM SIGSOFT الدولية لاختبار البرمجيات وتحليلها (ISSTA 2008) . ACM. الصفحات 36-42 . doi : 10.1145/1401827.1401835 . ISBN  9781605580548. S2CID 7506576 . 
  51. ↑ ماكيمان، ويليام م. (1998). "الاختبار التفاضلي للبرمجيات" (ملف PDF) . المجلة التقنية الرقمية . 10 (1): 100-107 . مؤرشف من الأصل (ملف PDF) بتاريخ 31-10-2006.
  52. ↑ بابيتش، دوماغوي؛ مارتينيوني، لورينزو؛ ماكامانت، ستيفن؛ سونغ، داون (2011). "توليد الاختبارات الآلية الديناميكية الموجهة إحصائيًا". وقائع الندوة الدولية لعام 2011 حول اختبار البرمجيات وتحليلها . ACM. ص 12-22 . doi : 10.1145/2001420.2001423 . ISBN  9781450305624. S2CID 17344927 . 
  53. 1 2 سيسترهين، إريك؛ ويفر، بيريند-يان؛ أورو، ميشيل؛ فيرفييه، ماركوس (19 سبتمبر 2017). "ورقة بيضاء حول أمان المتصفح" (ملف PDF) . شركة X41D SEC GmbH.
  54. ↑ "تحسينات أمنية لمتصفح مايكروسوفت إيدج (مايكروسوفت إيدج للمحترفين في مجال تكنولوجيا المعلومات)" . مايكروسوفت . ١٥ أكتوبر ٢٠١٧. تم الاطلاع عليه بتاريخ ٣١ أغسطس ٢٠١٨ .
  55. ↑ "أدوات فرز حالات الطوارئ الحاسوبية" . قسم الطوارئ الحاسوبية التابع لمعهد هندسة البرمجيات (SEI) في جامعة كارنيجي ميلون (CMU) . تم الاطلاع عليه بتاريخ 14 مارس 2017 .
  56. ↑ "محلل الأعطال القابل للاستغلال من مايكروسوفت" . CodePlex . تم الاطلاع عليه بتاريخ 14 مارس 2017 .
  57. ↑ "تقليل حالات الاختبار" . 2011-07-18.
  58. ↑ "تقنيات تقليل حالات الاختبار من IBM" . 18 يوليو 2011. مؤرشف من الأصل في 10 يناير 2016. تم الاطلاع عليه في 18 يوليو 2011 .
  59. ↑ زيلر، أندرياس ؛ هيلدبراندت، رالف (فبراير 2002). "تبسيط وعزل المدخلات المسببة للفشل" . معاملات IEEE في هندسة البرمجيات . 28 (2): 183-200 . Bibcode : 2002ITSEn..28..183Z . CiteSeerX 10.1.1.180.3357 . doi : 10.1109/32.988498 . ISSN 0098-5589 . تاريخ الاسترجاع: 14 مارس 2017 .  
  60. ↑ حازمه، أحمد؛ هيريرا، أدريان؛ باير، ماتياس (15 يونيو 2021). "ماغما: معيار قياس اختبار التضبيب للتحقق من صحة البيانات" . وقائع مؤتمر ACM حول قياس وتحليل أنظمة الحوسبة . 4 (3): 49:1–49:29. arXiv : 2009.01120 . doi : 10.1145/3428334 . S2CID 227230949 . 
  61. ^ لي ، يووي. جي، شولينج؛ تشن، يوان. ليانغ، سيتشوانغ؛ لي، وي هان؛ تشن، يوياو. ليو، تشينيانغ؛ وو، تشونمينغ؛ بيه، رحيم؛ تشنغ، بنغ. لو، كانججي؛ وانغ، تينغ (2021). {UNIFUZZ}: منصة شاملة وعملية {تعتمد على المقاييس} لتقييم Fuzzers . ص 2777 – 2794. ISBN  978-1-939133-24-3.
  62. ↑ Hazimeh, Herrera & Payer 2021 ، ص. 1: "نقوم بتقييم سبعة أدوات اختبار تعتمد على الطفرات شائعة الاستخدام (AFL، ...)".
  63. ↑ Li et al. 2021 ، ص. 1: "باستخدام UniFuzz ، نجري تقييمات متعمقة للعديد من أدوات اختبار التشويش البارزة بما في ذلك AFL ، ...".
  64. ↑ Hazimeh, Herrera & Payer 2021 ، ص. 1: "نقوم بتقييم سبعة أدوات اختبار تعتمد على الطفرات شائعة الاستخدام (..., AFL++, ...)".
  65. ↑ Li et al. 2021 ، ص. 1: "باستخدام UniFuzz ، نجري تقييمات متعمقة للعديد من أدوات الاختبار البارزة بما في ذلك AFL و AFLFast ...".
  66. ↑ Li et al. 2021 ، ص. 1: "باستخدام UniFuzz ، نجري تقييمات متعمقة للعديد من أدوات اختبار التشويش البارزة بما في ذلك AFL ، ... ، Angora ، ...".
  67. ↑ Hazimeh, Herrera & Payer 2021 ، ص. 1: "نقوم بتقييم سبعة أدوات اختبار تعتمد على الطفرات شائعة الاستخدام (..., honggfuzz, ...)".
  68. ↑ Li et al. 2021 ، ص. 1: "باستخدام UniFuzz ، نجري تقييمات متعمقة للعديد من أدوات اختبار التشويش البارزة بما في ذلك AFL ، ... ، Honggfuzz ، ...".
  69. ↑ Li et al. 2021 ، ص. 1: "باستخدام UniFuzz ، نجري تقييمات متعمقة للعديد من أدوات الاختبار البارزة بما في ذلك AFL ، ... ، QSYM ، ...".
  70. ↑ Hazimeh, Herrera & Payer 2021 ، ص. 1: "نقوم بتقييم سبعة أدوات اختبار تعتمد على الطفرات شائعة الاستخدام (...، و SymCC-AFL)".
  71. ↑ حازمه، هيريرا وباير 2021 ، ص 14.
  72. ↑ Li et al. 2021 ، ص. 1: "باستخدام UniFuzz ، نجري تقييمات متعمقة للعديد من أدوات الاختبار البارزة بما في ذلك AFL ، ... ، T-Fuzz ، ...".
  73. ↑ Li et al. 2021 ، ص. 1: "باستخدام UniFuzz ، نجري تقييمات متعمقة للعديد من أدوات الاختبار البارزة بما في ذلك AFL و ... و VUzzer64.".

للمزيد من القراءة

  • نابا، أ.؛ بلازكيز، إ. (2023). اختبار الثغرات الأمنية ضد الآلة: أتمتة أبحاث الثغرات الأمنية باستخدام أجهزة إنترنت الأشياء المحاكاة على Qemu . دار نشر Packt المحدودة. ISBN 9781804614976.دليل شامل حول البحث الآلي عن الثغرات الأمنية باستخدام أجهزة إنترنت الأشياء المحاكاة.
  • زيلر، أندرياس. جوبيناث، راهول. بوهمي، مارسيل؛ فريزر، جوردون. هولر ، كريستيان (2019). الكتاب المزعج . ساربروكن: CISPA + جامعة سارلاند.كتاب تمهيدي مجاني عبر الإنترنت حول اختبار البرمجيات العشوائي (fuzzing).
  • آري تاكانين، جاريد د. ديموت، تشارلز ميلر، اختبار البرمجيات الأمنية وضمان الجودة باستخدام تقنية Fuzzing ، 2008، رقم ISBN 978-1-59693-214-2
  • مايكل ساتون، وآدم غرين، وبيدرام أميني. اختبار الثغرات الأمنية: اكتشاف الثغرات الأمنية باستخدام القوة الغاشمة ، 2007، رقم ISBN 0-321-44611-9.
  • هـ. بول، تحديد الثغرات الأمنية غير المعروفة (Zero-Day Vulperiments) بطريقة فعالة من حيث التكلفة باستخدام نمذجة التهديدات والاختبار العشوائي (Fuzzing) ، 2011
  • فابيان دوشين، الكشف عن ثغرات الويب عبر اختبار التشويش التطوري بمساعدة استدلال النموذج، 2014، أطروحة دكتوراه
  • براتوس، سيرجي؛ دارلي، تري؛ لوكاستو، مايكل؛ باترسون، ميريديث ل.؛ شابيرو، ريبيكا ب.س.؛ شوبينا، آنا؛ "ب.س." شابيرو، ريبيكا؛ شوبينا، آنا (2014). "ما وراء الأخطاء المزروعة في "الثقة بالثقة": حدود معالجة المدخلات". مجلة IEEE للأمن والخصوصية . 12 (1): 83-87 . Bibcode : 2014ISPri..12a..83M . doi : 10.1109/MSP.2014.1 .—يسلط الضوء بشكل أساسي على سبب نجاح عملية اختبار البرمجيات العشوائية: لأن المدخلات هي البرنامج المتحكم في المفسر.