ในการเขียนโปรแกรมและการพัฒนาซอฟต์แวร์ การทดสอบ แบบฟัซซิ่ง (FuzzingหรือFuzz Testing)เป็น เทคนิค การทดสอบซอฟต์แวร์ อัตโนมัติที่เกี่ยวข้องกับการป้อน ข้อมูลที่ไม่ถูกต้อง ไม่คาดคิด หรือสุ่มเข้าไปในโปรแกรมคอมพิวเตอร์จากนั้นโปรแกรมจะถูกตรวจสอบหาข้อผิดพลาด เช่นการหยุดทำงานการตรวจ สอบ โค้ดภายในล้มเหลวหรือการรั่วไหลของหน่วยความจำ ที่อาจเกิดขึ้น โดยทั่วไปแล้ว เครื่องมือฟัซซิ่งจะใช้ในการทดสอบโปรแกรมที่รับข้อมูลที่มีโครงสร้าง โครงสร้างนี้จะถูกระบุไว้ เช่น ในรูปแบบไฟล์หรือโปรโตคอลและแยกแยะข้อมูลที่ถูกต้องออกจากข้อมูลที่ไม่ถูกต้อง เครื่องมือฟัซซิ่งที่มีประสิทธิภาพจะสร้างข้อมูลกึ่งถูกต้อง ซึ่ง "ถูกต้องเพียงพอ" ในแง่ที่ว่าข้อมูลเหล่านั้นจะไม่ถูกปฏิเสธโดยตรงโดยตัวแยกวิเคราะห์ แต่จะสร้างพฤติกรรมที่ไม่คาดคิดในส่วนลึกของโปรแกรม และ "ไม่ถูกต้องเพียงพอ" ที่จะเปิดเผยกรณีพิเศษที่ยังไม่ได้จัดการอย่างเหมาะสม

เพื่อวัตถุประสงค์ด้านความปลอดภัย อินพุตที่ข้ามขอบเขตความไว้วางใจมักจะมีประโยชน์มากที่สุด^{[ 1 ]}ตัวอย่างเช่น การทดสอบความปลอดภัยด้วยฟัซซ์โค้ดที่จัดการไฟล์ที่อัปโหลดโดยผู้ใช้ทั่วไปมีความสำคัญมากกว่าการทดสอบความปลอดภัยด้วยฟัซซ์โค้ดที่วิเคราะห์ไฟล์การกำหนดค่าซึ่งเข้าถึงได้เฉพาะผู้ใช้ที่มีสิทธิ์เท่านั้น

คำว่า "fuzz" มาจากโครงการในชั้นเรียนปี 1988 ^{[ 2 ]}ในชั้นเรียนระบบปฏิบัติการขั้นสูงระดับบัณฑิตศึกษา (CS736) ซึ่งสอนโดยศาสตราจารย์ Barton Miller ที่มหาวิทยาลัยวิสคอนซินซึ่งผลลัพธ์ได้รับการตีพิมพ์ในภายหลังในปี 1990 ^{[ 3 ] [ 4 ]}เพื่อทดสอบ fuzz กับ ยูทิลิตี้ UNIXที่ออกแบบมาเพื่อสร้างอินพุตแบบสุ่มและพารามิเตอร์บรรทัดคำสั่งสำหรับยูทิลิตี้โดยอัตโนมัติ โครงการนี้ออกแบบมาเพื่อทดสอบความน่าเชื่อถือของโปรแกรมบรรทัดคำสั่ง UNIX โดยการเรียกใช้อินพุตแบบสุ่มจำนวนมากอย่างรวดเร็วต่อเนื่องกันจนกว่าโปรแกรมจะล่ม ทีมของ Miller สามารถทำให้ยูทิลิตี้ที่ทดสอบล่มได้ 25 ถึง 33 เปอร์เซ็นต์ จากนั้นพวกเขาก็ทำการดีบักการล่มแต่ละครั้งเพื่อหาสาเหตุและจัดประเภทความล้มเหลวที่ตรวจพบแต่ละรายการ เพื่อให้นักวิจัยคนอื่นๆ สามารถทำการทดลองที่คล้ายกันกับซอฟต์แวร์อื่นๆ ได้ จึงได้เปิดเผยซอร์สโค้ดของเครื่องมือ ขั้นตอนการทดสอบ และข้อมูลผลลัพธ์ดิบต่อสาธารณะ^{[ 5 ]}การทดสอบแบบฟัซซิ่งในช่วงแรกนี้จะถูกเรียกว่าการทดสอบแบบฟัซซิ่งแบบกล่องดำ แบบรุ่นต่อรุ่น แบบไม่มีโครงสร้าง (แบบโง่หรือ "คลาสสิก")

ตามที่ศาสตราจารย์ Barton Miller กล่าวไว้ว่า "ในระหว่างกระบวนการเขียนคำอธิบายโครงการ ฉันจำเป็นต้องตั้งชื่อให้กับการทดสอบประเภทนี้ ฉันต้องการชื่อที่สื่อถึงความรู้สึกของข้อมูลแบบสุ่มและไม่มีโครงสร้าง หลังจากลองคิดหลายๆ แบบแล้ว ฉันก็เลือกใช้คำว่า fuzz" ^{[ 4 ]}

หนึ่งในผลงานสำคัญในช่วงแรกคือออราเคิลที่เรียบง่าย (แทบจะเรียบง่ายจนเกินไป) โปรแกรมจะถือว่าสอบไม่ผ่านหากเกิดข้อผิดพลาดหรือค้างภายใต้ข้อมูลป้อนเข้าแบบสุ่ม และจะถือว่าผ่านการทดสอบหากเป็นอย่างอื่น แม้ว่าการสร้างออราเคิลสำหรับการทดสอบอาจเป็นเรื่องท้าทาย แต่ออราเคิลสำหรับการทดสอบแบบฟัซซ์ในช่วงแรกนั้นเรียบง่ายและสามารถนำไปใช้ได้กับทุกสถานการณ์

