Dacă sunteți un dezvoltator ocupat, acest articol va fi un bun punct de plecare pentru construirea unei arhitecturi de aplicații sigure.

Dezvoltatorii de astăzi ajung să se concentreze mai mult pe construirea de software decât au putut în trecut, iar acesta este un lucru grozav.

Profităm de cultura producătorilor, de o atitudine de „livrare întotdeauna”, de colaborare open source și de o mulțime de aplicații care ne ajută să prioritizăm și să executăm cu eficiență maximă.

Ne aflăm într-un mediu de creație constantă, în care atât echipele, cât și antreprenorii solo pot fi la maximum de productivi.

Dar, uneori, această productivitate cu viteză mare își arată dezavantajele.

Pe măsură ce aflu mai multe despre cele mai bune practici de securitate, nu pot să nu văd din ce în ce mai multe aplicații care nu au niciun indiciu. Dezvoltatorii lor par să aibă o lipsă generală de conștientizare a securității. Acest lucru duce la lipsa prioritizării sarcinilor care nu acceptă direct lansarea produsului.

Piața pare să fi făcut mai importantă lansarea unui produs utilizabil decât unul sigur. Atitudinea predominantă este: „putem face lucrurile de securitate mai târziu”.

Construirea unei fundații bazată mai degrabă pe oportunitate decât pe longevitate este o modalitate proastă de a construi aplicații. Este o modalitate excelentă de a crea datorii de securitate.

ad-banner

Datoria de securitate, ca și datoria tehnică, se acumulează atunci când dezvoltatorii iau decizii (de obicei pripite) care pot face mai dificilă securizarea aplicației ulterior.

Dacă sunteți familiarizat cu conceptul de „împingere la stânga” (sau dacă ați citit-o articol despre expunerea la date sensibile), veți ști că, atunci când vine vorba de securitate, uneori nu există o versiune a „mai târziu” care să nu fie de asemenea târziu.

Este păcat, deoarece urmărirea unor practici de securitate de bază cu randament ridicat al beneficiilor la începutul procesului de dezvoltare nu necesită mult mai mult timp nu urmarindu-i. Adesea, se reduce la a avea cunoștințe de bază, dar importante, care vă ajută să luați o decizie mai sigură.

În timp ce arhitectura aplicației variază foarte mult, există câteva principii de bază pe care le puteți aplica. Acest articol vă va oferi o imagine de ansamblu la nivel înalt a acestor zone și vă va indica în direcția corectă.

Trebuie să existe un motiv pentru care o numim aplicație „arhitectură”. Îmi place să cred că arhitectura software-ului este similară în unele moduri de bază cu arhitectura unei clădiri. (Sau cel puțin, în expertiza mea absolută zero în crearea de clădiri, cum îmi imaginez o clădire destul de utilitară.)

Iată cum îmi place să rezum trei puncte de bază ale construirii unei arhitecturi de aplicații sigure:

  1. Depozitare separată
  2. Configurare personalizată
  3. Acces controlat și sfera utilizatorului

Acesta este doar un punct de săritură menit să ne facă să începem cu piciorul drept. O imagine completă a posturii de securitate a unei aplicații complet realizate include zone aflate în afara sferei de aplicare a acestei postări, inclusiv autentificarea, înregistrarea și monitorizarea, integrarea și, uneori, conformitatea.

1. Depozitare separată

Din punct de vedere al securității, conceptul de separare se referă la stocarea fișierelor care servesc scopuri diferite în locuri diferite.

Când construiți o clădire și decideți unde merg toate camerele, creați holul de la parter. Birourile administrative merg la etajele superioare, de obicei în afara căii principale. În timp ce atât holul, cât și birourile sunt camere, înțelegeți că acestea au scopuri diferite. Au, de asemenea, nevoi funcționale diferite și cerințe de securitate foarte diferite.

Cum sa asigurati securitatea arhitecturii aplicatiei dvs chiar acum separare

Când vine vorba de fișierele dvs., beneficiul este poate cel mai ușor de înțeles dacă aveți în vedere o structură simplă de fișiere:

application/
 ├───html/
 │   └───index.html
 ├───assets/
 │   ├───images/
 │   │   ├───rainbows.jpg
 │   │   └───unicorns.jpg
 │   └───style.css
 └───super-secret-configurations/
     └───master-keys.txt

În acest exemplu simplificat, să presupunem că toate imaginile aplicației dvs. sunt stocate în application/assets/images/ director. Când unul dintre utilizatorii dvs. creează un profil și își încarcă imaginea în el, această imagine este stocată și în acest folder. Are sens, nu? Este o imagine și acolo merg imaginile. Care-i problema?

Dacă sunteți familiarizat cu navigarea unei structuri de fișiere într-un terminal, este posibil să fi văzut această sintaxă înainte: ../../. Cele două puncte sunt un mod la îndemână de a spune „mergi într-un director”. Dacă executați comanda cd ../../ în images/ directorul structurii simple a fișierelor de mai sus, în care ați merge assets/, apoi din nou la directorul rădăcină, application/. Aceasta este o problemă din cauza unei mici vulnerabilități dublate traversarea căii.

În timp ce sintaxa punctelor economisește o anumită tastare, introduce și avantajul interesant de a nu fi nevoie să știi cum se numește directorul părinte pentru a merge la el.

Luați în considerare un script de încărcare utilă de atac, livrat în images/ dosar al acestei aplicații nesigure, care a crescut într-un director folosind cd ../ și apoi a trimis tot ce a găsit atacatorului, în repetate rânduri. În cele din urmă, va ajunge în directorul aplicației rădăcină și ar accesa fișierul super-secret-configurations/ pliant. Nu e bine.

