Aspecte legate de securitatea aplicaiilor web

Pe parcursul ultimilor ani, aplicaiile web au avut parte de o dezvoltare uluitoare, odat cu
intrarea n era Web 2.0 i dezvoltarea conceptului de cloud computing. Acest fenomen a fost
sprijinit de inovaiile tehnologice din domeniu, prin care paginile web n care erau afi ate mai
nainte informaii statice au devenit pagini dinamice, interactive ce permit un nivel de
interaciune ridicat al utilizatorului cu aplicaia web.
Dezvoltarea exploziv a creat de asemenea premisa apariiei vulnerabilitilor specifice
domeniului web, iar numrul acestora este n continu cretere dei cele mai populare atacuri au
la baz tot vulnerabiliti identificate pentru prima dat cu ani n urm. Aceast lucrare va face o
scurt trecere prin cele mai comune tipuri de vulnerabiliti specifice aplicaiilor web ([Cert12]):
a. SQL Injection
b. Cross-site Scripting (XSS)
c. Mesaje de erori prea detaliate (verbose errors)
d. Eludarea restriciilor de autentificare (authentication bypass)
e. Eludarea restriciilor de autorizare (authorization bypass)
f. Erori Logice
g. Diseminarea codului surs
a. SQL Injection (Injectarea de cod SQL).
Cea mai mare parte a aplicaiilor web existente n prezent folosesc baze de date pentru a
stoca datele necesare. SQL reprezint un standard internaional pentru regulile i sintaxa
comenzilor ce pot fi transmise unui sistem de gestiune a bazelor de date (SGBD), pentru
prelucrarea datelor stocate. Printre cele mai populare SGBD-uri la ora actual se numr
MySQL, PostgreSQL, Microsoft SQL Server, Oracle.
Un atac de tip SQL Injection apare n momentul n care un atacator are posibilitatea de a
introduce orice fel de date ntr-o interogare SQL folosit pentru accesarea bazei de date sau
atunci cnd se poate introduce (injecta) n locul datelor o sintax prin care logica declaraiei s
fie modificat astfel nct s execute o aciune diferit dect cea pentru care fusese destinat.
Acest tip de atac poate avea consecine grave, de la aflarea datelor cu caracter personal pn la
tergerea ntregii baze de date din spatele aplicaiei i, n ciuda pericolului pe care l reprezint,
este cea mai frecvent ntlnit vulnerabilitate n rndul aplicaiilor web ([Cert12]).
Urmtorul exemplu, prezentat n tabelul 4.1.1, prezint codul unei funcii de autentificare
care cere ca parametri numele i parola utilizatorului ce dorete s se logheze ntr-o aplicaie.
Deoarece datele de intrare pe care utilizatorul le va furniza (numele, respectiv parola sa) nu sunt
validate, adic nu se verific dac ntr-adevr s-a introdus un nume i o parol valide de
utilizator, apare posibilitatea inserrii de cod SQL. Prin introducerea sintaxei de Mihai OR
1=1 n cmpul destinat numelui utilizatorului, atacatorul modific complet sensul interogrii
SQL care va ocoli mecanismul de autentificare prin care se verific parola i atacatorul se va loga
pe contul Mihai dei nu a introdus nicio parol, condiia 1=1 fiind ntotdeauna adevrat.

1 din 8

Prototipul funciei ce interogheaz Baza de <?php

function autentificare($user, $parola)
date
{
$sql=SELECT * FROM users WHERE
username=$user and parola =$parola;
Return mysql_query($sql);
..
}
?>
Datele introduse de atacator pentru Mihai OR 1=1
parametrul destinat numelui de utilizator
Transformarea care are loc asupra $sql=SELECT * FROM users WHERE
username=Mihai OR 1=1;
interogrii SQL dup introducerea datelor
Tabel 4.1.1: Exemplu SQL Injection