ในเดือนเมษายน พ.ศ. 2555 Google ได้ประกาศ ClusterFuzz ซึ่งเป็นโครงสร้างพื้นฐานการทดสอบความปลอดภัยแบบฟัซซิ่งบนคลาวด์สำหรับส่วนประกอบที่สำคัญของ เว็บเบราว์ เซอร์Chromium ^{[ 6 ]}นักวิจัยด้านความปลอดภัยสามารถอัปโหลดฟัซเซอร์ของตนเองและรับรางวัลบั๊กได้หาก ClusterFuzz พบข้อผิดพลาดด้วยฟัซเซอร์ที่อัปโหลด

ในเดือนกันยายน พ.ศ. 2557 Shellshock ^{[ 7 ]}ถูกเปิดเผยว่าเป็นกลุ่มของช่องโหว่ด้านความปลอดภัยในเชลล์Bash ^ของ UNIX ที่ใช้กันอย่างแพร่หลาย ช่องโหว่ส่วนใหญ่ของ Shellshock ถูกค้นพบโดยใช้ฟัซเซอร์AFL [ ^{8 ]} (บริการที่เข้าถึงอินเทอร์เน็ตจำนวนมาก เช่น การใช้งานเว็บเซิร์ฟเวอร์บางส่วน ใช้ Bash ในการประมวลผลคำขอต่างๆ ทำให้ผู้โจมตีสามารถทำให้ Bash เวอร์ชันที่มีช่องโหว่สามารถเรียกใช้คำสั่งตามอำเภอใจได้ซึ่งอาจทำให้ผู้โจมตีสามารถเข้าถึงระบบคอมพิวเตอร์โดยไม่ได้รับอนุญาต^{[ 9 ]} )

ในเดือนเมษายน 2558 Hanno Böck ได้แสดงให้เห็นว่าฟัซเซอร์ AFL สามารถค้นพบช่องโหว่ Heartbleed ในปี 2557 ได้อย่างไร^{[ 10 ] [ 11 ]} ( ช่องโหว่ Heartbleedถูกเปิดเผยในเดือนเมษายน 2557 เป็นช่องโหว่ร้ายแรงที่ทำให้ฝ่ายตรงข้ามสามารถถอดรหัสการสื่อสารที่เข้ารหัสได้ ช่องโหว่นี้ถูกนำเข้ามาในOpenSSL โดยไม่ได้ตั้งใจ ซึ่งใช้TLSและถูกใช้โดยเซิร์ฟเวอร์ส่วนใหญ่บนอินเทอร์เน็ตShodanรายงานว่ายังมีเครื่องที่เสี่ยงต่อช่องโหว่นี้อยู่ 238,000 เครื่องในเดือนเมษายน 2559 ^{[ 12 ]}และ 200,000 เครื่องในเดือนมกราคม 2560 ^{[ 13 ]} )

ในเดือนสิงหาคม พ.ศ. 2559 หน่วยงานวิจัยโครงการขั้นสูงด้านการป้องกันประเทศ (DARPA) ได้จัดการแข่งขันรอบชิงชนะเลิศของCyber ​​Grand Challenge ครั้งแรก ซึ่งเป็นการแข่งขัน จับธงแบบอัตโนมัติเต็มรูปแบบที่กินเวลานาน 11 ชั่วโมง^{[ 14 ]}วัตถุประสงค์คือการพัฒนาระบบป้องกันอัตโนมัติที่สามารถค้นหาใช้ประโยชน์และแก้ไขข้อบกพร่องของซอฟต์แวร์แบบเรียลไทม์การทดสอบแบบฟัซซิ่งถูกใช้เป็นกลยุทธ์การโจมตีที่มีประสิทธิภาพในการค้นหาข้อบกพร่องในซอฟต์แวร์ของฝ่ายตรงข้าม ซึ่งแสดงให้เห็นถึงศักยภาพอันมหาศาลในการตรวจจับช่องโหว่แบบอัตโนมัติ ผู้ชนะคือระบบที่เรียกว่า "Mayhem" ^{[ 15 ]}ซึ่งพัฒนาโดยทีม ForAllSecure นำโดยDavid Brumley

ในเดือนกันยายน พ.ศ. 2559 ไมโครซอฟต์ได้ประกาศโครงการสปริงฟิลด์ ซึ่งเป็นบริการทดสอบแบบฟัซซ์บนคลาวด์สำหรับการค้นหาข้อบกพร่องด้านความปลอดภัยที่สำคัญในซอฟต์แวร์^{[ 16 ]}

ในเดือนธันวาคม 2016 Google ประกาศ OSS-Fuzz ซึ่งอนุญาตให้ทำการทดสอบความปลอดภัยอย่างต่อเนื่องกับโครงการโอเพนซอร์สที่สำคัญหลายโครงการ^{[ 17 ]}

ในงาน Black Hat 2018 คริสโตเฟอร์ โดมาส ได้สาธิตการใช้ฟัซซิ่งเพื่อเปิดเผยการมีอยู่ของ คอร์ RISC ที่ซ่อนอยู่ ภายในโปรเซสเซอร์^{[ 18 ]} คอร์นี้สามารถข้ามการตรวจสอบความปลอดภัยที่มีอยู่เพื่อดำเนินการ คำสั่ง Ring 0จาก Ring 3 ได้

ในเดือนกันยายน พ.ศ. 2563 ไมโครซอฟต์ได้เปิดตัวOneFuzzซึ่งเป็น แพลตฟอร์มการทดสอบแบบฟัซซิ่ง แบบโฮสต์เองที่ช่วยตรวจจับข้อบกพร่องของซอฟต์แวร์โดย อัตโนมัติ ^{[ 19 ]}รองรับทั้งWindowsและ Linux ^{[ 20 ]}และถูกเก็บถาวรในอีกสามปีต่อมาในวันที่ 1 พฤศจิกายน พ.ศ. 2566 ^{[ 21 ]}

