În practică #10 | Cum ajunge o vulnerabilitate într-o aplicație?
Cum schimbă tehnologia modul în care lucrăm
„În practică” este seria în care explicăm, fără jargon inutil și pornind de la exemple concrete, concepte și tehnologii care stau în spatele instrumentelor digitale pe care le folosim zi de zi.
O aplicație poate să funcționeze exact așa cum a fost gândită. Butoanele răspund, utilizatorii se pot autentifica, datele se salvează, comenzile ajung unde trebuie.
Și totuși, undeva în cod sau în modul în care aplicația a fost configurată, poate exista o vulnerabilitate.
Uneori este nevoie doar ca cineva să folosească o funcție într-un mod la care echipa care a construit-o nu s-a gândit.
Ce este, de fapt, o vulnerabilitate?
Pe scurt, o vulnerabilitate este o slăbiciune care poate fi exploatată pentru a face ceva ce sistemul nu ar trebui să permită.
Poate însemna acces la informații care ar trebui să fie private, executarea unor acțiuni fără permisiune, modificarea unor date sau chiar compromiterea unei aplicații.
Important este că vulnerabilitatea și atacul nu sunt același lucru.
Vulnerabilitatea este problema existentă în sistem. Atacul apare atunci când cineva încearcă să profite de ea.
E puțin ca o ușă care se închide, dar a cărei yală poate fi deschisă foarte ușor. Faptul că există problema nu înseamnă că cineva a intrat deja. Înseamnă însă că există o cale prin care ar putea să o facă.
Cum ajunge acolo?
Rareori cineva introduce intenționat o vulnerabilitate într-o aplicație. De cele mai multe ori, ea apare în procesul normal de dezvoltare.
O aplicație modernă poate avea mii sau milioane de linii de cod și poate folosi numeroase biblioteci, servicii și componente dezvoltate de alte echipe. În plus, se schimbă constant: apar funcționalități noi, actualizări și integrări cu alte sisteme.
Într-un asemenea ecosistem, vulnerabilitățile pot avea surse foarte diferite.
Uneori problema este în cod. Alteori, într-o bibliotecă externă care conține la rândul ei o vulnerabilitate. Poate fi vorba despre o configurare greșită, despre drepturi de acces prea largi sau despre o funcționalitate care nu verifică suficient de bine datele primite de la utilizator.
Un formular aparent banal
Să ne imaginăm un magazin online cu o casetă de căutare.
Utilizatorul scrie numele unui produs, iar aplicația caută informația în baza de date și afișează rezultatele.
În mod normal, în acea casetă ar trebui să ajungă ceva precum „laptop” sau „căști”.
Dar ce se întâmplă dacă cineva introduce în locul unui cuvânt obișnuit o secvență construită special pentru a modifica modul în care aplicația comunică cu baza de date?
Dacă aplicația tratează fără verificări suficiente ceea ce primește de la utilizator, acea intrare poate ajunge să fie interpretată ca o comandă.
Acesta este principiul din spatele unei categorii cunoscute de vulnerabilități numite SQL Injection.
Nu este important să știm sintaxa unui asemenea atac pentru a înțelege ideea. Problema apare atunci când aplicația nu separă suficient de bine datele introduse de utilizator de instrucțiunile pe care sistemul trebuie să le execute.
O simplă casetă de text poate deveni astfel o cale de acces către ceva ce utilizatorul nu ar fi trebuit să poată controla.
Dar dacă aplicația a fost testată?
Testarea este esențială, dar există mai multe feluri de a testa o aplicație.
Poți verifica dacă funcția de autentificare funcționează atunci când introduci datele corecte. Poți verifica ce se întâmplă când parola este greșită. Poți testa dacă utilizatorul ajunge pe pagina potrivită după autentificare.
Din perspectiva securității apare însă o întrebare suplimentară:
Ce s-ar întâmpla dacă cineva ar încerca intenționat să folosească această funcție altfel decât a fost proiectată?
De aici vine și ideea de adversarial thinking – să privești sistemul și din perspectiva celui care încearcă să-i găsească punctele slabe.
Nu verifici doar dacă aplicația face ceea ce trebuie. Încerci să descoperi și ce ar putea face atunci când primește ceva neașteptat.
Uneori problema nici măcar nu este în codul tău
Aplicațiile nu sunt construite de fiecare dată de la zero.
Programatorii folosesc biblioteci, framework-uri și alte componente software pentru funcționalități care există deja. Este firesc: altfel, dezvoltarea unei aplicații moderne ar dura enorm.
Dar apare și o consecință.
Dacă una dintre componentele folosite are o vulnerabilitate, aplicația poate deveni vulnerabilă chiar dacă problema nu se află în codul scris direct de echipa respectivă.
De aceea actualizările nu înseamnă doar funcții noi sau schimbări de interfață. Unele dintre ele repară probleme de securitate descoperite între timp.
Cum aflăm că există o vulnerabilitate?
Unele vulnerabilități sunt identificate de programatori în timpul dezvoltării. Altele apar în urma testelor de securitate sau a instrumentelor automate care analizează codul și componentele utilizate.
Există și specialiști care încearcă deliberat să găsească punctele slabe ale unui sistem înainte ca acestea să fie exploatate într-un atac real. Aici intră, printre altele, penetration testing-ul.
Iar atunci când o vulnerabilitate este descoperită într-un produs sau într-o componentă folosită pe scară largă, informația poate deveni relevantă pentru mii de organizații care folosesc aceeași tehnologie.
Urmează identificarea sistemelor afectate, evaluarea riscului și, atunci când există o soluție, actualizarea sau remedierea lor.
Securitatea nu începe după ce aplicația este gata
Poate că aceasta este partea cea mai importantă.
E mult mai dificil să construiești o aplicație și abia la final să întrebi: „Bun, și acum cum o facem sigură?”
Securitatea intră în multe dintre deciziile luate pe parcurs: cum sunt stocate datele, cum se autentifică utilizatorii, ce drepturi primește fiecare, ce informații acceptă aplicația, ce componente externe folosește și cum sunt acestea actualizate.
De aceea, pentru programatori, cybersecurity nu mai este o zonă complet separată, rezervată exclusiv specialiștilor în securitate.
Înseamnă și să te obișnuiești să pui încă o întrebare atunci când construiești ceva:
„Cum ar putea fi folosit acest lucru într-un mod la care nu m-am gândit?”
Este una dintre întrebările care pot face diferența dintre o aplicație care doar funcționează și una construită să reziste mai bine atunci când cineva încearcă să-i găsească punctele slabe.
Citește și celelalte articole din seria „În practică”
Comentarii