Cea mai bun modalitate de aprare mpotriva atacurilor de tip SQL Injection este cea de
a implementa funcii puternice de validare a datelor de intrare, naintea executrii interogrii
asupra bazei de date, astfel nct un utilizator ru voitor s nu poat introduce alte date dect cele
necesare aplicaiei. Msurile specifice care pot fi implementate n acest scop sunt urmtoarele
([Cert12]):
- Folosirea variabilelor bine definite i de definiii ale coloanelor bazei de date stocarea i manipularea numerelor ca i numere ntregi sau alte tipuri de numerice
potrivite, limitarea coninutului irurilor de caractere doar la caractere alfanumerice i
respingerea semnelor de punctuaie sau a caracterelor specifice sintaxei SQL ( , $, =, <, >
etc.) ([Cert12]).
- Atribuirea rezultatelor obinute n urma interogrii unei variabile bine definite
spre exemplu, dac aplicaia cere o valoare numeric din baza de date, aceasta trebuie
atribuit unei variabile de tip numeric, lucru care va impiedica atacatorii s extrag
informaii din baza de date (dac variabila ce urmeaz a fi afiat n browser nu accept
dect numere ntregi, atunci obinerea i afiarea unui nume sau a unei date calendaristice
sau a oricrui alt tip de date nu va fi posibil) ([Cert12]).
- Limitarea lungimii datelor irurile de caractere ar trebui ideal limitate la o lungime
potrivit scopului lor. Spre exemplu, un nume de utilizator nu ar trebui stocat ntr-un ir
care are lungimea de 200 de caractere. Limitarea numrului de caractere poate mpiedica
eficient succesul unei injecii SQL, deoarece reduce lungimea irului de caractere pe care
atacatorul il poate injecta n cod ([Cert12]).
- Evitarea concatenrii irului de caractere n interogri concatenarea irurilor de
caractere, unde interogarea este format direct din datele furnizate de utilizatori (ex:
SELECT * from nume_tabel WHERE + variabila_sir, unde variabila_sir este un ir de
caractere dat de utilizator) are cea mai mare rat de succes la atacurile SQL Injection. De
aceea, se recomand folosirea unei funcii view sau proceduri care s opereze asupra
variabilelor furnizate i care s genereze o eroare la introducerea unor date incorecte,
astfel nct s nu permit atacatorului s manipuleze ntreaga interogare ([Cert12]).
- Aplicarea separrii datelor i accesul pe baz de roluri n interiorul bazei de date o
aplicaie web ar trebui s foloseasc un cont care are privilegii de acces doar pentru
tabelele necesare funciilor atribuite utilizatorului respectiv. Tabelele interne ale bazei de

2 din 8

date, mai ales cele legate de managementul conturilor i variabilele sistemului nu ar