การทดสอบโปรแกรมด้วยอินพุตแบบสุ่มมีมาตั้งแต่ทศวรรษ 1950 เมื่อข้อมูลยังคงถูกจัดเก็บไว้บนบัตรเจาะรู [ ^{​​22 ] โปรแกรมเมอร์}จะใช้บัตรเจาะรูที่ดึงมาจากถังขยะหรือสำรับการ์ดตัวเลขสุ่มเป็นอินพุตให้กับโปรแกรมคอมพิวเตอร์ หากการดำเนินการเผยให้เห็นพฤติกรรมที่ไม่พึงประสงค์ แสดงว่าตรวจพบ ข้อบกพร่อง

การดำเนินการอินพุตแบบสุ่มยังเรียกว่าการทดสอบแบบสุ่มการทดสอบลิงหรือการดีบักแบบมอนเตคาร์โล^{[ 23 ]} (โดยเปรียบเทียบกับวิธีการมอนเตคาร์โล )

ในปี พ.ศ. 2524 Duran และ Ntafos ได้ทำการตรวจสอบประสิทธิภาพของการทดสอบโปรแกรมด้วยอินพุตแบบสุ่มอย่างเป็นทางการ^{[ 24 ] [ 25 ]}แม้ว่าการทดสอบแบบสุ่มจะถูกมองว่าเป็นวิธีการทดสอบโปรแกรมที่แย่ที่สุด แต่ผู้เขียนสามารถแสดงให้เห็นว่ามันเป็นทางเลือกที่คุ้มค่ากว่าเทคนิคการทดสอบที่เป็นระบบมากกว่า

ในปี พ.ศ. 2526 Steve Cappsที่ Apple ได้พัฒนา "The Monkey" ^{[ 26 ] ซึ่ง}เป็นเครื่องมือที่จะสร้างอินพุตแบบสุ่มสำหรับ แอปพลิเคชัน Mac OS แบบคลาสสิกเช่นMacPaint ^[ 27 ^] "ลิง" ในเชิงเปรียบเทียบหมายถึงทฤษฎีลิงอนันต์ซึ่งระบุว่าลิงที่กดแป้นพิมพ์แบบสุ่มบนแป้นพิมพ์เครื่องพิมพ์ดีดเป็นเวลานานอนันต์ ในที่สุดก็จะพิมพ์ผลงานทั้งหมดของเชกสเปียร์ออกมาได้ ในกรณีของการทดสอบ ลิงจะเขียนลำดับอินพุตเฉพาะที่จะทำให้เกิดการขัดข้อง

ในปี พ.ศ. 2534 ได้มีการปล่อยเครื่องมือ crashme ออกมา ซึ่งมีจุดประสงค์เพื่อทดสอบความทนทานของระบบปฏิบัติการ Unix และระบบปฏิบัติการที่คล้าย Unix โดยการเรียกใช้ระบบแบบสุ่มด้วยพารามิเตอร์ที่เลือกแบบสุ่ม^{[ 28 ]}

ฟัซเซอร์สามารถจำแนกประเภทได้หลายวิธี: ^{[ 29 ] [ 1 ]}

1. เครื่องมือสร้างช่องโหว่ (fuzzer) สามารถทำงานได้โดยการสร้างข้อมูลใหม่ทั้งหมดหรือโดยการแก้ไขข้อมูลที่มีอยู่แล้ว ขึ้นอยู่กับว่าข้อมูลนำเข้าถูกสร้างขึ้นใหม่ทั้งหมดหรือโดยการแก้ไขข้อมูลนำเข้าที่มีอยู่
2. เครื่องมือทดสอบการเบลอภาพ (fuzzer) อาจเป็นแบบโง่ (สำหรับข้อมูลที่ไม่เป็นระเบียบ) หรือแบบฉลาด (สำหรับข้อมูลที่มีโครงสร้าง) ขึ้นอยู่กับว่ามันรับรู้ถึงโครงสร้างของข้อมูลนำเข้าหรือไม่
3. เครื่องมือทดสอบการตรวจจับช่องโหว่ (fuzzer) สามารถเป็นแบบกล่องขาว กล่องเทา หรือกล่องดำ ขึ้นอยู่กับว่ามันรับรู้โครงสร้างของโปรแกรมหรือไม่

ฟัซเซอร์แบบใช้การกลายพันธุ์ จะใช้ประโยชน์จากชุดข้อมูลอินพุตเริ่มต้นที่มีอยู่ระหว่างการฟัซซิ่ง โดยจะสร้างอินพุตโดยการแก้ไข (หรือกลายพันธุ์ ) อินพุตเริ่มต้นที่ให้มา^{[ 30 ]}ตัวอย่างเช่น เมื่อทำการฟัซซิ่งไลบรารีรูปภาพlibpng ผู้ใช้จะให้ชุดไฟล์รูปภาพ PNG ที่ถูกต้อง เป็นอินพุตเริ่มต้น ในขณะที่ฟัซเซอร์แบบใช้การกลายพันธุ์จะแก้ไขอินพุตเริ่มต้นเหล่านี้เพื่อสร้างตัวแปรกึ่งถูกต้องของแต่ละอินพุตเริ่มต้น ชุดไฟล์อินพุตเริ่มต้นอาจมีอินพุตที่คล้ายกันหลายพันรายการ การเลือกอินพุตเริ่มต้นอัตโนมัติ (หรือการลดชุดทดสอบ) ช่วยให้ผู้ใช้สามารถเลือกอินพุตเริ่มต้นที่ดีที่สุดเพื่อเพิ่มจำนวนข้อบกพร่องทั้งหมดที่พบในระหว่างแคมเปญฟัซซิ่งให้สูงสุด^{[ 31 ]}

