INTRODUCERE ÎN

SECURITATEA
APLICAȚIILOR
WEB
Autor: N.Pleșca, lector univ.
CONȚINUT

■ Definirea noțiunilor.
■ Riscurile asociate aplicațiilor web.
■ Provocările comune cu care se confruntă o organizație în procesul
asigurării securității aplicațiilor, accesibile prin intermediul interfețelor
web.
■ Principii recomandate a fi respectate în procesul dezvoltării aplicațiilor
web securizate într-un mod rentabil pentru organizații.
ORGANIZAȚIILE ȘI WEB-ul
■ Aplicațiile Web sunt site-uri web dinamice care conțin elemente de programare
pe partea server și care oferă funcționalități pentru a interacționa cu utilizatorii,
pentru conectarea la baze de date pe back-end și generarea de conținuturi web
(rezultate), de cele mai multe ori în mod dinamic pentru browsere (clienți)
■ Astăzi, activitatea oricărei organizații nu poate fi realizată fără folosirea de către
aceasta a aplicațiilor web, implementate în diverse procese de activitate: site-uri
de prezentare, magazine electronice, sisteme bancare de deservire la distanță
(internet banking), sisteme informatice de evidență a vânzărilor, a comenzilor etc.
■ Multiple aplicații corporative sau sisteme informatice de evidență, care până nu
demult erau utilizate ca și aplicații-desktop, în ultimul timp, prin modernizare,
utilizează tehnologiile web
IMPORTANȚA SECURIZĂRII
APLICAȚIILOR WEB
■ Aplicațiile web au un rol tot mai mare și mai mare în activitatea
oricărei organizații, însă există și un alt aspect al exploatării
aplicațiilor web - compromiterea aplicației poate conduce la
aceea că
– clienții își pot pierde încredearea în organizație sau
– organizația va pierde o parte din clienții săi sau
– organizația va avea multiple pierderi financiare directe sau
indirecte (pentru recuperarea și restabilirea resurselor
vandalizate)
■ Anume din aceste motive dezvoltarea unei aplicații securizate
are o importanță considerabilă, alături de obiectivul de a
dezvolta o aplicație web funcțională
SECURITATEA APLICAȚIILOR WEB
■ Securitatea aplicațiilor web reprezintă o ramură a securității informaționale,
care se ocupă, în special, de securitatea site-urilor, aplicațiilor și serviciilor web
■ La nivel înalt, securitatea aplicațiilor web se bazează pe principiile securității
aplicațiilor, însă aceste principii sunt aplicate în mod specific Sistemelor Informatice
și aplicațiilor, accesibile utilizatorilor prin intermediul interfețelor web
■ La începutul anilor 2000, odată cu apariția la web 2.0, ce are drept caracteristică de
bază implicarea utilizatorului la construirea și/sau modficarea conținuturilor web
(exemplu sistemele de socializare), sporește schimbul de informații prin intermediul
rețelelor de calculatoare
■ Crește mult numărul serviciilor și a afacerilor gestionate prin intermediul web-ului.
Din acest motiv, hackerii încearcă tot mai frecvent să compromită resursele digitale
și rețelele corporative
DEFINIREA NOȚIUNII
■ Securitatea aplicațiilor include măsurile luate pentru a îmbunătăți securitatea
acesteia, prin găsirea, stabilirea și prevenirea vulnerabilităților de securitate
– Diferite tehnici sunt folosite pentru a preîntâmpina aceste vulnerabilități de
securitate în cadrul diferitor etape ale ciclului de viață al aplicațiilor
■ O vulnerabilitate este un neajuns al aplicației, care apare ca rezultat al unui defect
de proiectare sau a unui bug de realizare
■ Vulnerabilitatea îi permite unui atacator să dăuneze părților interesate în utilizarea
unei aplicații. Părțile interesate includ proprietarul aplicației, utilizatorii de
aplicației și alți actori care folosesc aplicația
■ Termenul "vulnerabilitate" este folosit rar. Cu toate acestea, în acest context se
includ notiunile: „amenințări”, „atacuri” și ”contramăsuri” întreprinse pentru
combaterea vulnerabilităților
EXEMPLE DE VULNERABILITĂȚI
■ Lipsa validării datelor de intrare ale utilizatorilor
■ Lipsa unui mecanism suficient de logare și de înregistrare a accesărilor aplicației
■ Prelucrarea necorespunzătoare a erorilor
■ Nu se închide corect conexiunea cu baza de date...etc.
■ În urma rezultatelor obținute în 2015, ca și lider absolut poate fi menționată vulnerabilitatea ce permite
atacul cross-site scripting. Ca rezultat al unui astfel de atac atacatorul poate, de exemplu, să acceseze
contul personal al utilizatorului și să efectueze tranzacții frauduloase. Această vulnerabilitate a fost
detectată în 80% din aplicațiile analizate de specialiștii. O altă vulnerabilitate – divulgarea de informații
sensibile, a căror risc este prezent în 50% din aplicațiile analizate. Un alt atac este includerea entităților
externe în XML și este caracteristic pentru 40% din aplicațiile analizate. Acesta din urmă, de altfel, face
posibilă punerea în aplicare a unei game largi de amenințări până la controlul complet al serverului atacat.
– In total, mai mult de 70% din toate aplicațiile analizate au în conținut vulnerabilități cu nivel de
risc ridicat (sursă: Rusia)
■ Mai multe delatii pot fi accesate https://www.owasp.org/index.php/Top_10-2017_Top_10
OPEN WEB APPLICATION SECURITY
PROJECT
■ Pentru a îmbunătăți securitatea aplicațiilor web, a fost creată o comunitate
internațională numită Open Web Application Security Project (OWASP), care
are drept scop coordonarea eforturilor la nivel mondial și reducerii riscurilor
asociate aplicațiilor web
■ OWASP este un proiect deschis, pentru asigurarea securității aplicațiilor WEB,
care include corporații, organizații educaționale și dezvoltatori individuali, care
împreună editează articole, recomandări și tutoriale disponibile în mod liber
pentru dezvoltarea aplicațiilor WEB securizate. Proiectul include, de asemenea,
o serie de instrumente de instruire pentru a analiza securitatea aplicațiilor WEB
RISCURILE CARE AMENINȚĂ
SECURITATEA APLICAȚIILOR WEB
■ Atacatorii pot folosi mai multe căi, de penetrare a aplicației web pentru a face rău
afacerii sau organizației
■ Fiecare din aceste căi reprezintă un risc care poate fi suficient de grav pentru a atrage
atenția dezvoltatorilor aplicației web
■ Uneori aceste căi sunt ușor de găsit și folosit de atacatori, iar alteori – mai dificil. În mod
similar, prejudiciul cauzat de producerea acestor riscuri poate să nu aibă consecințe
majore sau alteori poate duce la distrugerea businessului
■ Pentru determinarea riscului unei organizații, se poate evalua probabilitatea producerii
acestuia, care depinde de sursa de amenințare, de vectorul atacului și vulnerabilitatea de
securitate depistată, combinată cu o estimare a impactului tehnic și de business asupra
organizației. Împreună, toți acești factori, determină riscul global ce ameninta aplicatia
FACTORII CARE INFLUIENȚEAZĂ
RISCUL
VULNERABILITĂȚI vs RISCURI
■ Descoperirea vulnerabilităților este importantă, însă evaluarea riscurilor
asociate businessului este la fel de importantă
– La începutul ciclului de viață, se pot identifica problemele legate de
securitatea arhitecturii sau proiectare, utilizând modelarea amenințărilor. Mai
târziu, pot fi găsite problemele legate de securitate utilizând revizuirea
codului sau testarea penetrării. Sau problemele pot să nu fie descoperite până
când aplicația nu va fi lansată în producție și atunci va fi compromisă
■ Riscul poate fi evaluat folosind formula: Risc = Probabilitate * Impact
– Conform OWASP probabilitatea ia valori de la 0 la 9
 CICLUL DEZVOLTĂRII UNEI APLICAȚII