trebui s fie accesibile utilizatorilor obinuii ai aplicaiei ([Cert12]).
b. Cross-Site Scripting (XSS)
Aceast metod folosit de ctre atacatori reprezint o tehnic de forare asupra paginii
web de a afia un cod maliios (de regul scris n limbaj HTML, JavaScript, Flash sau ActiveX)
i de a-l executa ulterior n browser-ul utilizatorului. inta atacului nu este serverul site-ului web,
ci acesta are rolul de gazd pentru codul maliios, adevrata int a atacului fiind utilizatorul
aplicaiei. Atacatorul folosete site-ul pentru transmiterea codului malware care, odat executat
n browserul utilizatorului, i va permite sa fure diverse date: conturi, date, conturi bancare,
nregistrri din istoricul browser-ului etc.
Modalitile prin care un cod maliios poate deveni rezident ntr-o pagin web sunt
urmtoarele ([Cert12]):
- Este ncrcat n mod intenionat de ctre propietarul paginii web;
- Este injectat de ctre un atacator n seciunea public a unui site profitnd de anumite
vulnerabiliti ale acesteia;
Pagina web poate primi un deface printr-o vulnerabilitate a reelei sau a straturilor sistemului
de operare, iar o parte din codul introdus s fie maliios;
Victima poate accesa un link special pregtit (transmis pe mail, reele de socializare sau alte
metode) care s conin codul maliios;
Atacurile XSS se mpart n mai multe categorii ([Cert12]):
- Atacul de tip non-persistent atacatorul caut s gseasc o vulnerabilitate pentru XSS,
testnd diveri parametri de unde utilizatorul poate trimite mesaje la server si la care
primete mesaje napoi (de obicei un cmp de cutare). De exemplu, la introducerea pe
Google a parametrului de cutare atac XSS, browser-ul va ntoarce un URL cu un ir de
interogare care s fie de forma https://www.google.ro/?gws_rd=ssl#q=atac+xss, unde
ultima parte a URL-ului reprezint valoarea parametrului de cutare. Aceast valoare
poate fi schimbat dac introducem urmtoarea sintax HTML/JavaScript:
><script>alert(XSS%20Test). Dac pagina este vulnerabil, prin aceast modifcare a
URL-ului, va afia o fereastr de dialog inofensiv (dup instruciunea de cod care este
acum parte din pagin). Astfel, atacatorul descoper o vulnerabilitate care poate fi ulterior
folosit pentru a realiza atacuri XSS mai complexe (ex: furtul de cookie-uri) ([Cert12]).
- Atacul bazat pe DOM aceast form de atac XSS este unic, foarte similar cu cea a
atacului non-persistent, dar care nu necesit trimiterea unui mesaj i ateptarea unui
rspuns din partea site-ului. Spre exemplu, urmtorul URL http://victim/promo?
product_id=100&title=Foo#<script>alert(XSS%20Testing)</script> aparine unui site
de comer electronic care aduce datele din baza de date printr-un parametru (product_id)
i a fost modificat prin adugarea de cod maliios la finalul su. Dac site-ul prezint
vulerabilitate XSS, JavaScript-ul de pe partea clientului va avea ncredere suficient n
datele coninute de URL i va afia rezultatul pe ecran. Diferena dintre cele dou atacuri
este aceea c nu se trimite codul ctre serverul web ci fragmentul inserat n URL i spune
browser-ului n ce punct al documentului curent s sar (rmne n cadrul DOM)
([Cert12]).
- Atacul de tip persistent cunoscut i sub numele de injecie cu cod HTML, acest atac
nu necesit link-uri speciale pentru execuie, ci atacatorul trebuie doar s adauge codul
XSS ntr-o parte a paginii web care are potenial mare de vizitare din partea utilizatorilor
3 din 8

(ex: comentarii pe bloguri, chat-uri, postri pe forum-uri). Din momentul n care

