Testare thick-client

Aplicațiile desktop au un dezavantaj structural pe care aplicațiile web nu-l au: rulează pe mașini pe care nu le controlezi. Tot ce „știe” aplicația ca să funcționeze — credențiale, șiruri de conexiune, chei, logica pe care o ascunde — e acolo, pe endpoint, la îndemâna cuiva care are o copie a ei. Diferența dintre o problemă minoră și una gravă o dă des arhitectura: o aplicație în două straturi, care vorbește direct cu baza de date, poartă credențialele bazei și logica pe client — și de acolo un atacator ajunge, prin SQL injection, direct în date.

Ce testăm

• Stocare și secrete la rest — fișiere de configurare, registru, baze SQLite, memorie, fișiere temporare: credențiale, șiruri de conexiune, chei API, token-uri
• Binar și DLL — decompilare și reverse engineering (.NET și nativ); verificări de întărire (ASLR, DEP, semnătură Authenticode); DLL hijacking și abuz de ordine de căutare, identificate prin analiza „NAME NOT FOUND”
• Trafic — interceptare HTTP/S și non-HTTP (protocoale binare proprii), ocolirea validării TLS și a certificate pinning
• Manipulare în timpul execuției — hooking de funcții cu Frida, ca să ocolim controale din client: licențiere, verificări de rol, butoane dezactivate, logică de business ținută periculos în aplicație
• Injecție în backend — SQL injection (mai ales pe aplicații 2 straturi), injecție de comenzi, deserializare nesigură, verificări de autorizare pe server
• Escaladare locală de privilegii — permisiuni nesigure pe fișiere și registru, servicii care rulează ca SYSTEM, căi de serviciu neîncadrate, directoare de instalare cu drept de scriere

Ce primești

• Constatări mapate pe CWE, fiecare cu dovadă (cereri interceptate, binare modificate, secrete extrase)
• O notă de risc pe arhitectură (2 vs 3 straturi) și implicațiile ei
• Remediere concretă: mută încrederea și secretele pe server, aplică TLS și pinning corect, întărește binarul, repară ACL-urile și căile de serviciu