Tutorial de testare Fuzz (Fuzzing).

Ce este Fuzz Testing?

Testarea Fuzz sau Fuzzing este o tehnică de testare software care constă în introducerea de date nevalide sau aleatorii, numită FUZZ, într-un sistem software pentru a descoperi erori de codare și lacune de securitate. Scopul testării fuzz este de a introduce date folosind tehnici automate sau semi-automate și de a testa sistemul pentru diverse excepții, cum ar fi blocarea sistemului sau defecțiunea codului încorporat.

Testarea fuzz a fost dezvoltată inițial de Barton Miller la Universitatea din Wisconsin-Madison, care a inventat termenul după ce zgomotul de linie de pe o legătură de modem a dus la blocarea programelor pe care le folosea. Studenții săi au rulat primele fuzzere în 1989 și au descoperit că aproximativ o treime din utilitarele UNIX pe care le-au vizat s-au blocat sau s-au blocat. Testarea fuzz este o testare software tehnică și este un tip de Testarea securității.

Diagrama de mai jos prezintă bucla de fuzzing de bază, în care datele generate sunt trimise către aplicația testată, iar răspunsul este observat.

De ce să faci Fuzz Testing?

Fuzzing-ul își câștigă locul într-un plan de testare deoarece explorează input-urile pentru care nimeni nu s-a gândit să scrie un caz de testare. Principalele motive pentru care echipele îl adoptă sunt enumerate mai jos.

• Testarea fuzz găsește de obicei cele mai grave erori și defecte de securitate, deoarece o eroare este o dovadă directă a unei căi de intrare netratate.
• Testarea fuzz oferă rezultate mai eficiente atunci când este utilizată cu Negru Box Testarea, testarea beta și alte metode de depanare.
• Testarea fuzz este utilizată pentru a verifica vulnerabilitatea software-ului și este o tehnică de testare foarte rentabilă, deoarece datele de intrare sunt generate mai degrabă decât scrise de mână.
• Testarea fuzz este una dintre tehnicile de testare de tip „cutie neagră”. Fuzzing-ul este, de asemenea, una dintre cele mai comune metode folosite de hackeri pentru a găsi o vulnerabilitate într-un sistem, așa că rularea ei mai întâi elimină cea mai ușoară rută de intrare pentru un atacator.

Tipuri de testare Fuzz

Fuzzerii sunt de obicei grupați în funcție de cât știu despre programul pe care îl atacă. Cu cât fuzzerul știe mai multe, cu atât poate aprofunda codul.

Tip	Ce știe fuzzerul	Utilizare tipică
Cutia neagră fuzzing	Nimic despre componentele interne; vede doar intrări și ieșiri.	Fumul rapid rulează împotriva unui binar sau a unui endpoint live.
Cutie albă care se estompează	Cod sursă complet, adesea combinat cu execuție simbolică pentru a rezolva ramificațiile greu accesibile.	Analiza aprofundată a unei componente a cărei sursă este disponibilă.
Cutia gri fuzzing	Fără revizuire a sursei, dar cu feedback la momentul execuției, cum ar fi ramificațiile de cod la care a ajuns o intrare.	Implicit pentru motoarele moderne precum AFL++ și libFuzzer.

O a doua divizare, mai veche, separă prostii de la fuzzing inteligentUn parser neinteligent schimbă biții fără să știe ce format de intrare are, așa că majoritatea datelor sale sunt respinse de primul parser pe care îl întâlnește. Un parser inteligent înțelege sumele de control, câmpurile de lungime și structura mesajelor, astfel încât intrările sale supraviețuiesc validării și ajung la logica de bază. Fuzzing ghidat de acoperire este rafinamentul de tip „cutie gri” care a făcut ca fuzzing-ul să devină mainstream: motorul instrumentează codul binar, păstrează orice intrare care ajunge la o nouă ramură și modifică supraviețuitorii, astfel încât corpusul evoluează constant către cod neexplorat în loc să repornească de la un zgomot aleatoriu.