utilizatorul a vizitat pagina infectat, codul se execut automat i din aceast cauz este
mult mai periculos dect celelalte tipuri de atac XSS, utilizatorul nemaiavnd cale s se
apere mpotriva execuiei ce a avut loc ([Cert12]).
Metodele de prevenire a atacurilor XSS sunt ([Cert12]):
1. Filtrarea poate produce rezultate neateptate dac nu se monitorizeaz atent datele de
ieire. Fr folosirea altor metode, filtrarea poate induce noi riscuri prin crearea unor noi
tipuri de atac, de aceea filtrele aplicate trebuie puse ntr-o anumit ordine i modul n care
interacioneaz ntre ele trebuie cunoscut ([Cert12]).
2. Codarea i validarea datelor de intrare se creaz un singur punct de intrare a datelor
pentru toate codrile i este eficient nu doar impotriva XSS, dar i a injeciilor SQL, care
sunt verificate nainte de stocarea informaiilor n baza de date, ns nu poate opri
atacurile persistente XSS odat ce au fost stocate ([Cert12]).
3. Codarea datelor de ieire
4. Securitatea browser-ului web evitarea URL-urilor prea lungi sau complexe,
neaccesarea URL-urilor necunoscute primite prin e-mail, alegerea unui browser sigur,
actualizat la zi, cu setri de securitate ([Cert12]).
c. Mesajele de eroare prea detaliate
Aceast vulnerabilitate nu reprezint un tip de atac n sine. Mesajele de eroare cu scop
informativ pot conine adrese complete, descrieri, erori legate de accesul la baza de date, nume
de fiiere, mediul n care ruleaz. Un exemplu concret l reprezint formularul tipic de
autentificare la o aplicaie, prin care se cere utilizatorului numele de cont i parola. Dac
procesul de autentificare nu reuete, aplicaia ntoarce un mesaj informativ prin care utilizatorul
este anunat ca informaiile introduse nu au fost corecte. ns uneori aplicaia te atenioneaz care
dintre cmpuri a fost cel greit (ex: parola introdus este incorect). Acest lucru ofer
informaia c n baza de date exist ntr-adevr un cont cu numele de utilizator introdus, iar astfel
un atacator poate folosi o metod automat de atac care s parcurg un set mare de parole, fr a
trebui s ghiceasc i numele utilizatorului. Un rspuns corect dat de aplicaie la nereuirea
logrii ar putea fi de forma (Numele de utilizator sau parola au fost introduse eronat) care este
mai ambiguu, iar atacatorului nu i se ofer o informaie concret ([Cert12]).
Pentru prevenirea atacurilor bazate pe mesajele de erori se recomand:
- Utilizarea validrii pe partea clientului doar pentru performan, nu i pentru securitate,
pentru prevenirea erorilor de introducere i de tipar neintenionate care s ajung la
server. Astfel se reduce solicitarea serverului, mpiedicnd datele introduce greit n mod
neintenionat s ajung la acesta ([Cert12]).
- Normalizarea datelor de intrare, verificarea de securitate i validare astfel nct o bucat
de cod introdus maliios s treac prin mai multe filtre i s fie decodat i descoperit
ca fiind maliioas doar mai trziu ([Cert12]).
- Aplicarea validrii pe partea serverului, unde evitarea funciilor de validare nu este
posibil ([Cert12]).
- Constrngerea tipurilor de date care pot fi introduse, prin cererea unui anumit tip, format
i lungime ([Cert12]).
- Folosirea codrii securizate a caracterelor i validarea datelor de ieire, pentru a evita
aplicaia s le interpreteze ntr-un mod eronat.

4 din 8

Folosirea cu grij a mesajelor de eroare, astfel nct acestea s nu dezvluie nicio

informaie esenial despre sistem ([Cert12]).
Solicitarea autentificrii pentru anumite funcionaliti ale aplicaiei ([Cert12]).

d. Eludarea restriciilor de autentificare

