Înțelegerea celor mai importante 10 riscuri OWASP Mobile cu cazurile din lumea reală

Deținerea unui record în industrie de dezvoltare a aplicațiilor 100% rezistente la hack vine cu o responsabilitate și o garanție de bază că niciuna dintre soluțiile digitale dezvoltate sub numele nostru nu s-ar confrunta cu o încălcare a securității.

Pentru a realiza acest lucru, echipa de asigurare a calității Appinventiv este familiarizată cu toate riscurile de securitate posibile cu care se poate confrunta o aplicație. Cunoașterea riscurilor face ușor să ignorați capcanele și să scrieți aplicații sigure.

Ajutându-ne să fim în fruntea jocului atunci când vine vorba de asigurarea securității, înseamnă a avea o cunoaștere completă a practicilor de codare sigură OWASP (Open Web Application Security Project). Este o comunitate online de specialiști în securitate care au dezvoltat documentație gratuită, materiale de învățare și instrumente pentru construirea de aplicații mobile și web sigure.

Alături de alte lucruri, ei au întocmit și o listă cu OWASP Mobile Top 10 amenințări de securitate din aplicațiile mobile.

Deși documentul privind practicile de securitate OWASP este destul de clar, uneori poate fi dificil pentru companii să-l conecteze de cazuri reale.

În acest articol, vă vom oferi o prezentare generală de bază a Top 10 riscuri de securitate mobilă și vă vom oferi exemple de vulnerabilități dezvăluite în lumea reală pentru fiecare dintre ele. Vă va oferi o perspectivă asupra a ceea ce ne pregătim la Appinventiv atunci când lucrăm la aplicația dvs.

Înainte de a analiza riscurile, să ne uităm la statistici.

NowSecure a analizat aplicațiile din magazinul Google Play și magazinul de aplicații a identificat că peste 85% dintre aplicații încalcă unul dintre riscuri.

Dintre aceste aplicații, 50% au avut stocare de date nesigură și undeva același număr de aplicații lucrau cu risc de comunicare nesigură . Iată un grafic care arată procentul de apariție a riscurilor OWASP Mobile Top 10

Lista celor mai frecvente 10 amenințări la adresa aplicațiilor mobile și cele mai bune practici pentru a le evita

M1: Utilizare necorespunzătoare a platformei

Categoria de testare de securitate OWASP constă în utilizarea greșită a funcționalității unui dispozitiv sau instanța de defecțiune la utilizarea controalelor de securitate ale platformei. Poate include permisiunile platformei, intentiile Android, utilizarea greșită a TouchID-ului, brelocul etc.

Caz din lumea reală:

Trei aplicații iOS : „Aplicația Fitness Balance”, „Monitor de ritm cardiac” și „Aplicația Calorii Tracker” au apărut pentru a ocoli Touch ID-ul Apple. Ei le cereau utilizatorilor să-și folosească amprenta pentru a obține informații despre fitness, în timp ce o foloseau pentru a percepe bani din App Store.

Cele mai bune practici de evitat:

• Dezvoltatorul nu trebuie să permită criptările Keychain prin ruta serverului și să păstreze cheile doar pe un singur dispozitiv, astfel încât să fie imposibil să fie exploatate pe alte servere sau dispozitive.
• Dezvoltatorul trebuie să securizeze aplicația prin Keychain pentru a stoca secretul aplicației care are o listă dedicată de control al accesului.
• Dezvoltatorul trebuie să primească permisiunea pentru a limita aplicațiile care au permisiunea de a comunica cu aplicația lor.
• Dezvoltatorul trebuie să controleze primul din lista OWASP Mobile Top 10 prin definirea intențiilor explicite și blocând astfel toate celelalte componente pentru a accesa informațiile prezente în intenție.

M2: Stocarea nesigură a datelor

OWASP consideră că este o amenințare atunci când cineva are acces la un dispozitiv mobil pierdut/furat sau când malware sau o altă aplicație reambalată începe să acționeze în numele adversarului și execută acțiuni pe dispozitivul mobil.

O vulnerabilitate nesigură de stocare a datelor duce de obicei la următoarele riscuri:

• Fraudă
• Furt de identitate
• Pierdere materială.
• Daune reputației
• Încălcarea politicii externe (PCI)

Caz din lumea reală :