Cum se face Fuzz Testing

Pașii pentru testarea fuzz includ pașii de bază ai testării:

Pasul 1) Identificați sistemul țintă — alegeți fișierul binar, biblioteca, serviciul sau endpoint-ul protocolului care va fi atacat și confirmați că aveți permisiunea de a-l testa.

Pasul 2) Identificați intrările — listează fiecare punct de intrare din care citește ținta: fișiere, argumente din linia de comandă, variabile de mediu, pachete de rețea, câmpuri de formular și sarcini utile API.

Pasul 3) Generați date Fuzzed — produc intrări malformate prin mutarea eșantioanelor valide, prin generarea lor dintr-un model al formatului sau prin combinarea ambelor.

Pasul 4) Executați testul folosind date fuzzy — rulează ținta în funcție de intrările generate, ideal într-o buclă care repornește procesul automat după fiecare eșec.

Pasul 5) Monitorizați comportamentul sistemului — fiți atenți la erori, blocări, erori de aserționări, utilizare excesivă a memoriei și rapoarte de dezinfectare, în loc să verificați doar rezultatul tipărit.

Pasul 6) Înregistrați defectele — salvați intrarea exactă care a declanșat fiecare eșec, micșorați-o la cel mai mic caz reproductiv și arhivați-o în stivă trace atașat.

Exemple de Fuzzers

Fuzzerii sunt clasificați și în funcție de modul în care își construiesc inputul, iar cele trei abordări de mai jos sunt cele pe care le veți întâlni cel mai des.

• Fuzzers bazate pe mutații modificați mostrele de date existente pentru a crea noi date de test. Aceasta este o abordare foarte simplă și directă: începe cu mostre valide ale unui protocol și continuă să modifice fiecare octet sau fișier.
• Fuzzere bazate pe generații definesc date noi pe baza datelor de intrare ale modelului. Încep să genereze date de intrare de la zero pe baza specificației.
• Fuzzeri bazați pe protocol depind de cunoștințe detaliate despre formatul protocolului testat, iar această înțelegere provine din specificație. Aceasta implică scrierea unei matrice a specificației în instrument, apoi utilizarea unei tehnici de generare de teste bazate pe model pentru a parcurge specificația și a adăuga nereguli în conținutul datelor, secvență și așa mai departe. Aceasta este cunoscută și sub denumirea de testare sintactică, testare gramaticală sau testare a robusteții. Un fuzzer poate genera cazuri de testare dintr-unul existent sau poate utiliza intrări valide sau nevalide.

Există două limitări ale fuzzing-ului bazat pe protocol:

1. Testarea nu poate continua până când specificația este matură.
2. Multe protocoale utile sunt o extensie a protocoalelor publicate. Dacă testarea fuzz se bazează pe specificațiile publicate, Testați acoperirea pentru noile protocoale vor fi limitate.

Cea mai simplă formă de tehnică de fuzzing este trimiterea de date de intrare aleatorii către software, fie sub formă de pachete de protocol, fie ca eveniment. Această tehnică de transmitere a unor date de intrare aleatorii este foarte puternică pentru găsirea erorilor în multe aplicații și servicii. Sunt disponibile și alte tehnici, care sunt foarte ușor de implementat. Pentru a implementa aceste tehnici, trebuie doar să modificăm intrările existente și putem modifica o intrare pur și simplu prin interschimbarea biților acesteia.

Tipuri de erori detectate de Fuzz Testing

Deoarece fuzzingul judecă o rulare după cum se comportă programul și nu după o valoare așteptată, defectele pe care le scoate la iveală se grupează în trei familii.