Prin procesul de autentificare se verific, ntr-o oarecare msur, identitatea unei persoane
sau entiti. Prin intermediul certificatelor SSL (Secure Socket Layer) folosit de ctre paginile
web, se valideaz faptul c datele transmise de ctre site provin ntr-adevr de la acesta i c
domeniul respectiv nu este o copie. Pentru spargerea unui sistem de autentificare exist dou
posibiliti puse la dispoziia atacatorului: evitarea verificrii autentificrii sau utilizarea unei
parole furate. Pe durata de timp n care un utilizator este autentificat la aplica ia web, aceasta i
atribuie un token unic de sesiune (de regul sub forma unui cookie) pentru ca activitatea sa s fie
monitorizat. Din momentul autentificrii, utilizatorul este identificat doar prin intermediul
cookie-ului de sesiune atribuit. Prin urmare, dac un atacator reuete s compromit cookie-ul,
ghicind valoarea sa sau furndu-l, atunci va trece uor de mecanismul de autentificare a paginii
web, asumndu-i identitatea victimei ([Cert12]).
Cookie-urile de sesiune pot fi compromise prin mai multe metode:
1. Atacuri XSS dac nu se seteaz atributul HttpOnly al aplicaiei web, folosind
JavaScript se poate accesa obiectul document.cookie, iar coninutul acestuia poate fi
trimis unui site de unde atacatorul poate obine credenialele necesare ([Cert12]).
2. Cross-site request forgery este necesar ca victima s fie deja autentificat pe site-ul
int. Atacatorul exploateaz n mod indirect sesiunea utilizatorului autentificat, plasnd o
pagin capcan pe alt site, iar n momentul n care victima viziteaz pagina infectat,
browser-ul va efectua o cerere automat ctre pagina int, folosind cookie-ul de sesiune
al victimei ([Cert12]).
3. SQL Injection acest lucru este posibil n cazul n care cookie-urile de sesiune sunt
stocate n baza de date, n loc s fie stocate ntr-un sistem de fiiere sau spaiu de stocare
al serverului web ([Cert12]).
4. Network sniffing majoritatea aplicaiilor web folosesc HTTPS pentru confidenialitatea
i integritatea comunicaiei dintre server i browser-ul web, ns cea mai mare parte din
ele folosesc HTTP pentru restul paginilor, expunnd cookie-ul de sesiune, n special prin
reelele wireless din locurile publice ([Cert12]).
e. Eludarea restriciilor de autorizare
Aceste vulnerabiliti se refer la scenariul n care atacatorul are acces la o resurs la care, n
mod normal, ar avea acces doar utilizatori autentificai sau care dein anumite roluri sau
privilegii n aplicaia respectiv. Cele mai folosite metode de eludare a restriciilor de autorizare
sunt: traversarea de directoare, evitarea mecanismelor de autorizare i escaladarea privilegiilor.
Serverele restricioneaz utilizatorii la accesul diferitelor resurse, a cror localizare depinde de
sistemul de operare instalat pe server, n funcie de permisiuni de citire, scriere, execuie atribuite
utilizatorilor respectivi asupra fiierelor de pe server. Deoarece, de regul, majoritatea aplicaiilor
web folosesc roluri (administrator, user autentificat/neautentificat) care au diferite niveluri de
acces, un atacator poate reui sa acceseze o resurs restricionat permisiunilor sale de acces, prin
schimbarea rolului su ntr-unul superior ([Cert12]).
Cele mai simple modaliti de protecie asupra acestor vulnerabiliti sunt validarea datelor
introduse de utilizatori i urmrirea metodelor de proiectare sigur. Orice parte a aplica iei web
5 din 8