Aplicațiile de întâlniri precum Tinder, OKCupid și Bumble au fost analizate în repetate rânduri pentru practicile lor nesigure de stocare a datelor. Deficiențele de securitate prezente pe aceste aplicații variază în funcție de fezabilitate și severitate și fezabilitate, pot expune numele utilizatorilor, detaliile de conectare, istoricul mesajelor și chiar locația, în plus față de alte activități din contul personal.

Cele mai bune practici de evitat:

• Pentru iOS, practicile de securitate OWASP recomandă utilizarea aplicațiilor vulnerabile create în mod intenționat, cum ar fi iGoat, pentru a amenința modelul cadrului și aplicațiilor lor de dezvoltare. Acest lucru îi va ajuta pe dezvoltatorii de aplicații iOS să înțeleagă modul în care API-urile se ocupă de procesele aplicației și de activele de informații.
• Dezvoltatorii de aplicații Android pot folosi shell-ul Android Debug Bridge pentru a verifica permisiunile de fișiere ale aplicației vizate și ale DBMS pentru a verifica criptarea bazei de date. De asemenea, ar trebui să folosească Instrumentul de analiză a memoriei și Monitorul dispozitivului Android pentru a se asigura că memoria dispozitivului nu are date neintenționate.

M3: Comunicare nesigură

La conceperea unei aplicații mobile, datele sunt schimbate în modelul client-server. Deci, atunci când datele sunt transmise, acestea ar trebui mai întâi să traverseze rețeaua operatorului dispozitivului și internetul. Agenții de amenințare ar putea exploata vulnerabilități și ar putea intercepta date sensibile în timp ce călătoresc prin cablu. Iată diferiții agenți de amenințare care există:

• Adversar care îți partajează rețeaua locală – un Wi-Fi compromis
• Dispozitive de rețea sau de transport – turnuri celulare, proxy, routere etc.
• Programe malware pe dispozitivul mobil.

Interceptarea datelor sensibile prin canalul de comunicare s-ar solda cu o încălcare a confidențialității, care poate duce la:

• Furt de identitate
• Fraudă
• Daune reputaționale.

Caz din lumea reală:

Compania de securitate Rapid7 a dezvăluit mai multe vulnerabilități legate de ceasurile inteligente pentru copii. Acele ceasuri au fost comercializate ca fiind folosite de părinți pentru a-și urmări copiii și pentru a le trimite mesaje sau pentru a efectua apeluri pe ceasul lor inteligent.

Ceasurile trebuia să fie contactate de numere de contact aprobate prin intermediul unei liste albe, dar compania a constatat că filtrele nici măcar nu funcționau. Ceasurile au acceptat chiar și comenzi de configurare prin mesaje text. Însemna că un hacker ar putea schimba setările ceasului și ar putea pune copiii în pericol.

„Puteți identifica unde se află telefonul sau copilul, puteți obține acces la sunet sau puteți efectua apeluri telefonice către copii”, a spus Deral Heiland, responsabil de cercetare IoT la Rapid7.

Cele mai bune practici de evitat:

• Dezvoltatorii ar trebui să caute nu numai scurgerile din traficul comunicat între aplicație și server, ci și dispozitivul care deține aplicația și alt dispozitiv sau rețea locală.

• Aplicarea TLS/SSL pentru transportul canalelor este, de asemenea, una dintre cele mai bune practici de securitate a aplicațiilor mobile de luat în considerare atunci când vine vorba de transmiterea de informații sensibile și alte date sensibile.

• Folosiți certificate date de verificări în lanț SSL de încredere.
• Nu trimiteți date sensibile prin canale alternative, cum ar fi MMS, SMS sau notificări push.
• Aplicați un strat de criptare separat datelor sensibile înainte de a le oferi canalului SSL.

M4: Autentificare nesigură

Agenții de amenințare care exploatează vulnerabilitățile de autentificare fac acest lucru prin atacuri automate care utilizează instrumente personalizate sau disponibile.

Impactul asupra afacerii M4 poate fi:

• Furtul de informații
• Daune reputaționale
• Acces neautorizat la date.

Caz din lumea reală :

În 2019, o bancă din SUA a fost piratată de un atacator cibernetic care a profitat de defectul site-ului băncii și a ocolit autentificarea cu doi factori care a fost implementată pentru protejarea conturilor.

Atacatorul s-a autentificat în sistem prin acreditările victimei furate și, când a ajuns la pagina în care trebuia introdus PIN-ul sau răspunsul de securitate, atacatorul a folosit un șir manipulat în URL-ul web, care a setat computerul ca unul recunoscut. Acest lucru ia permis să treacă scena și să inițieze transferurile bancare.