WEB SECURIZATE
■ Majoritatea dezvoltatorilor de resurse web nu respectă
recomandările de asigurare a securizării aplicației în cadrul fiecărei
etape ale ciclului de viață a aplicației (secure software development
lifecycle), și ca rezultat obțin și exploatează aplicații web ce conțin
vulnerabilități care puteau fi evitate în cadrul etapelor de început ale
ciclului de viață. Prezența acestor vulnerabilități reprezintă ”ușițe”
de acces pentru răuvoitori la datele aplicației – uneori private, sau
alte resurse informaționale
■ Tocmai deaceea, același proiect OWASP, recomandă evaluarea
securității aplicației în cadrul fiecărei etape a ciclului de viață.
Adică, recomandă ca testarea să se facă în cadrul fiecărei etape și nu
doar după etapa de realizare, astfel existând posibilitatea corectării
proceselor de activitate, nealocând cheltuieli suplimentare pentru
înlăturarea riscurilor
■ Testarea reprezintă procesul de verificare a stării unui sistem sau
aplicații conform unui set de criterii
1. Etapa care precede dezvoltarea
1.1. Definirea ciclului de viață - înainte de începerea dezvoltării aplicației, trebuie să se definească un
ciclu de viață adecvat, în care asigurarea securității să fie inevitabilă în fiecare etapă.
1.2. Revederea politicilor și standardelor – necesitatea asigurării că există politici, standarde și
documentație corespunzătoare pentru a fi urmată în procesul dezvoltării. Documentația este extrem de
importantă, deoarece oferă orientări și politici echipelor de dezvoltare.
– ”Oamenii pot face ceea ce trebuie, doar dacă știu ce este bine să facă”.
– Dacă aplicația trebuie dezvoltată în Java, de exemplu, este esențial să existe un standard de
codificare securizat Java. Dacă este formulată cerința de a cripta datele, este esențial să
existe un standard de criptare
– Nici o politică sau standard nu poate acoperi toate situațiile cu care se va confrunta echipa
de dezvoltare. Prin documentarea problemelor comune și previzibile, vor exista mai puține
situații în care echipa va trebui să ia decizii singură în timpul procesului de dezvoltare.
1.3. Dezvoltarea criteriilor de măsurare (metrici) pentru asigurarea trasabilității - înainte de începerea
dezvoltării, este necesară planificarea programului de măsurare. Prin definirea criteriilor de măsurare,
se va asigura vizibilitatea defectelor, atât în procese cât și în produsul dezvoltat
 2. Specificarea cerințelor și proiectarea