• Eșecuri de afirmare și scurgeri de memorie: Această metodologie este utilizată pe scară largă pentru aplicații mari în care erorile afectează siguranța memoriei, ceea ce reprezintă o vulnerabilitate severă. Buffer Aici apar depășirile de capacitate, citirile de tip „use-after-free” și citirile out-of-bounds.
• Intrare nevalidă: În testarea fuzz, fuzzerii sunt folosiți pentru a genera date de intrare nevalide, care sunt folosite pentru testarea rutinelor de gestionare a erorilor, iar acest lucru este important pentru software-ul care nu își controlează datele de intrare. Fuzzing-ul simplu poate fi văzut ca o modalitate de a automatiza testare negativă.
• Erori de corectitudine: Fuzzing-ul poate fi folosit și pentru a detecta anumite tipuri de erori de „corectitudine”, cum ar fi o bază de date coruptă sau rezultate de căutare slabe. Fuzzing-ul diferențial, care furnizează aceeași intrare către două implementări și compară răspunsurile, este modalitatea obișnuită de a le detecta.

Instrumente de testare Fuzz

Instrumentele utilizate în securitatea web pot fi utilizate pe scară largă în testarea fuzz, cum ar fi Burp Suite și Peach Fuzzer. Mai multe dintre numele clasice de mai jos sunt acum arhivate, așa că statutul lor actual este menționat lângă fiecare intrare.

• Fuzzer cu piersiciPeach Fuzzer oferă o acoperire de securitate mai robustă decât un scaner. Alte instrumente de testare pot căuta doar amenințări cunoscute, în timp ce Peach Fuzzer permite utilizatorilor să găsească amenințări cunoscute și necunoscute. Peach Tech a fost achiziționată de GitLab, iar Community Edition v3 nu mai este întreținută; succesorul întreținut este Ediția Comunitară GitLab Protocol Fuzzer.
• Spike Proxy: un instrument de nivel profesional care caută vulnerabilități la nivel de aplicație în aplicațiile web. SPIKE Proxy acoperă elementele de bază, cum ar fi SQL Injecție și scripting cross-site, pe o rețea complet deschisă Python infrastructură și era disponibilă pentru Linux și WindowsNu a fost întreținut de mulți ani și este inclus aici din motive istorice.
• WebScarabWebScarab este scris în Java și, prin urmare, este portabil pe multe platforme. Framework-ul WebScarab comunică folosind protocoalele HTTP și HTTPS și funcționează ca un proxy de interceptare: permite operatorului să revizuiască și să modifice cererile create de browser înainte ca serverul să le primească și să revizuiască și să actualizeze răspunsurile generate de server înainte ca browserul să le primească. Orice breșă pe care o găsește WebScarab este adăugată la lista sa de probleme raportate. Depozitul a fost arhivat în aprilie 2024 și este acum doar pentru citire.
• OWASP WSFuzzerWSFuzzer este un program licențiat GPL, scris în Python care viza serviciile web și, în ultima sa versiune, bazat pe HTTP Servicii SOAP au fost ținta principală. A fost livrat ca parte a WebScarab și a fost retras odată cu acesta; OWASP ZAP și add-on-ul său Fuzzer sunt înlocuitorul recomandat.
• Alternative menținute: AFL++ și libFuzzer sunt motoarele standard ghidate de acoperire pentru codul nativ, OSS-Fuzz le rulează continuu și gratuit pentru proiecte open-source și boofuzz acoperă fuzzing-ul protocolului de rețea în PythonO listă mai amplă este inclusă în ghidul pentru instrumente de testare a securității.

Cele mai bune practici de testare fuzz

Un fuzzer îndreptat spre o țintă și lăsat în pace rareori găsește prea multe. Practicile de mai jos diferențiază o campanie care produce defecte înregistrate de una care doar consumă timp CPU.