Cele mai bune practici de evitat:

• Echipa de securitate a aplicației trebuie să studieze autentificarea aplicației și să o testeze prin atacuri binare în modul offline pentru a determina dacă poate fi exploatată.
• Protocoalele de securitate de testare a aplicației web OWASP trebuie să se potrivească cu cele ale aplicațiilor mobile.
• Folosiți cât mai mult posibil metode de autentificare online, la fel ca în cazul browserului web.
• Nu activați încărcarea datelor aplicației până când serverul nu a autentificat sesiunile utilizator.
• Locurile unde eventuale datele locale ne asigură că sunt criptate prin chei criptate derivate din acreditările de conectare ale utilizatorilor.
• Cererea de autentificare persistentă trebuie, de asemenea, stocată pe server.
• Echipa de securitate ar trebui să fie atentă cu jetoanele de autorizare centrate pe dispozitiv în aplicație, deoarece dacă dispozitivul este furat, aplicația poate deveni vulnerabilă.
• Deoarece accesul fizic neautorizat al dispozitivelor este obișnuit, echipa de securitate trebuie să impună autentificarea obișnuită a acreditărilor utilizatorului de la capătul serverului.

M5: Riscuri criptografice insuficiente

Agenții de amenințare în acest caz sunt cei care au acces fizic la date care au fost criptate greșit. Sau în cazul în care un malware acționează în numele adversarului.

Criptografia întreruptă are ca rezultat, în general, următoarele cazuri:

• Furtul de informații
• Furtul de proprietate intelectuală
• Furtul de cod
• Încălcări ale confidențialității
• Daune reputaționale.

Caz din lumea reală :

În urmă cu uneori, o alertă din partea echipei de răspuns la urgențe cibernetice a DHS Industrial Control Systems și avizul Philips au avertizat utilizatorii cu privire la o posibilă vulnerabilitate în aplicația pentru Android Philips HealthSuite Health .

Problema care a fost urmărită până la o putere de criptare inadecvată a deschis aplicația hackerilor care puteau avea acces la activitatea ritmului cardiac al utilizatorilor, tensiunea arterială, starea de somn, greutatea și analiza compoziției corporale etc.

Cele mai bune practici de evitat:

• Pentru a rezolva unul dintre cele mai frecvente riscuri OWASP Top 10 pentru mobil , dezvoltatorii trebuie să aleagă algoritmi moderni de criptare pentru criptarea aplicațiilor lor. Alegerea algoritmului are grijă de vulnerabilitate în mare măsură.
• Dacă dezvoltatorul nu este un expert în securitate, trebuie să se abțină de la a crea propriile coduri de criptare.

M6: Riscuri de autorizare nesigure

În acest caz, agenții de amenințare pot accesa aplicația altcuiva, de obicei, prin atacuri automate care folosesc instrumente personalizate sau disponibile.

Poate duce la următoarele probleme:

• Furtul de informații
• Daune reputaționale
• Fraudă

Caz din lumea reală :

Specialiștii în securitatea informațiilor de la Pen Test Partners au spart Pandora , un sistem inteligent de alarmă auto. În teorie, aplicația este folosită pentru a urmări o mașină, pentru a opri motorul dacă este furat și pentru a-l încuia până la sosirea poliției.

Pe cealaltă parte a monedei, un hacker poate deturna contul și poate avea acces la toate datele și funcționalitățile de alarmă inteligentă. În plus, acestea ar putea:

• Urmăriți mișcările vehiculului
• Activați și dezactivați sistemul de alarmă
• Blocați și deblocați ușile mașinii
• Opriți motorul
• În cazul Pandora, hackerii au avut acces la tot ce se vorbea în interiorul mașinii prin microfonul sistemului antifurt.

Cele mai bune practici de evitat:

• Echipa de QA trebuie să testeze în mod regulat privilegiile utilizatorului, rulând jetoane de sesiune cu privilegii reduse pentru comenzile sensibile.
• Dezvoltatorul trebuie să rețină că schemele de autorizare a utilizatorului merg greșit în modul offline.
• Cea mai bună modalitate de a preveni acest risc este să efectuați verificări de autorizare pentru permisiunile și rolurile unui utilizator autentificat pe server, în loc de dispozitivul mobil.

M7: Riscuri de calitate slabă a codului