În timp ce ar trebui să existe alte măsuri pentru a preveni traversarea căii și vulnerabilitățile legate de încărcarea utilizatorilor, cea mai simplă prevenire este de departe separarea stocării. Fișierele și activele de bază ale aplicației nu ar trebui să se amestece cu alte date și, mai ales, nu cu introducerea utilizatorului. Cel mai bine este să păstrați fișierele încărcate de utilizator și jurnalele de activitate (care pot conține date suculente și pot fi vulnerabile la atacuri de injecție) separate de aplicația principală.

Puteți realiza separarea utilizând un server diferit, o instanță diferită, o gamă de IP separată sau un domeniu separat.

2. Configurare personalizată

Deși pierderea timpului la personalizare poate împiedica productivitatea, un domeniu pe care doriți să îl personalizați este setările de configurare.

Configurarea greșită a securității este listat în topul OWASP 10. Un număr semnificativ de incidente de securitate au loc deoarece un server, firewall sau cont administrativ rulează în producție cu setări implicite. La deschiderea noii clădiri, sperăm că veți fi mai atenți să vă asigurați că nu ați lăsat nicio cheie în încuietori.

1611523268 536 Cum sa asigurati securitatea arhitecturii aplicatiei dvs chiar acum separare

De obicei, victimele atacurilor legate de setările implicite nu sunt vizate în mod specific. În schimb, acestea se găsesc prin instrumente de scanare automată, pe care atacatorii le trec peste multe ținte posibile. Acești atacatori testează multe sisteme diferite pentru a vedea dacă se răstoarnă și expun un exploit util.

Natura automatizată a acestui atac înseamnă că este important să revizuiți setările pentru fiecare parte a arhitecturii. Chiar dacă o piesă individuală nu pare semnificativă, aceasta poate oferi o vulnerabilitate care oferă unui atacator o poartă către aplicație.

În special, examinați componentele arhitecturii pentru zonele nesupravegheate, cum ar fi:

  • Conturile implicite, în special cu parolele implicite, rămase în funcțiune;
  • Exemple de pagini web, aplicații tutoriale sau eșantion de date rămase în aplicație;
  • Porturile inutile rămase în funcțiune sau porturile lăsate deschise către Internet;
  • Metode HTTP permise fără restricții;
  • Informații sensibile stocate în jurnale automate;
  • Permisiuni configurate implicit în serviciile gestionate; și,
  • Listele de directoare sau tipurile de fișiere sensibile, lăsate accesibile în mod implicit.

Această listă nu este exhaustivă. Componentele specifice arhitecturii, cum ar fi stocarea în cloud sau serverele web, vor avea alte caracteristici configurabile de revizuit. În general, reduceți suprafața de atac a aplicației utilizând componente minime de arhitectură. Dacă utilizați mai puține componente sau nu instalați module de care nu aveți nevoie, veți avea mai puține puncte posibile de intrare în atac pentru a le configura și proteja.

3. Acces controlat și domeniul de aplicare al utilizatorului

Una dintre cele mai dificile probleme de securitate de testat într-o aplicație este controlul accesului configurat greșit. Instrumentele de testare automată au capacitate limitată de a găsi zone ale unei aplicații la care un utilizator nu ar trebui să poată accesa. Acest lucru este adesea lăsat la dispoziția testării manuale sau a revizuirii codului sursă.

Dezvoltatorii pot reduce riscul ca acest lucru să devină o problemă greu de remediat mai târziu. Luați în considerare această vulnerabilitate la începutul ciclului de viață al dezvoltării software-ului, atunci când se iau decizii arhitecturale. La urma urmei, nu v-ați lăsa pur și simplu cheile stăpânești la îndemână pe o margine înaltă și sperați că nimeni nu va veni împreună cu o scară.

1611523268 899 Cum sa asigurati securitatea arhitecturii aplicatiei dvs chiar acum separare

Controlul accesului întrerupt se află în Top 10 OWASP, care intră mai în detaliu asupra diferitelor sale forme. Ca un exemplu simplu, luați în considerare o aplicație cu două niveluri de acces: administratori și utilizatori. Dezvoltatorii doresc să construiască o nouă caracteristică – capacitatea de a modera sau interzice utilizatorii – cu intenția ca numai administratorilor să li se permită să o folosească.

Dacă sunteți conștient de posibile vulnerabilități de control al accesului, puteți decide să creați caracteristica de moderare într-o zonă separată de spațiul accesibil utilizatorului. Aceasta poate fi pe un domeniu diferit sau ca parte a unui model pe care utilizatorii nu îl partajează. Acest lucru reduce riscul ca o configurare greșită a controlului accesului sau o creștere a vulnerabilității privilegiului să permită unui utilizator să acceseze în mod necorespunzător caracteristica de moderare ulterior.

Desigur, un control robust al accesului în aplicația dvs. are nevoie de mai mult sprijin pentru a fi eficient. Luați în considerare factori precum jetoanele sensibile sau cheile transmise ca parametri URL sau dacă un control eșuează în siguranță sau nesigur. Chiar și așa, luând în considerare autorizarea în etapa arhitecturală, vă veți pregăti pentru a face mai ușoare întăririle.

Bazele securității pentru un beneficiu maxim

Dezvoltatorii evită acumularea datoriilor tehnice alegând un cadru bine verificat. În mod similar, dezvoltatorii evită datoriile de securitate, devenind conștienți de vulnerabilitățile comune și de deciziile arhitecturale care le pot ajuta să le atenueze. Pentru o resursă mult mai detaliată despre cum să încorporați securitatea în aplicații de la început, Standardul de verificare a securității aplicației OWASP este un ghid robust.