• Începeți de la un corpus de semințe bun. Colectează intrări reale, valide, pe care aplicația le acceptă deja. Mutarea unui fișier autentic ajunge la codul de parsare mult mai repede decât mutarea unor octeți aleatori.
• Scrieți un ham mic și rapid. Punctul de intrare ar trebui să facă un singur lucru per rulare, să evite apelurile de rețea și scrierile pe disc și să se întoarcă rapid, deoarece debitul se măsoară în execuții pe secundă.
• Porniți dezinfectantele. Corupția silențioasă a memoriei adesea nu duce la blocări. AddressSanitizer și UndefinedBehaviorSanitizer o transformă într-o eroare imediată, diagnosticabilă.
• Aleargă mult timp și aleargă continuu. O rulare de una sau două ore identifică erorile superficiale; căile profunde necesită de obicei multe ore, motiv pentru care fuzzing-ul ar trebui să fie inclus într-o sesiune CI nocturnă, mai degrabă decât într-o sesiune manuală.
• Minimizează și deduplică fiecare eroare. Reduce intrarea eșuată la cea mai mică formă și grupează erorile după stivă trace, altfel o eroare ajunge cât sute de bilete.
• Păstrați un corpus de regresie. Adăugați fiecare intrare de reproducere la un set permanent care rulează la fiecare compilare, astfel încât un defect remediat să nu poată reveni în mod discret.
• Delimitează ținta din punct de vedere legal. Defectarea unui serviciu terț activ fără permisiune scrisă este imposibil de distins de un atac.

Avantajele testării Fuzz

Folosită cu așteptări realiste, fuzzing-ul adaugă o valoare pe care alte tehnici se chinuie să o egaleze.

• Testarea fuzz îmbunătățește testarea securității software-ului.
• Erorile găsite în fuzzing sunt uneori severe și sunt adesea aceleași cu cele folosite de atacatori, inclusiv blocări, scurgeri de memorie și excepții netratate.
• Dacă testerii nu observă erori din cauza limitărilor de timp și resurse, acele erori se găsesc și în testarea fuzz.
• Intrările sunt generate de o mașină, astfel încât acoperirea continuă să crească peste noapte, fără efort manual suplimentar.

Dezavantajele testării Fuzz

Aceleași proprietăți care fac fuzzing-ul ieftin limitează și ceea ce poate dovedi.

• Testarea fuzz singură nu poate oferi o imagine completă a unei amenințări generale de securitate sau a unui set de erori.
• Testarea fuzz este mai puțin eficientă în gestionarea amenințărilor de securitate care nu provoacă blocări ale programelor, cum ar fi unii viruși, viermi și troieni.
• Testarea fuzz poate detecta doar erori sau amenințări relativ simple și nu va raționa despre logica de afaceri.
• Pentru a funcționa eficient, necesită un timp semnificativ de lucru cu mașina.
• Stabilirea unei condiții de valoare limită cu intrări aleatorii este foarte problematică, deși testerii rezolvă acum o mare parte din aceasta cu algoritmi determiniști conduși de intrările utilizatorului.

Testarea Fuzz vs. Testarea Penetrației

Ambele activități caută defecte de securitate, însă răspund la întrebări diferite și sunt rareori interschimbabile.

Criterii	Testarea Fuzz	Testarea penetrării
Condus de	Un motor automat care generează date de intrare incorecte	Un tester priceput raționează despre sistem
Caută	Blocări, blocări și erori de siguranță a memoriei	Puncte slabe exploatabile, inclusiv defecte logice și de configurare
Adâncime	Acoperire foarte largă a datelor de intrare, raționament superficial	Acoperire restrânsă, raționament profund
producție	Reproducerea intrărilor și a stivei traces	Un raport de constatări cu căi de exploatare și evaluări ale riscurilor
Cel mai bun moment	Continuu, în procesul de construire	Periodic, împotriva unui candidat la lansare

În practică, cele două se alimentează reciproc: fuzzing-ul elimină erorile ieftine și automatizabile, astfel încât orele limitate ale unui tester sunt dedicate defectelor pe care doar un om le poate observa.

Întrebări frecvente