care poate fi folosit ntr-un eventual atac informatic trebuie identificat din timp. Aceste
componente nu fac referire doar la cmpurile prin care utilizatorul poate introduce date, dar i
oricare alt valoare ce poate fi modificat i trimis prin intermediul unui proxy (cmpuri
ascunse, date din cookie). Validarea corespunztoare a acestor date scad ansele unui atac reuit
cu succes. De asemenea, cu ct utilizatorul are mai puine privilegii, cu att ansele de a duce
pn la capt un atac asupra aplicaiei scad ([Cert12]).
f. Erori logice
Erorile logice sunt erori de programare care pot aprea n momentul n care la dezvoltarea
aplicaiei lucreaz un numr mare de programatori i dezvoltatori diferii. Toate aplicaiile web
folosesc o logic anume de funcionalitate. Acestea sunt descompuse n pai mici, simpli, pentru
a aduce funcionalitile necesare aplicaiei la nivelul la care pot fi executate de ctre un
dispozitiv. Chiar i n cazul aplicaiilor web simple, dezvoltarea lor presupune o cantitate mare de
logic, pentru fiecare etap de proiectare. Dei sunt trecute de multe ori cu vederea, erorile logice
ofer o baz foarte variat de atac. Din nefericire, nu pot fi dect n cazuri rare scanate cu
ajutorul unor programe specializate de identificare a vulnerabilitilor i nu prezint o semntur
specializat ca n cazul altor vulnerabiliti, ceea ce le face mult mai greu de cunoscut i
caracterizat. Deoarece nu sunt apreciate ca i vulerabiliti grave, erorile logice prezint un
interes foarte mare din partea atacatorilor ([Cert12]).
O eroare logic apare n momentul n care programatorul aplicaiei nu ia n considerare toate
efectele posibile ale codului asupra aplicaiei. Se iau n considerare doar efectele care se
intenioeaz sa fie implementate, nelund n seam sau fcnd omitere de alte efecte secundare,
posibile. Defectele de ordin logic sunt greu de explicat, definit i nvat prin teorie, ele fiind
variate de la o aplicaie la alta. Sunt descoperite de regul de ctre atacatori dup familiarizarea
cu aplicaia respectiv i dup testarea comportamentului su n diverse situaii. Totui, pentru a
se nelege mai bine importana deosebit pe care o pot avea aceste erori logice, vor fi prezentate
n continuare dou exemple concrete prin care s-a fcut exploatarea acestora.
Un prim exemplu este ocolirea funciei pentru schimbarea parolei, o eroare de logic ce a fost
gsit ntr-o aplicaie web utilizat de o societate de servicii financiare. Aceasta avea
implementat o funcie de shimbare a parolei de ctre utilizatori n care era necesar completarea
cmpurilor: nume utilizator, parol actual, noua parol i confirmarea noii parolei. De
asemenea, o alt funcie din cadrul aplicaiei permitea schimbarea parolei de ctre administratori,
prin care acetia puteau schimba parola oricrui utilizator fr a fi nevoii s introduc vechea
parol a acestuia. Aceste dou funcii au fost puse n cadrul aceluiai script pe partea serverului.
Interfeele afiate clienilor i administratorilor difereau prin faptul c cea afiat unui
administrator nu avea cmpul de introducere a vechii parole. Presupunerea fcut, din care a
provenit ulterior eroarea logic a fost aceea c un utilizator obinuit va introduce ntotdeauna
vechea parol pentru modficarea acesteia. Prin urmare, n momentul n care serverul procesa o
schimbare de parol, el verifica dac aceasta a fost cerut de un client sau de un administrator
verificnd prezena sau absena vechii parole. Dac cmpul pentru vechea parol era gol, atunci
serverul presupunea c un administrator a fcut cererea. Din acest moment, eroarea logic devine
evident, deoarece utilizatorii controleaz fiecare aspect al cererilor pe care le emit. Prin urmare,
ei pot alege dac s completeze sau nu cmpul pentru vechea parol. n acest caz, defectul logic
s-a dovedit devastator, fiecare atacator avnd oportunitatea s reseteze cu uurin parola oricrui
alt utilizator i s preia controlul asupra contului acestuia, o dat ce acest mecanism de procesare
a cererii i devenea cunoscut ([Cert12]).
6 din 8