ฟัซเซอร์แบบสร้างรุ่นจะสร้างอินพุตตั้งแต่เริ่มต้น ตัวอย่างเช่น ฟัซเซอร์แบบสร้างรุ่นอัจฉริยะ^{[ 32 ]}จะใช้โมเดลอินพุตที่ผู้ใช้ให้มาเพื่อสร้างอินพุตใหม่ ฟัซเซอร์แบบสร้างรุ่นไม่เหมือนกับฟัซเซอร์แบบการกลายพันธุ์ตรงที่ไม่ขึ้นอยู่กับการมีอยู่หรือคุณภาพของชุดข้อมูลอินพุตเริ่มต้น

ฟัซเซอร์บางตัวมีความสามารถที่จะทำได้ทั้งสองอย่าง คือสร้างอินพุตตั้งแต่เริ่มต้นและสร้างอินพุตโดยการกลายพันธุ์ของเมล็ดพันธุ์ที่มีอยู่^{[ 33 ]}

โดยทั่วไปแล้ว ฟัซเซอร์จะใช้ในการสร้างอินพุตสำหรับโปรแกรมที่รับอินพุตที่มีโครงสร้าง เช่นไฟล์ลำดับเหตุการณ์จากแป้นพิมพ์หรือเมาส์หรือลำดับข้อความโครงสร้างนี้จะแยกแยะอินพุตที่ถูกต้องซึ่งโปรแกรมยอมรับและประมวลผลออกจากอินพุตที่ไม่ถูกต้องซึ่งโปรแกรมจะปฏิเสธอย่างรวดเร็ว สิ่งที่ถือว่าเป็นอินพุตที่ถูกต้องอาจถูกระบุไว้อย่างชัดเจนในแบบจำลองอินพุต ตัวอย่างของแบบจำลองอินพุต ได้แก่ไวยากรณ์เชิงรูปธรรมรูปแบบไฟล์แบบ จำลอง GUIและโปรโตคอลเครือข่ายแม้แต่สิ่งที่ไม่ปกติถือว่าเป็นอินพุตก็สามารถใช้ฟัซเซอร์ได้ เช่น เนื้อหาของฐานข้อมูลหน่วยความจำที่ใช้ร่วมกันตัวแปรสภาพแวดล้อมหรือการสลับเธรด อย่างแม่นยำ ฟัซเซอร์ที่มีประสิทธิภาพจะสร้างอินพุตที่กึ่งถูกต้อง ซึ่ง "ถูกต้องเพียงพอ" ที่จะไม่ถูกปฏิเสธโดยตรงจากตัวแยกวิเคราะห์และ "ไม่ถูกต้องเพียงพอ" ที่จะทำให้เกิดกรณีพิเศษและทดสอบพฤติกรรมของโปรแกรมที่น่าสนใจ

ฟัซเซอร์อัจฉริยะ (แบบจำลอง^{[ 33 ]}ไวยากรณ์^{[ 32 ] [ 34 ]}หรือโปรโตคอล^{[ 35 ]} ) ใช้ประโยชน์จากแบบจำลองอินพุตเพื่อสร้างอินพุตที่ถูกต้องในสัดส่วนที่มากขึ้น ตัวอย่างเช่น หากอินพุตสามารถจำลองเป็นต้นไม้ไวยากรณ์นามธรรมได้ ฟัซเซอร์อัจฉริยะแบบใช้การกลายพันธุ์^{[ 34 ]}จะใช้การแปลง แบบสุ่ม เพื่อย้ายต้นไม้ย่อยที่สมบูรณ์จากโหนดหนึ่งไปยังอีกโหนดหนึ่ง หากอินพุตสามารถจำลองได้ด้วยไวยากรณ์ที่เป็นทางการฟัซเซอร์อัจฉริยะแบบใช้การสร้าง^{[ 32 ]}จะสร้างอินสแตนซ์ของกฎการผลิตเพื่อสร้างอินพุตที่ถูกต้องตามไวยากรณ์ อย่างไรก็ตาม โดยทั่วไปแล้วแบบจำลองอินพุตจะต้องระบุไว้อย่างชัดเจน ซึ่งทำได้ยากเมื่อแบบจำลองเป็นกรรมสิทธิ์ ไม่ทราบ หรือซับซ้อนมาก หากมีคลังข้อมูลขนาดใหญ่ของอินพุตที่ถูกต้องและไม่ถูกต้อง เทคนิค การเหนี่ยวนำไวยากรณ์เช่น อัลกอริทึม L* ของ Angluinจะสามารถสร้างแบบจำลองอินพุตได้^{[ 36 ] [ 37 ]}