În aceste cazuri, intrările neîncrezătoare sunt transmise de entități către apelurile de metodă efectuate în codul mobil. Un efect al acestui lucru poate fi problemele tehnice care pot duce la degradarea performanței, utilizarea grea a memoriei și arhitectura front-end defectuoasă.

Caz din lumea reală :

WhatsApp a corectat anul trecut o vulnerabilitate de care profitau hackerii pentru a instala programe malware de supraveghere numite Pegasus Spyware pe smartphone-uri. Tot ce trebuiau să facă a fost să efectueze un apel audio WhatsApp pe numerele de telefon vizate.

În câțiva pași simpli, hackerii au putut să intre în dispozitivele utilizatorilor și să le acceseze de la distanță.

Cele mai bune practici de evitat:

• Conform practicilor de codare securizată OWASP , codul ar trebui rescris pe dispozitivul mobil în loc să fie fixat pe partea serverului. Dezvoltatorii trebuie să rețină că codarea proastă la nivelul serverului este foarte diferită de codarea proastă la nivel de client. Adică, atât controalelor slabe pe partea serverului , cât și controalelor pe partea clientului ar trebui să li se acorde o atenție separată.
• Dezvoltatorul trebuie să folosească instrumente terțe pentru analiza statică pentru a identifica depășirile de memorie tampon și scurgerile de memorie.
• Echipa trebuie să creeze o listă de biblioteci terță parte și să o verifice periodic pentru versiuni mai noi.
• Dezvoltatorii ar trebui să vadă toate intrările clientului ca nefiind de încredere și să le valideze, indiferent dacă provin de la utilizatori sau de la aplicație.

M8: Riscuri de falsificare a codului

De obicei, în acest caz, un atacator exploatează modificarea codului prin intermediul unor forme rău intenționate ale aplicațiilor găzduite în magazinele de aplicații terță parte. De asemenea, ar putea păcăli utilizatorii să instaleze o aplicație prin atacuri de tip phishing.

Cele mai bune practici de evitat:

• Dezvoltatorii trebuie să se asigure că aplicația este capabilă să detecteze modificările codului în timpul rulării.
• Fișierul build.prop trebuie verificat pentru prezența ROM-ului neoficial în Android și pentru a afla dacă dispozitivul este rootat.
• Dezvoltatorul trebuie să utilizeze sume de control și să evalueze semnăturile digitale pentru a vedea dacă a avut loc manipularea fișierelor.
• Codificatorul se poate asigura că cheile aplicației, codul și datele sunt eliminate odată ce este găsită manipularea.

M9: Risc de inginerie inversă

Un atacator descarcă de obicei aplicația vizată din magazinul de aplicații și o analizează în mediul local cu o suită de instrumente diferite. După care, ei pot schimba codul și pot face ca aplicația să funcționeze diferit.

Caz din lumea reală :

Pokemon Go s-a confruntat recent cu privirile de încălcare a securității când s-a constatat că utilizatorii au făcut o inginerie inversă a aplicației pentru a cunoaște vecinătatea Pokemonilor și a-i prinde în câteva minute.

Cele mai bune practici de evitat:

• Cel mai bun mod de a proteja o aplicație împotriva riscului, conform securității mobile OWASP , este să folosești aceleași instrumente pe care le-ar folosi hackerii pentru inginerie inversă.
• Dezvoltatorul trebuie, de asemenea, să înfunde codul sursă, astfel încât să devină dificil de citit și apoi să facă inginerie inversă.

M10: Risc de funcționalitate străină

De obicei, un hacker se uită la funcționalitățile străine din interiorul unei aplicații mobile pentru a descoperi funcționalitățile ascunse în sistemele backend. Atacatorul ar exploata funcționalități străine din propriile sisteme fără nicio implicare a utilizatorilor finali.

Caz din lumea reală :

Ideea aplicației Wifi File Transfer a fost să deschidă portul pe Android și să permită conexiuni de la computer. Problema ? O absență a autentificării, cum ar fi parolele, adică oricine se poate conecta la un dispozitiv și poate obține accesul complet al acestuia.

Cele mai bune practici de evitat:

• Asigurați-vă că nu există cod de testare în versiunea finală
• Asigurați-vă că nu există un comutator ascuns în setările de configurare
• Jurnalele nu trebuie să conțină nicio descriere a procesului serverului backend
• Asigurați-vă că toate jurnalele de sistem nu sunt expuse la aplicații de către OEM
• Punctele finale API trebuie să fie bine documentate.