Un alt exemplu de defect logic, descoperit ntr-un centru de telefonie, fcea referire la
tergerea intrrilor din audit. Aplicaia avea diverse funcii care permiteau gestionarea unei baze
de date de dimensiuni mari. Multe din acestea se refereau la informaii securizate, printre care i
crearea de conturi i schimbarea de parole, iar din aceast cauz se men inea o gestiune complet
de audit, unde fiecare aciune efectuat era nregistrat, mpreun cu identitatea utilizatorului
responsabil de acea aciune. De asemenea era inclus i o funcie prin care li se permitea
administratorilor s tearg anumite intrri din audit, aciune care la rndul ei era nregistrat,
pentru evitarea exploatrii n scopuri ru-voitoare. Dezvoltatorii aplicaiei au plecat de la
presupunerea c nicio tergere a vreunei nregistrri din audit nu se poate realiza fr a lsa
mcar o urm (prin testrile lor, rmnnd de fiecare dat ultima nregistrare a persoanei care a
ters datele). Aceast presupunere a fost greit, deoarece atacatorii au descoperit o modalitate de
a produce modificri asupra datelor i a terge urmele n ntregime, parcurgnd urmtorii pai:
autentificarea cu propriul cont i crearea unui nou cont de utilizator, atribuirea tuturor
privilegiilor noului cont, utilizarea noului cont pentru a duce la ndeplinire atacul, apoi utilizarea
unui nou cont pentru a terge toate nregistrrile generate de primii trei pai. n acest fel, de i
fiecare din aciuni genera nregistrri n jurnalul de audit, n ultima faz, contul nou creat tergea
toate datele legate de intrrile i aciunile precedente. Astfel, n audit rmnea doar intrarea c cel
de-al doilea nou cont a ters toate datele. Deoarece al doilea cont era creat de primul cont nou
creat, iar nregistrrile legate de cine a creat primul cont erau terse, nu mai exista practic nicio
informaie valabil care s poat face legtura ntre identitatea persoanei care a dus la capt
atacul i contul iniial al persoanei care a pornit atacul ([Cert12]).
O serie de practici care pot ajuta n reducerea erorilor logice, este urmtoarea:
- Documentarea tuturor aspectelor legate de design-ul aplicaiei pentru a putea fi nelese
uor de cineva din exterior ([Cert12]).
- Punerea accentului pe modul n care ar putea influena utilizatorii aplicaia, n timpul
recenziilor de securitate referitoare la cod ([Cert12]).
Punerea accentului pe modul de comportare a aplicaiei n momentul n care sunt introduse date
eronate i efectele produse asupra dependenelor dintre componentele diverse ale codului
([Cert12]).
Introducerea de comentarii n codul surs care s includ informaii legate de: scopul i
funcionalitatea fiecrei poriuni de cod, presupunerile fcute de fiecare component n legtur
cu elementele care nu se afl direct sub controlul ei, adugarea de comentarii care s fac
trimitere la toate componentele care folosesc acel cod ([Cert12]).
g. Diseminarea codului-surs
O eroare de codare, des ntlnit n aplicaiile web, este divulgarea codului surs care face
posibil exploatarea acestuia de ctre atacator cu scopul de a reconfigura fiiere prin intermediul
HTTP, oferind totodat o nelegere mai profund atacatorului n legtur cu logica din spatele
aplicaiei web.
Folosind un atac de tip divulgare a codului surs, atacatorul poate obine codul surs pentru
aplicaiile de pe server (precum ASP, PHP, JSP) i, implicit, o imagine asupra logicii aplica iei,
modul de gestionare a cererilor i parametrii acestora, structura bazei de date, comentariile
introduse n cod i vulnerabilitile acestuia. Aceste informaii pot fi folosite pentru realizarea
unui duplicat a aplicaiei pentru teste i pregtirea unui atac asupra celei originale. Atacul poate fi
realizat folosind vulnerabiliti cu divulgare a codului surs cunoscute, exploatarea erorilor

7 din 8

detaliate care uneori includ codul surs, folosind alte tipuri de vulnerabiliti cunoscute care se
pot dovedi utile n divulgarea codului (cum ar fi traversarea directoarelor) ([Cert12]).
Metodele de prevenire a atacurilor de acest fel sunt urmtoarele:
- Verificarea folderului de unde este cerut fiierul care urmeaz s fie descrcat
- Verificarea tipurilor de fiiere cerute de utilizatori
- Indexarea fiierelor care pot fi descrcate i afiarea doar a numrului lor din index ca i
parametru al URL-ului.
Aceste aspecte legate de securitatea aplicaiilor web, dei exist posibilitatea ca ele s nu fie
detaliate n cerinele de proiectare a aplicaiei sau menionate de ctre clientul ce dorete
proiectarea aplicaiei respective, reprezint o importan vital i trebuie luate n considerare de
ctre dezvoltatori, constituind practic punctul de plecare al construirii sistemului informatic ce se
dorete a fi proiectat.
Bibliografie:
[CERT12] - CERT-RO Ghid pentru securizarea aplicaiilor i serviciilor web 2012

8 din 8