ฟัซเซอร์แบบโง่^{[ 38 ] [ 39 ]}ไม่จำเป็นต้องใช้โมเดลอินพุต ดังนั้นจึงสามารถใช้ฟัซเซอร์กับโปรแกรมที่หลากหลายมากขึ้นได้ ตัวอย่างเช่นAFLเป็นฟัซเซอร์แบบโง่ที่ใช้การกลายพันธุ์ ซึ่งแก้ไขไฟล์ซีดโดยการสลับบิตแบบสุ่มโดยการแทนที่ไบต์แบบสุ่มด้วยค่าที่ "น่าสนใจ" และโดยการย้ายหรือลบบล็อกข้อมูล อย่างไรก็ตาม ฟัซเซอร์แบบโง่อาจสร้างอินพุตที่ถูกต้องในสัดส่วนที่ต่ำกว่า และทำให้ โค้ด ตัวแยกวิเคราะห์ ทำงานหนัก กว่าส่วนประกอบหลักของโปรแกรม ข้อเสียของฟัซเซอร์แบบโง่สามารถแสดงให้เห็นได้โดยการสร้างเช็คซัม ที่ถูกต้อง สำหรับ การ ตรวจสอบความซ้ำซ้อนแบบวนรอบ (CRC) CRC เป็นโค้ดตรวจจับข้อผิดพลาดที่รับประกันว่าความสมบูรณ์ของข้อมูลที่อยู่ในไฟล์อินพุตจะได้รับการรักษาไว้ในระหว่างการส่งเช็คซัมจะถูกคำนวณจากข้อมูลอินพุตและบันทึกไว้ในไฟล์ เมื่อโปรแกรมประมวลผลไฟล์ที่ได้รับ และเช็คซัมที่บันทึกไว้ไม่ตรงกับเช็คซัมที่คำนวณใหม่ ไฟล์นั้นจะถูกปฏิเสธว่าไม่ถูกต้อง ตอนนี้ ฟัซเซอร์ที่ไม่รู้จัก CRC ไม่น่าจะสร้างเช็คซัมที่ถูกต้องได้ อย่างไรก็ตาม มีความพยายามที่จะระบุและคำนวณเช็คซัมที่เป็นไปได้อีกครั้งในอินพุตที่กลายพันธุ์ เมื่อฟัซเซอร์แบบใช้การกลายพันธุ์แบบง่ายๆ ได้แก้ไขข้อมูลที่ได้รับการป้องกันแล้ว^{[ 40 ]}

โดยทั่วไปแล้ว ฟัซเซอร์จะมีประสิทธิภาพมากขึ้นหากสามารถครอบคลุมโค้ดได้ ในระดับสูงกว่า เหตุผลก็คือ หากฟัซเซอร์ไม่ทดสอบส่วนประกอบโครงสร้างบางอย่างในโปรแกรม ก็จะไม่สามารถเปิดเผยข้อบกพร่องที่ซ่อนอยู่ในส่วนประกอบเหล่านั้นได้เช่นกัน ส่วนประกอบบางอย่างของโปรแกรมถือว่ามีความสำคัญมากกว่าส่วนอื่นๆ ตัวอย่างเช่น ตัวดำเนินการหารอาจทำให้เกิด ข้อผิดพลาด การหารด้วยศูนย์หรือการเรียกใช้ระบบอาจทำให้โปรแกรมล่มได้

ฟัซเซอร์แบบกล่องดำ^{[ 38 ] [ 34 ]}ถือว่าโปรแกรมเป็นกล่องดำและไม่รับรู้โครงสร้างภายในของโปรแกรม ตัวอย่างเช่น เครื่องมือ ทดสอบแบบสุ่มที่สร้างอินพุตแบบสุ่มถือเป็นฟัซเซอร์แบบกล่องดำ ดังนั้น ฟัซเซอร์แบบกล่องดำสามารถประมวลผลอินพุตได้หลายร้อยรายการต่อวินาที สามารถขนานการทำงานได้ง่าย และสามารถปรับขนาดให้เข้ากับโปรแกรมที่มีขนาดตามอำเภอใจได้ อย่างไรก็ตาม ฟัซเซอร์แบบกล่องดำอาจแค่แตะต้องพื้นผิวและเปิดเผยข้อบกพร่องที่ "ตื้น" เท่านั้น ดังนั้นจึงมีความพยายามที่จะพัฒนาฟัซเซอร์แบบกล่องดำที่สามารถเรียนรู้เกี่ยวกับโครงสร้างภายใน (และพฤติกรรม) ของโปรแกรมในระหว่างการฟัซซิ่งได้ทีละน้อยโดยการสังเกตเอาต์พุตของโปรแกรมเมื่อได้รับอินพุต ตัวอย่างเช่น LearnLib ใช้การเรียนรู้แบบแอคทีฟเพื่อสร้างออโตมาตอนที่แสดงถึงพฤติกรรมของเว็บแอปพลิ เคชัน

ฟัซเซอร์แบบไวท์บ็อกซ์^{[ 39 ] [ 33 ]}ใช้ประโยชน์จากการวิเคราะห์โปรแกรมเพื่อเพิ่มความครอบคลุมของโค้ด อย่างเป็นระบบ หรือเพื่อเข้าถึงตำแหน่งโปรแกรมที่สำคัญบางตำแหน่ง ตัวอย่างเช่น SAGE ^{[ 41 ]}ใช้ประโยชน์จากการดำเนินการเชิงสัญลักษณ์เพื่อสำรวจเส้นทางต่างๆ ในโปรแกรมอย่างเป็นระบบ (เทคนิคที่เรียกว่าการดำเนินการแบบ concolic ) หากมีข้อกำหนดของโปรแกรม ฟัซเซอร์แบบไวท์บ็อกซ์อาจใช้ประโยชน์จากเทคนิคจาก การทดสอบตามแบบจำลองเพื่อสร้างอินพุตและตรวจสอบเอาต์พุตของโปรแกรมเทียบกับข้อกำหนดของโปรแกรม ฟัซเซอร์แบบไวท์บ็อกซ์สามารถมีประสิทธิภาพมากในการเปิดเผยข้อบกพร่องที่ซ่อนอยู่ลึกในโปรแกรม อย่างไรก็ตาม เวลาที่ใช้ในการวิเคราะห์ (ของโปรแกรมหรือข้อกำหนด) อาจกลายเป็นอุปสรรค หากฟัซเซอร์แบบไวท์บ็อกซ์ใช้เวลานานเกินไปในการสร้างอินพุต ฟัซเซอร์แบบแบล็กบ็อกซ์จะมีประสิทธิภาพมากกว่า^{[ 42 ]}ดังนั้นจึงมีความพยายามที่จะรวมประสิทธิภาพของฟัซเซอร์แบบแบล็กบ็อกซ์และประสิทธิผลของฟัซเซอร์แบบไวท์บ็อกซ์ เข้าด้วยกัน ^{[ 43 ]}