soluției
2.1. Revizuirea cerințelor de securitate - cerințele de securitate definesc modul în care o aplicație
funcționează din perspectiva securizării. Este esențial ca cerințele de securitate să fie testate. Testarea în
acest caz înseamnă testarea ipotezelor făcute în cerințe și teste, pentru a vedea dacă există lacune la
definirea cerințelor. De exemplu, dacă există o cerință de securitate conform căreia utilizatorii trebuie să
fie înregistrați, înainte ca aceștia să poată avea acces la secțiunea de gestiune a site-ului web, aceasta ar
însemna că utilizatorul trebuie preventiv să se înregistreze în sistem sau că trebuie doar să se autentifice?
Ar fi bine ca cerințele să fie formulate clar și să nu existe mai multe interpretări ale lor.
La căutarea lacunelor în formularea cerințelor ar fi bine să se precaute mecanisme de securitate precum:
■ Managementul utilizatorilor și a acțiunilor acestora
■ Autentificarea utilizatorului
■ Autorizarea utilizatorului
■ Confidențialitatea datelor
■ Integritatea datelor
■ Managementul sesiunilor
■ Securitatea transportării datelor
■ Metodele de separare a subsistemelor
■ Legislația și conformitatea standardelor (inclusiv cele de confidențialitate etc.)
2. Specificarea cerințelor și proiectarea
soluției
2.2. Proiectarea arhitecturii - aplicațiile trebuie să aibă design-ul arhitecturii bine
documentat. Această documentație poate include modele, documente textuale și alte
artefacte similare. Este esențial ca aceste artefacte să fie testate pentru asigurarea că
designul arhitecturii impune nivelul adecvat de securitate, așa cum a fost definit în cerințe.
Identificarea fluxurilor de securitate în faza de proiectare nu este doar unul dintre
momentele cele mai rentabile pentru a identifica defectele, ci poate fi unul dintre
momentele cele mai eficiente pentru a face schimbările necesare. De exemplu, dacă se
constată că proiectul solicită autorizarea acțiunilor în mai multe locuri, ar putea fi oportună
examinarea unei componente centrale de autorizare. Dacă aplicația efectuează validarea
datelor în mai multe locuri, ar putea fi adecvată elaborarea unui modul de validare
centralizată (de exemplu, implementarea validării intrărilor de date într-un singur loc, și nu
în zeci de locuri, este mult mai ieftină). Dacă sunt descoperite vulnerabilități, ar trebui să fie
transmise proiectantului arhitecturii sistemului pentru soluții alternative.
2. Specificarea cerințelor și proiectarea
soluției
2.3. Crearea și analiza modelelor UML – după proiectarea arhitecturii, trebuie construite
modele UML (Unified Modeling Language) care descriu modul în care funcționează aplicația.
În unele cazuri, acestea pot fi deja disponibile. Aceste modele trebuie să fie utilizate pentru ca
designerii să confirme cât mai exact modul în care funcționează aplicația. Dacă sunt
descoperite deficiențe, ar trebui să fie prezentate proiectantului de sistem pentru elaborarea de
soluții alternative.
2.4. Crearea și examinarea modelelor pentru riscurile care amenință aplicația – având la
dispoziție soluțiile de proiectare arhitecturală, modelele UML - care explică exact cum
funcționează sistemul, se recomandă să fie elaborat un model al riscurilor care amenință
aplicația. Trebuie dezvoltate scenarii realiste de evitare a amenințărilor. Trebuie analizate
modelele de proiectare și arhitectura pentru asigurarea că aceste amenințări au fost atenuate,
acceptate de întreprindere sau atribuite unei terțe părți, cum ar fi o firmă de asigurări. Atunci
când amenințările identificate nu au strategii de atenuare, trebuie revizuite modelele de
proiectare și arhitectura împreună cu arhitectul sistemului pentru a modifica modelele.
3. Realizarea aplicației
Teoretic, realizarea este implementarea unor modele de proiectare. Cu toate acestea, în
lumea reală, multe decizii referitoare la modelele de proiectare se fac în timpul realizării
codului. Acestea sunt adesea decizii mai mici, fie prea detaliate pentru a fi descrise în cadrul
etapei de proiectare, fie probleme în soluționarea cărora nu a fost folosit nici un standard.
Dacă modelele de proiectare și arhitectură nu sunt adecvate, dezvoltatorul va fi nevoit să ia
multe decizii în mod independent. Dacă există politici și standarde insuficiente,
dezvoltatorul se va confrunta cu situația de a lua decizii și mai multe.
3.1. Parcurgerea codului - echipa de securizare ar trebui să perfecționeze codul,
parcurgându-l împreună cu dezvoltatorii, iar în unele cazuri, cu arhitecții de sistem. O
parcurgere a codului este o parcurgere la nivel înalt în cadrul căreia dezvoltatorii să explice
logica și fluxul codului implementat. Aceasta permite echipei de revizuire a codului să
obțină o înțelegere generală a codului și permite dezvoltatorilor să explice de ce anumite
lucruri au fost dezvoltate așa și nu altfel. Scopul nu este de a efectua o revizuire a codului,
ci de a înțelege la un nivel înalt fluxul, aspectul și structura codului care alcătuiesc aplicația.
3. Realizarea aplicației
3.2. Revizuirea codului – după înțelegerea structurării codului și de ce anumite lucruri au fost
codificate așa cum au fost, testerul poate examina codul actual pentru depistarea defectelor de
securitate. Verificările statice validează codul în raport cu un set de liste de verificare, inclusiv:
■ Cerințe privind disponibilitatea, confidențialitatea și integritatea;
■ Ghidul OWASP sau Top 10 pentru expunerile tehnice (în funcție de profunzimea revizuirii);
■ Probleme specifice referitoare la limbajul sau frameworkul utilizat, cum ar fi listele de verificare
PHP sau ”Microsoft Secure Coding” pentru ASP.NET;
■ Orice cerințe specifice industriei producătoare de software, cum ar fi recomandările  Sarbanes-
Oxley 404, COPPA, ISO/IEC 27002, APRA, HIPAA, Visa Merchant etc.
În ceea ce privește rentabilitatea resurselor investite (în cea mai mare parte resursa timpului), analiza
statică a codului (white-box testing) produce randamente mult mai mari decât orice altă metodă de
revizuire a securității și se bazează cel mai puțin pe abilitățile testerului. Cu toate acestea, această
metodă de testare nu este ideală și codul ar trebui testat, sub aspectul securității, utilizând și alte
metode de testare mai complete
(http://softwaretestingfundamentals.com/white-box-testing/)
4. Implementarea aplicației
4.1. Testarea posibilităților de penetrare a aplicațiilor - după testarea cerințelor,
analizei modelelor și revizuirii codului, s-ar putea presupune că au fost captate toate
problemele. Testarea aplicației după ce aceasta a fost instalată oferă o ultimă
verificare pentru certitudinea că aplicația este complet funcțională.
4.2. Testarea managementului configurației - testul de penetrare a aplicațiilor ar
trebui să includă verificarea modului în care a fost implementată și securizată
aplicația. În timp ce aplicația poate fi securizată, configurația ar putea fi încă
vulnerabilă la exploatare.
5. Întreținerea
5.1. Elaborarea recenziilor de management operațional - un proces care să detalieze
modul în care este gestionată atât partea operațională a aplicației, cât și cea a
infrastructurii.
5.2. Efectuarea controalelor periodice de robustețe a aplicației - verificările lunare
sau trimestriale ar trebui să fie efectuate atât pe aplicație, cât și pe infrastructură,
pentru asigurarea că nu au fost introduse riscuri noi de securitate și că nivelul de
securitate este încă intact.
5.3. Asigurarea verificării schimbării - după ce fiecare schimbare a fost aprobată și
testată, asigurând calitatea, este esențial ca modificarea să fie verificată pentru
asigurarea că nivelul de securitate nu a fost afectat de schimbarea realizată.
CONCLUZII

■ Activitățile specifice securizarii aplicatiilor web, în procesul dezvoltării

aplicațiilor web ar trebui distribuite de-a lungul întregului ciclu de viață

■ Se recomandă să se țină cont de recomandările companiei OWASP sau

alte recomandări și standarde internaționale și naționale

■ Astfel vor fi dezvoltate aplicații web funcționale, securizate și sigure 