ฟั ซเซอร์ แบบกล่องสีเทาใช้ประโยชน์จากการตรวจสอบแทนการวิเคราะห์โปรแกรมเพื่อรวบรวมข้อมูลเกี่ยวกับโปรแกรม ตัวอย่างเช่น AFL และ libFuzzer ใช้การตรวจสอบแบบเบาเพื่อติดตาม การเปลี่ยน ผ่านบล็อกพื้นฐานที่ดำเนินการโดยอินพุต ซึ่งนำไปสู่ภาระด้านประสิทธิภาพที่สมเหตุสมผล แต่จะแจ้งให้ฟัซเซอร์ทราบเกี่ยวกับการเพิ่มขึ้นของความครอบคลุมของโค้ดในระหว่างการฟัซซิ่ง ซึ่งทำให้ฟัซเซอร์แบบกล่องสีเทาเป็นเครื่องมือตรวจจับช่องโหว่ที่มีประสิทธิภาพอย่างยิ่ง^{[ 44 ]}

การทดสอบแบบฟัซซิ่งส่วนใหญ่ใช้เป็นเทคนิคอัตโนมัติเพื่อเปิดเผยช่องโหว่ในโปรแกรมที่สำคัญต่อความปลอดภัยซึ่งอาจถูกใช้ประโยชน์ด้วยเจตนาร้าย^{[ 6 ] [ 16 ] [ 17 ]}โดยทั่วไปแล้ว การทดสอบแบบฟัซซิ่งใช้เพื่อแสดงให้เห็นถึงการมีอยู่ของบั๊กมากกว่าการไม่มีบั๊ก การดำเนินแคมเปญฟัซซิ่งเป็นเวลาหลายสัปดาห์โดยไม่พบบั๊กไม่ได้พิสูจน์ว่าโปรแกรมถูกต้อง^{[ 45 ]}ท้ายที่สุด โปรแกรมอาจยังคงล้มเหลวสำหรับอินพุตที่ยังไม่ได้ดำเนินการ การดำเนินการโปรแกรมสำหรับอินพุตทั้งหมดมีค่าใช้จ่ายสูงมาก หากเป้าหมายคือการพิสูจน์ว่าโปรแกรมถูกต้องสำหรับอินพุตทั้งหมด จะต้องมี ข้อกำหนดอย่างเป็นทางการและต้องใช้ เทคนิคจาก วิธีการอย่างเป็นทางการ

เพื่อให้สามารถเปิดเผยข้อบกพร่องได้ ฟัซเซอร์จะต้องสามารถแยกแยะพฤติกรรมของโปรแกรมที่คาดหวัง (ปกติ) ออกจากพฤติกรรมที่ไม่คาดหวัง (มีข้อบกพร่อง) ได้ อย่างไรก็ตาม เครื่องจักรไม่สามารถแยกแยะข้อบกพร่องออกจากคุณสมบัติได้เสมอไป ในการทดสอบซอฟต์แวร์ อัตโนมัติ ปัญหานี้เรียกว่าปัญหาออราเคิลการทดสอบ^{[ 46 ] [ 47 ]}

โดยทั่วไปแล้ว ฟัซเซอร์จะแยกแยะระหว่างอินพุตที่ทำให้โปรแกรมล่มและอินพุตที่ไม่ล่ม ในกรณีที่ไม่มีข้อกำหนดเฉพาะ และเพื่อใช้การวัดที่เรียบง่ายและเป็นกลาง การล่มของโปรแกรมสามารถระบุได้ง่าย และอาจบ่งชี้ถึงช่องโหว่ที่อาจเกิดขึ้น (เช่นการโจมตีแบบปฏิเสธการให้บริการหรือการเรียกใช้โค้ดโดยพลการ ) อย่างไรก็ตาม การที่โปรแกรมไม่ล่มไม่ได้หมายความว่าไม่มีช่องโหว่ ตัวอย่างเช่น โปรแกรมที่เขียนด้วยภาษาCอาจล่มหรือไม่ล่มก็ได้เมื่ออินพุตทำให้เกิดบัฟเฟอร์โอเวอร์โฟลว์พฤติกรรมของโปรแกรมจึงไม่แน่นอน

เพื่อให้ฟัซเซอร์มีความไวต่อความล้มเหลวอื่นๆ นอกเหนือจากการหยุดทำงานมากขึ้น สามารถใช้สารกันเสียเพื่อแทรกการยืนยันที่ทำให้โปรแกรมหยุดทำงานเมื่อตรวจพบความล้มเหลว^{[ 48 ] [ 49 ]}มีสารกันเสียที่แตกต่างกันสำหรับบั๊กประเภทต่างๆ:

• เพื่อตรวจจับข้อผิดพลาดที่เกี่ยวข้องกับหน่วยความจำ เช่นบัฟเฟอร์โอเวอร์โฟลว์และการใช้งานหน่วยความจำหลังจากถูกปล่อย (โดยใช้โปรแกรมดีบักหน่วยความจำเช่นAddressSanitizer )
• เพื่อตรวจจับสภาวะการแข่งขันและการติดตาย (ThreadSanitizer)
• เพื่อตรวจจับพฤติกรรมที่ไม่กำหนด (UndefinedBehaviorSanitizer)
• เพื่อตรวจจับการรั่วไหลของหน่วยความจำ (LeakSanitizer) หรือ
• เพื่อตรวจสอบความสมบูรณ์ของการควบคุมการไหล (CFISanitizer)

การทดสอบแบบฟัซซิ่งยังสามารถใช้เพื่อตรวจจับข้อบกพร่อง "ความแตกต่าง" ได้หาก^มีการใช้งานอ้างอิงสำหรับ การทดสอบการถดถอยอัตโนมัติ ^{[ 50 ]}อินพุตที่สร้างขึ้นจะถูกดำเนินการกับโปรแกรมสองเวอร์ชันเดียวกัน สำหรับการทดสอบความแตกต่าง อัตโนมัติ [ ^{51 ]}อินพุตที่สร้างขึ้นจะถูกดำเนินการกับการใช้งานสองแบบของโปรแกรมเดียวกัน (เช่นlighttpdและhttpdเป็นการใช้งานเว็บเซิร์ฟเวอร์ทั้งคู่) หากตัวแปรทั้งสองสร้างเอาต์พุตที่แตกต่างกันสำหรับอินพุตเดียวกัน แสดงว่าอาจมีตัวใดตัวหนึ่งมีข้อบกพร่องและควรได้รับการตรวจสอบอย่างละเอียดมากขึ้น

การวิเคราะห์โปรแกรมแบบคงที่วิเคราะห์โปรแกรมโดยไม่ต้องเรียกใช้งานจริง ซึ่งอาจนำไปสู่ผลลัพธ์ที่ผิดพลาดได้โดยที่เครื่องมือจะรายงานปัญหาเกี่ยวกับโปรแกรมที่ไม่มีอยู่จริง การใช้ฟัซซิ่งร่วมกับการวิเคราะห์โปรแกรมแบบไดนามิกสามารถใช้เพื่อพยายามสร้างอินพุตที่แสดงให้เห็นถึงปัญหาที่รายงาน^{[ 52 ]}

เว็บเบราว์เซอร์สมัยใหม่ผ่านการทดสอบแบบฟัซซิ่งอย่างกว้างขวางทีมรักษาความปลอดภัยของ Chrome ได้ทำการทดสอบฟัซซิ่ง โค้ด ChromiumของGoogle Chrome อย่างต่อเนื่องด้วยคอร์ประมวลผล 15,000 คอร์ ^{[ 53 ]}สำหรับMicrosoft Edge [Legacy]และInternet Explorerนั้นMicrosoft ได้ทำการทดสอบแบบฟัซซิ่งด้วยเครื่องคอมพิวเตอร์ 670 ปีในระหว่างการพัฒนาผลิตภัณฑ์ โดยสร้างการเปลี่ยนแปลง DOMมากกว่า 400 พันล้านครั้งจากไฟล์ HTML 1 พันล้านไฟล์^{[ 54 ] [ 53 ]}

ฟัซเซอร์สร้างอินพุตจำนวนมากในเวลาอันสั้น ตัวอย่างเช่น ในปี 2016 โครงการ Google OSS-fuzz สร้างอินพุตประมาณ 4 ล้านล้านรายการต่อสัปดาห์^{[ 17 ]}ดังนั้น ฟัซเซอร์จำนวนมากจึงมีชุดเครื่องมือที่ทำให้งานที่ต้องทำด้วยตนเองและน่าเบื่อหน่ายเป็นไปโดยอัตโนมัติ ซึ่งตามมาด้วยการสร้างอินพุตที่ทำให้เกิดความล้มเหลวโดยอัตโนมัติ

การคัดกรองข้อบกพร่องอัตโนมัติใช้เพื่อจัดกลุ่มอินพุตที่ทำให้เกิดความล้มเหลวจำนวนมากตามสาเหตุหลักและจัดลำดับความสำคัญของข้อบกพร่องแต่ละรายการตามความรุนแรง ฟัซเซอร์สร้างอินพุตจำนวนมาก และอินพุตที่ทำให้เกิดความล้มเหลวจำนวนมากอาจเปิดเผยข้อบกพร่องของซอฟต์แวร์ เดียวกันได้อย่างมีประสิทธิภาพ มีเพียงข้อบกพร่องบางส่วนเท่านั้นที่มีความสำคัญต่อความปลอดภัยและควรได้รับการแก้ไขด้วยลำดับความสำคัญที่สูงกว่า ตัวอย่างเช่นศูนย์ประสานงาน CERTให้เครื่องมือคัดกรอง Linux ซึ่งจัดกลุ่มอินพุตที่ทำให้เกิดข้อผิดพลาดตามการติดตามสแต็ก ที่สร้างขึ้น และแสดงรายการแต่ละกลุ่มตามความน่าจะเป็นที่จะถูกใช้ประโยชน์ได้ [ ^{55 ] ศูนย์วิจัย}ความปลอดภัยของ Microsoft (MSEC) ได้พัฒนาเครื่องมือ "!exploitable" ซึ่งสร้างแฮชสำหรับอินพุตที่ทำให้เกิดข้อผิดพลาดก่อนเพื่อตรวจสอบความเป็นเอกลักษณ์ จากนั้นจึงกำหนดระดับการใช้ประโยชน์ได้: ^{[ 56 ]}

• สามารถใช้ประโยชน์ได้
• อาจถูกเอาเปรียบได้
• อาจจะไม่สามารถใช้ประโยชน์ได้ หรือ
• ไม่ทราบแน่ชัด

บั๊กที่ไม่เคยรายงานมาก่อนและได้รับการคัดกรองแล้วอาจถูกรายงานไปยังระบบติดตามบั๊ก โดยอัตโนมัติ ตัวอย่างเช่น OSS-Fuzz ดำเนินการแคมเปญฟัซซิ่งขนาดใหญ่และต่อเนื่องเป็นเวลานานสำหรับโครงการซอฟต์แวร์ที่สำคัญด้านความปลอดภัยหลายโครงการ โดยบั๊กที่ไม่เคยรายงานมาก่อนแต่ละรายการจะถูกรายงานโดยตรงไปยังระบบติดตามบั๊ก^{[ 17 ]}ระบบติดตามบั๊กของ OSS-Fuzz จะแจ้งผู้ดูแล ซอฟต์แวร์ที่มีช่องโหว่โดยอัตโนมัติ และตรวจสอบเป็นระยะๆ ว่าบั๊กได้รับการแก้ไขใน เวอร์ชันล่าสุดแล้วหรือไม่โดยใช้ข้อมูลป้อนเข้าที่ลดขนาดลงซึ่งทำให้เกิดความล้มเหลว

การลดขนาดอินพุตอัตโนมัติ (หรือการลดกรณีทดสอบ) เป็น เทคนิค การดีบัก อัตโนมัติ เพื่อแยกส่วนของอินพุตที่ทำให้เกิดความล้มเหลวซึ่งเป็นสาเหตุของความล้มเหลว^{[ 57 ] [ 58 ]}หากอินพุตที่ทำให้เกิดความล้มเหลวมีขนาดใหญ่และส่วนใหญ่ผิดรูป อาจเป็นเรื่องยากสำหรับนักพัฒนาที่จะเข้าใจว่าอะไรเป็นสาเหตุของข้อบกพร่องอย่างแท้จริง เมื่อพิจารณาจากอินพุตที่ทำให้เกิดความล้มเหลว เครื่องมือลดขนาดอัตโนมัติจะลบไบต์อินพุตออกให้มากที่สุดเท่าที่จะเป็นไปได้ในขณะที่ยังคงจำลองข้อบกพร่องเดิม ตัวอย่างเช่นDelta Debuggingเป็นเทคนิคการลดขนาดอินพุตอัตโนมัติที่ใช้อัลกอริธึมการค้นหาแบบไบนารี ที่ขยาย เพื่อค้นหาอินพุตที่น้อยที่สุดดังกล่าว^{[ 59 ]}

ต่อไปนี้เป็นรายชื่อฟัซเซอร์ที่อธิบายว่า "เป็นที่นิยม" "ใช้กันอย่างแพร่หลาย" หรือคล้ายคลึงกันในเอกสารวิชาการ^{[ 60 ] [ 61 ]}

• อเมริกันฟัซซี่ลอป (ฟัซเซอร์)
• การทดสอบ Concolic
• ความผิดพลาด
• บั๊ก
• การทดสอบลิง
• การทดสอบแบบสุ่ม
• การเปิดเผยช่องโหว่แบบประสานงาน
• การตรวจจับข้อผิดพลาดขณะรันไทม์
• การทดสอบความปลอดภัย
• การทดสอบควัน (ซอฟต์แวร์)
• การประหารเชิงสัญลักษณ์
• การทดสอบระบบ
• การทดสอบอัตโนมัติ

• Nappa, A.; Blázquez, E. (2023). การทดสอบช่องโหว่ด้วยเครื่องจักร: การวิจัยช่องโหว่โดยอัตโนมัติด้วยอุปกรณ์ IoT จำลองบน Qemu . สำนักพิมพ์ Packt จำกัด. ISBN 9781804614976.คู่มือฉบับสมบูรณ์เกี่ยวกับการวิจัยช่องโหว่โดยอัตโนมัติด้วยอุปกรณ์ IoT จำลอง
• เซลเลอร์, แอนเดรียส; โกปินาท, ราหุล; โบห์เม, มาร์เซล; เฟรเซอร์, กอร์ดอน; ฮอลเลอร์, คริสเตียน (2019) หนังสือเลือนลาง ซาร์บรึคเคิน: CISPA + มหาวิทยาลัยซาร์ลันด์หนังสือเรียนออนไลน์ฟรี ฉบับเบื้องต้นเกี่ยวกับการทดสอบแบบฟัซซิ่ง (Fuzzing)
• Ari Takanen, Jared D. DeMott, Charles Miller, การทดสอบความปลอดภัยซอฟต์แวร์และการรับรองคุณภาพด้วย Fuzzing , 2008, ISBN 978-1-59693-214-2
• Michael Sutton, Adam Greene และ Pedram Amini. Fuzzing: Brute Force Vulnerability Discovery , 2007, ISBN 0-321-44611-9.
• H. Pohl, การระบุช่องโหว่ Zero-Day อย่างคุ้มค่าด้วยความช่วยเหลือของการสร้างแบบจำลองภัยคุกคามและการทดสอบแบบ Fuzzing , 2011
• ฟาเบียน ดูเชน, การตรวจจับช่องโหว่ของเว็บไซต์โดยใช้การอนุมานแบบจำลองร่วมกับการทดสอบแบบฟัซซิ่งเชิงวิวัฒนาการ, 2014, วิทยานิพนธ์ปริญญาเอก
• Bratus, Sergey; Darley, Trey; Locasto, Michael; Patterson, Meredith L.; Shapiro, Rebecca Bx; Shubina, Anna; "Bx" Shapiro, Rebecca; Shubina, Anna (2014). "Beyond Planted Bugs in "Trusting Trust": The Input-Processing Frontier". IEEE Security & Privacy . 12 (1): 83– 87. Bibcode : 2014ISPri..12a..83M . doi : 10.1109/MSP.2014.1 .—โดยพื้นฐานแล้วเป็นการเน้นให้เห็นว่าเหตุใดการทดสอบแบบฟัซซิ่งจึงได้ผลดี: เพราะอินพุตคือโปรแกรมควบคุมของตัวแปลภาษา

• Fuzzing Projectประกอบด้วยบทช่วยสอน รายชื่อ โครงการ โอเพนซอร์ส ที่สำคัญด้านความปลอดภัย และแหล่งข้อมูลอื่นๆ
• โครงการทดสอบแบบฟัซซ์ของมหาวิทยาลัยวิสคอนซิน (โครงการฟัซซ์ดั้งเดิม)แหล่งที่มาของเอกสารและซอฟต์แวร์ฟัซซ์
• การออกแบบอินพุตที่ทำให้ซอฟต์แวร์ล้มเหลววิดีโอการประชุม รวมถึงการทดสอบแบบฟัซซี
• การสร้างเฟรมเวิร์กการทดสอบแบบฟัซซิ่งที่ 'คำนึงถึงโปรโตคอล'