Modalit ăți de asigurare a securit ății web -siteurilor [619762]

Universitatea din Bucure ști
Facultatea de Matematic ă și Informatic ă

Lucrare de Licen ță
Modalit ăți de asigurare a securit ății
web-site-urilor

Coordonator:
Lector dr Mihail Cherciu
Absolvent: [anonimizat]
2016

Modalit ăți de asigurare a securit ății web -siteurilor

1

Cuprins
Introducere. Prezentare general ă……………………………………………………………….. ……………… 3

Capitolul I
Site-uri Web.Clasificare. Arhitectură .Particularit ăți………………………… ………………………….4

Capitolul II
Introducere în securitatea Web …………………………………….. …………………………… …………….. 9
Principii de securitate ……………………………………………………………………………….. …………..10
Atacuri, vulnerabilit ăți și efectele lor………………. …………………………………………. …………..11

Capitolul III
Elemente de securitate Apache ………………………………………………….. …………….. …………….16
Elemente de securitate a bazei de date MySql …………………………….. ……………… …………….20
Elemente de securitate PH P………………………………………………….. …………………… …………..25
Elemente de securitate a browserului ………………………………….. …………………….. ……………30

Capitolul IV
Autentificarea, Criptarea, Managementul Sesiunilor ……………………………….. ……………….. 31
Cookie -uri………………………………………………………………………………………………… ………….31
Manageme ntul Sesiunilor ……………………………………………………………………………. …………33
Criptografia site -urilor we b. Protocoalele SSL si T LS……………………………………. ………….37

Capitolul V
Instrumente pentru securitatea web …………………………………………………………. ………………50
Scan nere de vulnerabilit ăți……………………………………………………………………………. ……….50
Analiz oare de cod PHP…………………………… ………………………………………………… ……….. …54
Alte instrumente………………………………………………………………………………………… …………55

Studiu de caz
Site web de social networking scris în PhP/MySql ………………………………………. …………… 57

Modalit ăți de asigurare a securit ății web -siteurilor

2

Modalit ăți de asigurare a securit ății web -siteurilor

3

Introducere

Limbajul PHP a devenit încă de la începuturile sale, limbajul de scripting preferat
de vasta majoritate a developerilor web, fiind utilizat in peste 22 de milioane de nume de
domenii rulând pe mai bine de 1,3 milioane de servere distincte. Creșterea rapidă a
utilizǎrii limbajului PH P s-a datorat pr intre altele simplitǎții sale, funcționalitaților pe care
le oferǎ, precum și performanțelor excelente înregistrate în exploatare. Din pǎcate, aceleași
calitați care au făcut PHP -ul atât de popular, au “ajutat” developerii de aplicații web sǎ
neglijeze un aspect foarte important al developmentului de soft: securitatea aplicațiilor
scrise în PH P. Dacă la începuturile sale, problema securitǎții in PH P nu a fost atât de
stringentă, în prezent, când PHP este utilizat în sisteme de tranzacționare, portaluri de
corporație sau e -commerce, un cod nesecurizat poate avea conseci nțe dintre cele mai
neplăcute, atât din punct de vedere financiar cât și din punct de vedere al reputației sau
încrederii în site -ul sau organizația respectivă.
Lucrarea de față își propune să realizeze o scurtă incursiune în problematica
securitǎții site -urilor web și anume să evidențieze o serie de probleme apărute frecvent în
concepția și dezvoltarea site -urilor web iar, în final, să ofere pentru unele dintre ele o serie
de recomandări simple dar eficiente. De asemenea, autorul prezintă o serie de utili tare la
îndemana administratorului web care pot fi utilizate pentru imbunătățirea securitǎții web.
Conștient fiind de faptul că securitatea web reprezintă un domeniu vast, au fost lăsate
inten ționat netratate unele subiecte care ar necesita o cercetare mai aprofundată și ar mări
mult volumul lucrării . Din acest motiv, lucrarea nu tratează probleme de securitate fizică a
serverului care găzduiește site -ul web si nici nu abordează probleme de securitate a
sistemului de operar e.

Modalit ăți de asigurare a securit ății web -siteurilor

4
Capitolul I. Site-uri web. Clasificare. Arhitectură. Particularități
Definiții ale site -urilor web
Un website sau site web reprezintă o colecție de pagini web, de obicei, aparținând
unui domeniu web. Un site web este găzduit pe cel puțin un server, este accesibil prin
intermediul unei rețe le cum ar fi Internet sau LAN ( local area network) prin intermediul
unei adrese de internet numită URL ( uniform resource locator). ( Wikipedia )
Un website reprezintă un grup de pagini web conținand legături între ele, puse la
dispoziție online de către un individ , companie , institutie educațională, guvern sau alt tip
de organizatie. ( Dictionarul Webster )

Clasificare a site -urilor web
Dupa scopul utiliz ării site -urile web sunt de mai multe categorii:
Site-uri de prezentare . Au 5 -10 pagini în care se prezint ă o firm ă, un produs sau un
serviciu .
Site-uri de prezentare corporate . Utilizate pentru prezentarea companiilor mari,
includ mai multe pagini prin care este prezentat ă activitatea companiei, proiectele
desfășurate. Site -urile pot include și module prin care se faciliteaz ă colaborarea cu clien ții,
distribuitorii, etc.
Site-uri de informare . Sunt create exclusiv pentru a prezenta informa ții pe o
anumit ă temă.
Site-uri de campanie publicitar ă. Sunt realizate în aplica ții de anima ție Flash, sunt
utilizate pentru a promova un produs sau un serviciu .
Site-uri de con ținut generat de utilizatori . Majoritatea con ținutului acestor site -uri
aparține vizitatorilor. De exemplu : www.yout ube.com , www.soundcloud.com
Site-uri de rețele sociale . Printre cele mai cunoscute sunt : www.facebook.com ,
linkedin.com , twitter.com
Site-uri de știri. Apar țin de obicei institu țiilor dar pot fi și alc ătuite din știri
colectate de la ter ți furnizori : mediafax.com , gandul.info, ade varul.com .
Bloguri . Site -uri web create de obicei de o singur ă persoan ă, care scrie des articole
pe diverse teme. Articolele pot fi comentate de vizitatori: Zoso.ro , wordpress.com.
Magazine online . Create pentru a servi comer țului electronic. Exemple: emag.ro ,
amazon.com , covera.ro .

Modalit ăți de asigurare a securit ății web -siteurilor

5
Platforme de e -learning . Acest tip de site pun la dispozi ția utilizatorilor cursuri sau
tutorial e gratuite. Exemple: Udemy.com, Coursera.com, iversity.com, FutureLearn.com
sau iversity.com .
Portaluri . Sunt site -uri care conțin mai multe tipuri de informa ții, știri, vide oclipuri,
etc. Din aceast ă categorie fac parte site -uri precum: Apropo.ro, realitatea.net , romania.tv ,
tv5monde.com , yahoo.com .
Motoare de c ăutare . Sunt utilizate pentru a c ăuta informa ții în întregul world wide
web, de exemplu www.google.com sau localizat într-o anumit ă regiune/ țară, de exemplu
www.yandex.ru, cel mai utilizat motor de c ăutare din Rusia sau www.baidu.com , cel mai
utilizat motor de c ăutare chinez. Altele: altavista.com , yahoo.c om.
Dupa modul în care au fost construite exist ă două tipuri principale de site -uri.
Site-uri statice , care con țin doar fi șiere HTML , CSS , Javascript , imagini și text.
Acestea sunt cele mai simple site -uri, pentru ca nu necesit ă cunostin țe avansate de
programare. Acest tip de site -uri este potrivit pentru prezentarea unei firme mici .
Site-urile web dinamice , cu o structur ă mai complexă decât cele statice. Site -urile
web dinamice pot con ține un server de aplica ții, o baz ă de date ș i un limbaj de scr ipting la
nivel de server gen PH P. Acest gen de website este recomandat pentru pagini complexe, de
genul magazinelor online , blog -urilor dar și site -urilor de preze ntare care ofer ă
functionalit ăți sporite .
Arhitectura unui site web dinamic
Lucrarea de fa ță se concentreaz ă asupra site -urilor web d inamice construite cu PHP,
MySQL, Apache ( la nivel de server) și JavaScript, CSS si HTML (la nivel de client ).
Acestea sunt tehnologii Open Source foarte larg r ăspândite în râ ndul comunit ății
dezvoltatorilor de site-uri web.
Un alt beneficiu important este acela ca aceste tehnologii sunt gratuite.
De aceea, vom considera în conti nuare, un site web avâ nd combina ția men ționat ă
mai sus: PHP, MySQL, Apache ( la nivel de server) și JavaScript, CSS si HTML (la nivel
de client ).
De alt fel, PHP ( limbaj de scripting) , MySQL (baze de date) și Apache( web server)
reprezint ă cele mai frecvent utilizate tehnologii din categoria lor.

Modalit ăți de asigurare a securit ății web -siteurilor

6

Fig. 1 – Arhitectura unui site web
Procesul Cerere / R ăspuns
La nivelul cel mai de baz ă, procesul cerere/răspuns este alcă tuit dintr -un browser
web care cere unui server s ă-i trimit ă o pagină web și un ser ver web c are îi trimite pagina
(Figura 2 ).

Fig. 2 – Secven ța simpl ă cerere/ră spuns

Modalit ăți de asigurare a securit ății web -siteurilor

7
Pașii din secven ța cerere/ răspuns sun t prezenta ți mai jos:
1. Se introduce http://site.ro în adresa browserului
2. Browserul caut ă adresa IP asociat ă site.ro
3. Browserul emite o cerere pentru pagina principal ă la site.ro
4. Cererea este transmis ă pe internet și ajunge la serverul web al site.ro
5. Se rverul web,dup ă ce a primit cererea, caut ă pagina web pe hard discul local.
6. Pagina web este gasit ă de serverul web și trimis ă browserului
7. Browserul afi șează pagina web.
La pasul 2, se observă că browserul web a căutat adresa IP a site.ro. Fiecare
computer conectat la internet are asignată o adresă IP. Dar, in general, accesăm serverele
web după nume, cum ar fi site.ro sau google.com. Browserul consultă un serviciu internet
numit DNS ( Domain Name Service ) pentru a găsi adresa IP asociată site ului s i apoi o
utilizează pentru a comunica cu calculatorul.
Fig. 3 – Secven ța dinamic ă cerere/r ăspuns

Modalit ăți de asigurare a securit ății web -siteurilor

8

Pașii urma ți pentru o secven ță dinamic ă cerere /r ăspuns ( ilustra ți în Figura 3) sunt:
1. Se introduce adresa http://www.site.ro în browser
2. Browserul caută adresa IP asociat ă lui site.ro
3. Browserul emite o cerere la aceast ă adres ă de IP pentru pagina de start a
serverului web
4. Cererea str ăbate re țeaua internet și sose ște la serverul web al site.ro
5. Serverul web, primind cererea, aduce pagina de start de pe hard disk.
6. Cu pagina de start în memorie, serverul web observ ă că este un fisier con ținând
script PHP și trimite pagina interpretorului PHP.
7. Interpretorul P HP execut ă codul PHP
8. Unele comenzi PHP pot con ține declara ții MySQL ( cereri de interog ări în baza
de date) pe care interpretorul PHP le transmite mai departe motorului bazei de date
MySQL.
9. Baza de date MySQL returnează rezultatele interog ărilor/ declara țiilor MySQL
înapoi către serverul Web.
10. Interpretorul PHP returneaz ă rezultatele execu ției codului PHP împreun ă cu
rezultatele interog ărilor din baza de date MySQL către serverul Web.
11. Serverul Web returneaz ă pagina c ătre browserul client, pe care o afi șează.
Pagina HTML returnat ă către browser, in exemplul de mai sus, poate con ține și cod
JavaScript care va fi interpretat local de browserul client.
Exist ă o serie de instrumente care se pot utiliza pentru a determina tehnologia
utilizat ă la construirea unui web sit e. Un exemplu în acest sens este builtwith.com.

Modalit ăți de asigurare a securit ății web -siteurilor

9
Capitolul II. Introducere în securitatea web
Când se discută despre securizarea unui site web trebuie s ă se evalu eze mai întâi
importan ța informa ției care trebuie protejat ă ( atât pentru proprietarul site-ului c ât și pentru
atacatori).
Am putea fi tentați să credem că cel mai ridicat nivel de securita te este cerut pentru
toate site -urile, in orice situație, dar securitatea vine cu un anumit cost. Înainte de a decide
cât efort sau câte cheltuieli trebui e alocate securitǎții, trebuie d eterminat cât valorează
informația din site -ul respectiv. Valoarea informației deținute pe un computer de un user
ocazional, o bancă, o clinică medica lă sau de o organizație militară diferă foarte mult.
Securitatea trebuie i nclusă î n faza de design. Securitatea nu este un obiectiv , ci mai
curând o stare de spirit sau ati tudine. Securitatea trebuie pusă î n balan ța cu costurile
necesare asigură rii ei, precum ș i cu uzabilitatea.

Elemente de securitate
Securitatea Web se bazeaz ă pe urmă toarele elemente:

Confiden țialitatea
Imposibilitatea unei terțe entități sa aibă acces la datele vehiculate între doi
receptori. Este procesul care asigură că datele ramân confidențiale și că nu pot fi accesate
de către utilizatori neautoriza ți sau de cei care monitorizează fluxul de date intra si inter
rețele. Criptarea este utilizată in mod fre cvent pentru a asigura confidențialitatea. O altă
modalitate este utilizarea listelor de control al accesului (access cont rol lists – ACL ).

Autentificarea
Presupune verificarea identității utilizatorului, de o bicei, pe baza de nume si parolă .
Ea raspunde la întrebarea fundamentală : „cine este acest utilizator?” , și repre zintă
procesul care identifică î n mod unic clienții deserviți de aplicație sau servici i.

Autorizarea
Specifica acțiunile (rolurile ) pe care un utilizator le poate realiza intr -un anumit
context. A ceasta este asociată autentifică rii. E a raspunde la întrebarea: ”ce poți face ?” și
reprezintă procesul care guvernează ce resurse sau operații poate accesa userul care este
autenti ficat. Resursele includ fișiere , baze de date, tabele, recorduri, ș .a.m.d., împreună cu
resurse sistem cum ar fi registry keys sau date de configurare.

Integritatea
Implică detectarea î ncercărilor de modificare neautorizată a datelor transmise.
Aceasta reprezintă garanția că datele sunt protejate împotriva modificărilor accidentale sau

Modalit ăți de asigurare a securit ății web -siteurilor

10
(răuvoitoare)deliberate. La fel ca și privacy, integritatea este o preocupare cheie, in special,
când datele sunt transmise prin mai multe rețele. Integritatea datelor în tranzit este de
obicei asigurată prin utilizarea tehnicilor de hashing și a codurilor de autentificare a
mesajelor.

Nerepudierea
Asigur ă că expeditorul unui mesaj nu poate afirma c ă nu l-a trimis .

Privacy
Vizeaz ă drepturile ce trebuie respectat e privind caracterul (subiectul ) datelor
vehiculate. Aceasta este deseori confundat ă cu confiden țialitatea.

Disponibilitatea
O anumit ă resurs ă este necesar s ă fie accesat ă la momentul oportun.

Securitatea Web trebuie s ă ia în considerare :
Clientul (interacțiunea cu utilizatorul, d atele personale stocate, cookie -urile, date
off-line, cache, etc ., transferurile asincrone v ia Ajax/Comet, existența plugin -urilor și a
extensii lor suspecte ).
Datele în tranzit (securitatea rețelei, schimbul sigur de mes aje între diverse entități ,
nerepudierea datelor ).
Serverul (securitatea serverului/ serverelor web, securitatea aplicațiilor,
disponibilitatea serviciilor) .
Atacu rile asupra unui site web pot viza oricare dintre cele trei aspecte.

Vulnerabilit ăți ale site -urilor web ș i problemele pe care le pot cauza

Printre cauzele vulnerabil ităților de securitate ale site -urilor web amintim
următoarele:
– Erorile de program (bug-urile)
– Configurarea necorespunză toare a programelor
– Lipsa suportului tehnic asociat programelor în exploatare.

Studiile au arătat că intr -o proporție foarte mare (peste 90%) breșele de securitate
apărute au fost cauzate de instala rea și configurarea necorespunză toare sau de
nerespectarea unor proceduri de utilizare sau administrare a serverelor web.

Principii de proiectare și programare cu implica ții asupra securit ății web

Expunerea minimă
Cât mai puține privilegii
Simplitatea
Apǎrar ea în adâncime

Modalit ăți de asigurare a securit ății web -siteurilor

11
Expunerea minimă
De cele mai multe ori site -urile web comunică cu bazele de date și cu clienții prin
intermediul cererilor HTTP. Prin acest proces , fluxul de date și informații traversează
internetul fiind astfel expuse detectării prin intermediul unor posibile atacuri ale
utilizatorilor rău intentionați. Dacă date le expuse au valoare ridicată ( cum ar fi informații
despre credit -card, parole, informa ții m edicale) atunci aceasta prezintă un risc de securitate
ridicat. Se recomandă minimizarea expunerii sau transmiterii unor informații de acest gen
si utilizarea conexiunilor SSL.
Cât mai puține privilegii
Într-o aplicație î n care este necesară autenti ficarea userilor, se recomandă acordarea
acelor privilegii de care au nevoie pentru execuția opera țiilor la care sunt îndreptă țiți prin
lista de control al accesului. Acordarea unor privilegii care nu sunt necesare în indeplinirea
taskurilor asociate useri lor poate duce la utilizarea lor in scopuri care pot produce pagube
majore aplicației web. În plus, nu trebuie acordat niciun privilegiu care asigură accesul la o
funcționalitate pentru care userul nu are train ingul necesar utiliză rii ei. De aceea, de cele
mai multe ori, orice nou privilegiu asignat userilor trece printr -un proces de aprobare.
Simplitatea
Creșterea complexitatii unui site web poate conduce la probleme în gestionarea
securitǎții acestuia. De exe mplu, este necesară o urmărire mai atentă a modului cum
interacționează modulele care compun aplicația si a modului de configurare a aplicației
web. Ca regulă generală, complexitatea unei aplicații web nu trebuie sa depașească
capabilită țile de administrare a acesteia.
Apǎrarea în adâ ncime
Principiul apǎrǎrii în adâncime ( defense in depth) stipuleazǎ cǎ este necesar sǎ se
realizeze un plan de a pǎrare de rezervă. De exemplu, î n cazul efectuării unor tranzacții
bancare, chiar dacă utilizatorul este deja logat la aplicație, sistemul poate impune ca userul
să se autentifice din nou câ nd se va efectua o noua tranzacț ie. Prin aceasta s e pot preveni
eventuale tranzacț ii de către utilizatori neautentificaț i.

Vulnerabilită ți ale site -urilor web

Lipsa unei autentificări suficiente
Verificarea credențialelor ș i apoi asigurarea accesului la aplicația web sunt
operațiuni esențiale pentru un server. Autentificarea utilizând credențiale valide reprezi ntă
primul punct de verificare în protecția unei aplicaț ii web. Una din cele mai mari slăbiciuni
ale aplicaț iilor web o reprezintă lipsa unei meto de puternice de autentificare ( utilizarea
unei parole complexe).
Lipsa unei politici de setare și reîn noire a parolelor
Parolele reprezintă unul din cele mai importante elemen te ale securită ții web. Ele
trebu ie protejate și schimbate la intervale regulate de timp pentru că un hacker poate
induce un atac de ghicire a parolei (prin intermediul unui atac de tip forță brută sau
dicționar) care poate avea o probabilitate mare de succes . Odata ce parola a fost ghici tă,

Modalit ăți de asigurare a securit ății web -siteurilor

12
atacatorul se poate conecta la aplicație și opera în numele userului a i cărui credențiale au
fost ghicite. Observăm frecvent că politica de securitate nu cere useri lor să aibă o parolă
complexă ( combinație de caractere alfanumerice , utilizare litere mici și litere mari).
Practica curentă î n materie de setar e a unei parole sigure este urmă toarea:
– Parola nu trebuie să fie un cuvânt din dicționar
– Parola nu treb uie să fie prenumele sau să conțină prenumele userului
– Parola nu tre buie să f ie numele de familie sau să conț ină numele de familie a l
userului
– Parola nu trebuie să fie mai lungă de 255 de caractere
– Parola trebuie să conțină cel puțin două caractere alfabetice
– Parola trebuie să aibă o lungime de cel puț in 8 caracte re
– Parola trebuie să conțină cel putin o literă mică
– Parola trebuie să conț ină cel putin o literă mare
– Parola trebuie să conț ină ce l puțin un caracter numeric
– Parola nu trebuie să se potrivească cu sau să conțină ID -ul utilizatorului
Parola tr imisă pe o conexiune necriptat ă
Parolele trimise pe o conexiune necriptată sunt vulnerabile/ susceptibile să fie
capturate de către un atacator poziționat adecvat la rețea pentru a monitoriza și captura
traficul. Aceasta include orice entitate situată in rețeaua userului, la providerul de internet,
la providerul d e internet car e găzduiește site -ul, etc .
Colectarea de nume de utilizatori
Ca regul ă generală , numele de utilizator nu trebuie utilizat de mai multe persoane.
De asemenea , numele de utilizator nu trebuie expus. Ca și in cazul parolelor, numele de
utilizator poate fi extras prin metode de forță brută sau prin simpla găsire a adreselor de
email asociate numelui de utilizator sau facând căutare pe internet. Un atacator poate
exploata aceste elemen te ca p otențiale vulnerabilități cu care să adune informaț ii.
Atacatorul poate astfel ghici numele de utilizator și, în ecranul de login , poate proiecta
atacuri mai precise ( ghicirea parolelor doar pentru conturile valide, concentrându -se pe
reducerea num ărului de incercari de hacking la un nivel la care nu poate fi detectat de orice
metoda automată). O cale relativ simplă de a obtine acces neautorizat l a username se poate
face utilizâ nd procesul de recuperare a parolei (funcționalitate oferită de marea ma jorita te a
site-urilor web). S -a constat at de foarte multe ori că informaț ii despre nume de utilizatori
valide sunt afiș ate in mesajele de parolă eronată. Atacatorul poate exploata această
vulnerabilitate pentru a co lecta informații despre userii î nregistr ați. Așa cum s -a menționat
anterior, aceste informaț ii vor ajuta atacatorul în proiectarea unor atacuri mai precise, cum
ar fi ghicirea parolelor conturilor valide.
Management neadecvat al sesiunilor
Gestiunea sesiunilor reprezintă o metodologie de secur itate ese nțială pentru oprirea
atacatorilor în î ncercarea lor de a prelua controlul sesiunii. Ideea este ca serverul să poată
verifica regulat dacă userul este cel care pretinde că este. Dacă o aplicație nu utilizează
criptarea la nivel de transport ( SSL s au TLS) pentru a proteja comunicarea între client ș i
server, comunicarea este mai susceptibilă de a avea breșe de securitate.

Modalit ăți de asigurare a securit ății web -siteurilor

13
Suport slab al cifrului SSL
O metodă s tandard de a secretiza comunicațiile î ntre un user și aplicațiile sale o
reprezintă cripta rea. Dac ă metoda de criptare este î nvechit ă sau slabă, securitatea aplicaț iei
este și ea slabă.
Sunt c unoscute destule exemple unde un serviciu remote suportă un cifru slab SSL.
Atacatorul poate sparge critparea slabă a cifrului și induce un atac de tipul ”men in the
middle ” pentru a intercepta o sesiune de utilizator.
Informația trimisă utilizând metoda GET
Există cateva metod e pe care HTML le utilizează pentru a face cereri de informații,
incluzând metodele GET și POST.
Stringuri ale Id -urilor de sesi une prea scurte și ne -aleatoare
Utilizarea ID -urilor de sesiune care sunt ușor de ghicit reprezintă o vulnerabilitate.
Identificatorii de sesiune ar trebui să fie cat mai lungi posibil și generati aleator. Un ID sau
token de sesiune reprezintă un instrument de identificare a unui user conectat la o aplicație
web. Aplicația web creează tokenuri de sesiun e pe care îi trimite către browserul userului.
Browserul, in schimb, trimite tokenul inapoi către aplicația web impreună cu o cerere sau
informație care identifică userul. Un atacator poate ghici valoarea tokenului pentru userii
autentificați, fapt ce poat e duce la un acces neautorizat sub fo rma unei deturnări de sesiune
(session hijacking ). După ce sesiunea a fost deturnată, oric e actiune a atacatorului va fi
înregistrată ca aparținând userului inițial.
Răspuns HTTP stocat în cache
Răspunsurile http care conțin date importante pot fi stocate î n memoria cache a
computerului local. Aceste informații pot fi colectate de alte per soane care dețin acces la
acelaș i calculator (cautând in memoria cache). Această situație poate fi și mai dificilă dacă
laptopul use rului este furat sau dacă userul accesează site -ul web de la un terminal public.
Zona de cache se referă la copiile p aginilor web utilizate recent ( și a datelor asociate) care
sunt stocate pe calculato rul local. Aceste copii locale î mbunătățesc viteza de a cces la si te
dar pot fi ușor găsite în fiș ierele utilizator și etichetate ca tempo rary internet files sau cache.
În unele browsere precum Internet Explorer, conținutul cache poate fi creat atât prin HTTP
cât și prin HTTPS.
Afișarea tipului și versiunii de server http
În securitatea web, este considerată o bună practică ascunderea orică rei informații
despre tehnologie, producător și versiune a oricărui element hardware și software din
urmatorul motiv: aceste informaț ii pot fi utilizate de către un atacator pentru a identifica
vulnerabilită țile asociate cu tehnologia, producătorul sau versiunea respectivă.
Cookie -uri nesecurizate, Cookie -uri cu flagul Secure inactiv
Cookie -urile pot fi utili zate pentru controlul accesului; prezentăm mai jos câ teva
probleme de securitate legate de ele. Un cookie http este un fiș ier trimis de un server web
către un browser. Mesajul este apoi trimis înapoi către server de fiecare dată când
brow serul cere o pag ină de la server. Scopul utilizării cookie -urilor este acela de a
îmbunătăți ex periența utilizatorului cu site -ul respectiv, prin direcț ionarea utilizatorului
către informațiile care -l interesează cel mai mult. S -a constat at adesea că tokenurile de

Modalit ăți de asigurare a securit ății web -siteurilor

14
sesiune nu sunt protejate a decvat acolo unde mediul aplicaț iei web oferă o gestionare a
sesiunilor: de exemplu când id -ul de sesiune al userului este afișat în URL. Aceasta creează
o vulnerabilitate când un atacator poate determina o sesiune activă și poate lua identitatea
unui user valid. Char dacă autentificarea este cerută, poate fi posibil pentr u un user să o
realizeze utilizâ nd credențialele l ui dar apoi el poate schimba id -ul de sesiune în URL
pentru a accesa datele altui utilizator, fără a cere o reautentificare.
Daca Secur e flag este setat pentru cookie -uri, browserele nu vor trimite cookie -urile
cu cereri care utilizează conexiune http necriptată, evitân d în acest fel ca aceste cookie -uri
să fie interceptate de către un atacator care monitoriz ează traficul de rețea. Daca opț iunea
Secur e nu este setată, atunci cookie -urile sunt transmise î n text clar.
Cookieuri setate să expire î ntr-un termen foarte lung
Cookie -urile cu termen de expirare extins reprezintă o sursă de vulnerabilitate. Este
recomandabil să se seteze cookie -urile astfel î ncât să expire mai rapid pentru a r educe
șansele de a fi citite de un terț neautorizat. O sesiune utilizator poate fi folosită de oricare
user care cunoaște modul de funcționare al cookie -urilor. Cookie -urile nu se distrug
neapărat când se î nchide fereastra de browser sa u când se acceseasă o pagină nouă. Din
acest motiv, orice alt user cu acces la calcu latorul userului poate reutiliza o sesiune
existentă.
Cookie-uri cu flagul HTTP Only inactive
Cookie -urile având flagul HttpOnly sunt create de un server și au o valoare de
securitate. Ele n u pot fi citite din și scrise în limbajele de scripting la nivel de client precu m
JavaScript, aceste posibilități existâ nd numai pe partea de server. Dacă flagul HttpOnly nu
este setat sau cookie -ul este creat cu JavaScript (la nivel de client) , cookie -ul poate fi citit
și scris atât pe client cât și pe server. Codul de aplicație la nivel de client, precum
JavaS cript, poate citi conținutul cookie -ului. Un atacator poate exploata această
vulnerabilitate și captura cookie -uri prin intermediul unui s cript inje ctat. Aceste date pot fi
utilizate pentru a construi un atac.
Mecanisme slabe sau inexistente de validare a input -ului utilizator
Deși reprezintă o practică comună pentru apli cațiile web să verifice drepturile de
acces înainte de a afișa/ oferi functionalitățile către utilizator prin interm ediul formelor web,
ar trebui să fie de asemenea o practic ă comună revalidarea autentifică rii userului la
anumite puncte importante de acces într-un sit e web. Daca revalidarea user id -ului și a
cereri lor acestu ia nu sunt revalidate , se cre ează posibilitatea ca un atacator să falsifice
cererile dintr -o sesiune ex istentă pentru a accesa informaț ie neautorizată. De exemplu ,
într-o aplicatie web, unui user îi poate fi cerut să se autentifice doar pentru a obține ac cesul
la paginile protejate ale aplicației , apoi i se poate cere să se reautentifice când selectează
clasa de tranzacții pe care doreș te s-o execute.
În plus, tot ce introduce utilizatorul trebuie filtrat pent ru a restricționa orice
informaț ie care nu est e cerută de aplicaț ie. Aceasta include orice șir de caractere sau
grupuri de caractere , în special caractere de control ca re pot fi utilizate pentru a obț ine
acces neautorizat.

Modalit ăți de asigurare a securit ății web -siteurilor

15
Situaț ia securit ății site-urilor web in Româ nia
Conform analizelor efectuate de CERT -RO, in 2014 , un procent de 24% din totalul
adreselor de IP alocate spațiului rom ânesc au fost implicate în cel puțin o alertă de
securitate. Din aceste alerte, mai bine de jumatate se referă la sisteme info rmatice
neconfigurate corespunză tor, nes ecurizate sau vulnerabile.
Conform aceluiaș i raport, un număr de 10759 de domenii .ro au fost compromise,
în creștere cu 5% față de anul 2013.
Concluziile CERT pentru spaț iul ciberneti c românesc sunt urmă toarele:
– se constată o diver sificare a tipuril or de amenință ri informatice
– cea mai mare parte a alertelor primite sunt legate de sisteme configurate
necorespunză tor, precum ș i de sisteme infectate cu malware care fac parte din dive rse
rețele de tip botnet
– echipamente care fac parte din categoria Internet of Things ( imprimante, camere
web, smartphone, smart TV) , odată conectate la internet devin ț inta unor atacuri
informatice
– o serie de organizații din România a fost ținta unor atacuri informatice complexe
de tip Advanced Persistent Threat, lan sate de grupări din exteriorul țării.

Modalit ăți de asigurare a securit ății web -siteurilor

16
Capitolul III. Elemente de securitate la nivel de server
Elemente de securizare a serverului web Apache
Serverul Web reprezintă o componentă esențială a oricărei aplicații web.
Elemente importante:
Document root Direct ory: /var/www/html sau /var/www
Fișierul de configurare principal: /etc/httpd/conf/httpd.conf (RHEL/CentOS/Fedora)
sau /etc/apache/apache2.conf (Debian/Ubuntu).
Port HTTP implicit: 80 TCP
Port HTTPS implicit: 443 TCP
Testare setări si sintaxa ale fișierului de configurare Configuration: httpd -t
Access Log files of Web Server: /var/log/httpd/access_log
Error Log files of Web Server: /var/log/httpd/error_log

Reguli de bună practică

Mențineți o versiune câ t mai recentă , cu ultimile patch -uri aplicate serverului web
Este considerată o bună practică să se upgr adeze la ultima versiune stabilă. Î n acest
fel se va asigura că aplicațiile vor rula in modul cel mai sigur. Comunitatea de developeri
Apache lucrează permanent la corectarea proble melor legate de securitate, creând versiuni
noi și îmbunătăț ite a serverului web. Pentru a verifica versiunea de Apache, se poate utiliza
urmatoarea comand ă: httpd –v
Ascundeți versiunea de Apache si sistem de operare din erori
La instalarea Apache, se afișează versiunea serverului web si numele sistemului de
opera re în erori, după cum se observă î n figura de mai jos:

Fig. 4 – Afișarea versiunii serverului web în mod implicit
Aceasta poate fi considerat ă o vulnerabilitate. Pentru a corecta aceasta, sunt
necesare c âteva schimb ări în fișierul de configurare principal. Se recomand ă inactivarea
signaturii cu urm ătoarea modificare:
# vi httpd.conf ServerSignature Off

Modalit ăți de asigurare a securit ății web -siteurilor

17
Dezactiva ți directory listing
Implicit, Apache listează conținu tul directorului Document root î n absența unui
fișier index. Cu alte cuvinte, dacă fișierul index : index.html sau index.php nu este
disponibil , atunci oricine poate vedea toate fișierele și subdirectoarele listate in browser.
Aceast a cre ează o vulnerabilitate pentru că atacatorul poate analiza codul sursă in vederea
descoperirii unor breșe de securitate sau pentru a obține mai multe informații despre o
aplicație , cum ar fi conectarea la baza de date, parole către alte sisteme; din ac est motiv
este mai bine ca directory listing -ul să fie inactivat.

Fig. 5 – Listarea directoarelor în absen ța unui fi șier index
Pentru a inactiva directory listing se utilizeaz ă directiva Options din fi șierul de
configurare pentru un director specific. Pentru aceasta trebuie sa cre ăm o modificare în
fișierul httpd.conf sau apache2.conf :
<Directory /var/ww w/html>
Options –Indexes
</Directory>

Fig. 6 – Mesajul afi șat în cazul c ând directory listing este inactivat

Modalit ăți de asigurare a securit ății web -siteurilor

18
Aceasta este considerată o bună practică pentru minimizarea șanselor de reușită a
unui atac web. Se poate utiliza urmă toarea comandă pentru listarea modulelor compilate :
grep LoadModule /etc/httpd/conf/httpd.conf
În mod implicit o instalare de Apache poate include un număr de module
preinstalate și activate de care nu este nevoie. Mulți web administratori tind să activeze
toate modulele, expunând î n acest fel serverul web la probleme de securitate care ar putea
exista sau ar putea fi descoperite î n viitor, legate de modulele activate.
Inactivați serviciile pe care nu le utilizați
Dacă nu sunt necesare, se recomandă inactivarea serviciilor precum CGI execution
sau symbolic links. Aceasta se poate realiza cu directiva Options din fișierul de configurare
httpd.conf și, in plus, se pot inactiva aceste servicii pentru un anumit folder.
<Directory /your/website/directory>
Options -ExecCGI -FollowSymLinks -Includes
</Directory>
Inactivați Trace HTTP Request
TRACE reprezintă o metodă de cerere HTTP utilizată pentru deb ugging care
furnizează detalii despre o cerere client. Aceasta creează o vulnerabilitate de securitate
pentru că un atacator o poate exploata și obț ine informații sensibile din headere precum
cookie -uri sau credențialele asociate web site -ului. Aceasta se poate corecta prin simpla
schimbare a directivei î n fișierul de configurare httpd.conf in TraceEnableOff .
# vi httpd.conf TraceEnable off
Inactivați Apache server -info
Dacă directiva <Location /server -info> din fișierul de configurare httpd.conf este
activată, se vor afiș a detalii despre configurația Apache. Aceasta ar putea include
informații sensibile despre setările din server, cum ar fi versiunea de server, system paths,
nume de baze de date, informații despre librării,etc. Aceste informații pot fi dezactivate
prin comentarea directivei <Location /server -info> din fișierul de configurare httpd.conf .
Nu rulați Apache cu userul de root
În mod implicit Apache rulează propriul proces cu userul nobody sau daemon. Din
motive de securitate se recomandă c a Ap ache să ruleze cu un account ne privilegiat,de
exemplu http -apache. Modificați directiva User si Group în httpd.conf.
Crearea userului și grupului Apache:
# groupadd http -apache
# useradd -d /var/www/ -g http -apache -s /bin/nologin http -apache
Apoi se va face o modificare in /etc/httpd/conf/httpd.conf și se restartează serviciul.
Se va deschide /etc/httpd/conf/httpd.conf cu vim editor , se va căuta după stringurile User
și Group și va trebui specificat numele de utilizator și grup de utilizat:
User ht tp-apache
Group http -apache
Dezactivați bannerul
Aceas tă directivă controlează dacă câ mpurile din header conținând răspunsul
serverului la o cerere a unui client conține o descriere generică a tipului de sistem de
operare și informații despre modulele c ompilate.

Modalit ăți de asigurare a securit ății web -siteurilor

19
# vi httpd.conf ServerTokens Prod
Restrictionați accesul la o anumită rețea sau adresă de IP
În cazul î n care se dorește ca site-ul să fie vizualizat doar de anumite adrese de IP
sau rețele, această funcționalitate se poate activa prin modific ările în httpd.conf de mai jos.
Introduceti adresa de rețea în directiva Allow:
# vi httpd.conf <Directory /yourwebsite> Options None AllowOverride None
Order deny,allow Deny from all Allow from 10.20.0.0/24 </Directory>
Introduceți adresa de IP î n directiva Allow:
<Directory /yourwebsite> Options None AllowOverride None Order
deny,allow Deny from all Allow from 10.20.1.56 </Directory>
Utilizați doar TLS, dezactivaț i SSLv2, SSLv3
În ceea ce privește SSL v2 , acesta este considerat învechit, fiin d înregistrate o serie
de erori criptografice asociate cu acest protocol.
# vi httpd.conf SSLProtocol -ALL +TLSv1
Dezactivați cifrurile nule sau slabe
Aceasta se poate realiza cu urmatoarea linie de cod:
# vi httpd.conf SSLCipherSuite
ALL:!aNULL:!ADH:! eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
Securizarea serverului web împotriva atacurilor de tip XSS
Fară a avea flagurile HttpOnly și Secure in headerul de răspuns HTTP, este posibil
furtul sau manipularea sesiunii de web și a cookie -urilor. Este considerată o bună pra ctică
setar ea flagului HttpOnly și Secure î n codul de aplicație.
Asigurați -vă că mod_headers.so este activat î n serverul Apache.
Adăugați urmă toarea intrare în fișierul de configurare httpd.conf :
Header edit Set -Cookie ^(.*)$ $1;HttpOnly;Secure
Restar tați Serveru l Apache.
Header edit nu este compatibil cu versiuni de Apache mai vechi de 2.2.4. Î n cazul
în care serverul Apache are o versiune mai vech e de 2.2.4, trebuie operată urmă toarea
modificar e:
Header set Set -Cookie HttpOnly;Secure
Pentru a verifica dacă aceste setă ri au efect, se poate utiliza oricare instrument
pentru detectarea informației din header primite ca răspuns de la server (cum ar fi
http://web -sniffer.net/ sau http://www.askapac he.com/online -tools/http -headers -tool/ )
Exemplu:
HTTP/1.1 200 OK
Date: Wed, 20 May 2015 07:43:32 GMT
Server: Apache
X-Powered -By: PHP/5.4.37
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache -Control: no -store, no -cache, must -revalidate, post -check=0, pre -check=0
Pragma: no -cache
Set-Cookie: PHPSESSID=542e23804787c784bb80a5dc823e3197;
path=/;HttpOnly;Secure

Modalit ăți de asigurare a securit ății web -siteurilor

20
Vary: Accept -Encoding,User -Agent
Content -Type: text/html

Elemente de securit ate a bazei de date MySQL

Limbajul PHP suportă urmă toarele baze de date (DB2, SQLite, InterBase,Oracle,
Sybase, MySQL , PostgreSQL, DBM).
Ca regulă generală, când se lucrează cu baza de date, este necesar ca toate datele
care vin din baza de date să fie filtrate.

Reguli de bun ă practic ă
În spatele oricarei aplic ații web serioase se află o bază de date care stochează detalii
relevan te despre input -ul utilizatorilor, detalii despre login sau navigare pe site.
Install sau upgrade la ultima versiune
Primul lucru care trebuie făcut în securizarea unui server de bază de date este să se
stabilea scă dacă ultima versiune stabilă este instalat ă.
Pentru a determina ce versiune de MySQL este instalat ă se poate utiliza urmatoarea
comand ă:
$ mysql
Aceasta va returna versiunea bazei de date :
Server version: 5.0.27 –standard MySql Community Edition – Standard (GPL)
Apoi se recomandă verificarea site -ului http://dev.mysql.com/downloads , secțiunea
Current Release.
La fel ca și la Apache si ModSecurity, se va verifica dacă primele două cifre sunt
cele mai recente.
Dezactiva ți accesul de la distanță
Dacă serverul Web și baza de date rulează pe aceeași mașina fizică, cum este cazul
cel mai frecvent, nu se justifică accesul la distanță la MySQL . In general, se recomandă
dezactivarea orică rei funcționalități care nu este utilizată î n mod explicit. Acccesul la
distanță este de obicei utilizat pentru backup sau pentru taskuri administrative.
Schimbați username si parola pentru administrator
Implicit, parola administrativă pentru un install de My SQL are valoare null.
Aceasta permite accesul la baza de date cu privilegii de administrator si să se creeze noi
useri, să se asigneze sau revoce privilegii, precum ș i să se creeze sau suprime tabele. Î n
privința numel ui de utilizator pentru administrator, se știe că în MySQL acesta este numit
root. Dacă se va schimba n umai parola, hackerii care vor încerca să pătrundă î n sistem vo r
avea deja jumătate din infomaț ia de care au nevoie. Schimbați atât username -ul câ t și
parola si veți face de două ori mai difi cilă patrunderea î n sistem. Pentru a schimba numele
de administrator pentru administrator, se recomandă utilizarea urmatoarelor comenzi :
Update user set user=‟‟mynewdbadmin” where user = “root” ;
Flush priviledg es;

Modalit ăți de asigurare a securit ății web -siteurilor

21
Aici am utilizat mynewdbadmin ca noul nume de utilizator cu privilegii
administrative. Urmă torul pas este setare a parolei. Desigur, orice parolă este mai bună
decât nicio parolă. De aceea remarcăm două cazuri:
– Dacă s e va stoca parola administrativă î ntr-un tool de administrare, o parolă
generat ă aleator este adesea mai sigură decât una creată manual. De asemenea,
o parolă generată aleator este mai dificil de memorat.
– Dacă se va utiliza utilitarul MySQL la nivel de linie de comanda sau un tool de
admi nistra re a bazei de date care necesită logarea de fiecare dată când se va
administra baza de date, recomandăm utilizarea pașilor de la secțiunea :
Autentificare.
În cazul utilizării unei parole generate aleator, Gibson Rese arch Corporation (GRC)
are un ge nerator de parolă destul de performant .
Ștergeț i userii de baza de date impliciț i si creați noi c onturi pentru fiecare aplicație
Când se instalează MySQL, o serie de useri sunt creaț i. Contul de administrator
este necesar (deș i numele de utilizator și pa rola pot fi schimbate) dar pentru res tul numelor
de utilizatori, în funcție de setup -ul serverului/ bazei de date, utilizatorii im pliciți ar putea
să fie suprimați. Dacă aceș tia nu sunt esențiali pentru functionarea aplica ției ,
recomandarea este ca acești a să fie sterș i. Conturile de utilizat ori suplimentare sunt o
ocazie î n plus pentru hackeri să spargă sistemul.
Pentru a șterge conturile care nu sunt nece sare , se recomandă rularea urmă toarelor
comenzi:
mysql –u mynewdbadmin
DELETE FROM user WHERE NOT (host=”localhost” and
user=”mynewdbadmin”) ;
FLUSH PRIVILEDGES;

Comanda de mai sus va șter ge conturile implicite cu excepț ia contului de
administrator. După rularea acestei comenzi se vor putea cre a alte conturi de utilizatori, în
funcție de necesităț i. Recomandăm crearea unui cont utilizator separat pentru fiecare
aplicație care va utiliza MySQL. Î n acest fel, dacă un cont utilizator este compromis,
celelalte aplicații de pe server nu vor fi afectate.
Pentru a adă uga conturi noi, se pot utiliza urmă toarele comenzi:
mysql –u mynewdbadmin
CREATE USER apps IDENTIFIED BY „new_apps_pwd‟ ;

Ștergeț i bazele de date de tip “demo”
Install -ul implicit de MySQL vine ș i cu câteva baze de date de tip sample/demo.
Acestea sunt utile pentru testing dar de îndată ce MySQL funcț ionează la nivel optim,
bazele de da te de tip sample ar trebui șterse. Această recomandare este emisă conform
principiului conform căruia trebuie ș terse sau dezactivate funcționalitățile care nu sunt
utilizate î n mod explicit pentru funcționarea sistemului.
Pentru ștergerea bazelor de date de tip demo, se poate utiliza urmă toarea comandă:


Modalit ăți de asigurare a securit ății web -siteurilor

22
mysql -u mynewdbadmin
drop database test;

Cu aceste recomandări, considerăm ca s -a realizat un nivel rezon abil de securitate
pentru baza de date MySQL pe care să se construias că aplicația / site ul web.
In cont inuare vom trata doua chestiuni importante referitoare la lucrul cu baza de
date:
1. Expunerea credențialelor de acces la baza de date și
2. Injec ții SQL

Expunerea credențialelor la baza de date
Una din primele preocupări legate de utilizarea unei baze de date o reprezintă
credențialele de acess – username si parola. Pentru ușurință, acestea pot fi stocate intr -un
fișier numit db.inc.
<?php
$db_user = „myuser‟ ;
$db_pass = „mypass‟ ;
$db_host = „127.0.0.1‟ ; /* pentru serverul local*/
$db = mysql_connect ($db_host , $db_user , $db_pass) ;
?>
Atât myuser cât și mypass sunt informații sensibile , așa că ele cer o atenție specială.
Prezența lor in codul sursă este un risc, dar din păcate aceasta nu se poate evita. Fară aceste
informații, baza de date nu poate fi protejată cu un user și parolă. Dacă examină m fișierul
de configurare al serverului Apache : httpd.con f, se poate observa ca tipul i mplicit este
text/plain. Acesta induce un anumit risc când un fișier precum db.inc este sto cat in
interiorul document root -ului. Fiecare resursă in doc ument root are un URL corespunză tor
și pentru ca Apache nu are un anumit tip de text asociat fișierelor c u excensia inc, o cerere
pentru o astf el de resursă va returna sursa î n text clar ( tipul implicit de text) , inclusiv
credențialele de acces la ba za de date. Pentru a intra mai î n detaliu, sa considerăm un
server cu un document root de forma /www. Dacă fiș ierul db.inc este stocat in locația
/www/inc, el are propriul lui URL cum ar fi http: //site.ro/inc/db.inc (presupunând că s ite.ro
este hos tul). Accesând acest url se afișează sursa fișierului db.inc în text clar. Î n felul
acesta credențialele de acces la b aza de date riscă expunerea dacă fișierul db.inc este
poziționat î n oricare director al document root ( /www/*).
Cea mai bună soluț ie pentru acest tip de problemă este să se stocheze fișierele
asociate din declarațiile de tip include în afara document roo t-ului ( /www ). Nu este
necesar să fie stocate î ntr-un anumită loca ție din sistemul de operare pentru a le „include”
sau „cere” . Tot ce trebu ie făcut este de a se asigura că serverul web are privilegii de citire
pentru acestea. În concluzie, este un risc suplimentar să se plaseze astf el de fișiere in
document root ș i orice metod ă care î ncearcă să minimizeze acest risc fară a le loca în altă
locatie în afara document r oot este ineficientă. De fapt, î n document root ar trebui plasate
numai resurse care treb uie neapărat să fie acesibile printr -un URL.

Modalit ăți de asigurare a securit ății web -siteurilor

23
Ca ultim punct: in cazul in ca re nu se poate apela la soluț ia expusă mai sus din
motive independente, recomandarea este de a se configura serverul Apache să respingă
cererile pentru resurse de tip inc.
<Files ~ “\.inc$”>
Order allow, deny
Deny from all
</Files>
SQL Injection
Injecția SQL este una din cele mai cunoscute vulnerabilită ți din aplicațiile scrise in
PHP.
Majoritatea proiectelor web folosesc baze de date pentru a -și stoca datele. Limbajul
SQL este un standard internațional ce stabilește regulile și sintaxa comenzilor ce pot fi
transmise unui sistem de gestiune a bazelor de date (SGBD), pentru manipularea da telor
stocate. Implementarea acestuia poate să difere de la caz la caz în funcție de producă tor. În
prezent , cele mai populare SGBD -uri sunt MySQL, PostgreSQL, Microsoft SQL Server și
Oracle.
O vulnerabilitate de tip SQL Injection (injecț ie cu cod sursa S QL) apare atunci
când un atacator poate introduce orice date într -o interogare SQL transmisă unei baze de
date sau când, prin injectarea sintaxei, logica declarației este modificată în ase menea fel
încât să execute o acțiune diferită. Injecț ia SQL poate fi crucială pentru sistem dar, în ciuda
pericolului pe care îl prezintă, este cea mai frecvent întâlnită vulnerabilitate.
Prezentăm mai jos un exemplu:
Funcția PHP ce interoghează baza de date este urmatoarea:
<?php
function autentificare($user, $parola)
{
$sql=”SELECT * FROM users WHERE unername=‟$user‟ and parola =‟$parola‟)”;
Return mysql_query($sql);
…..
}
?>
Ce va introduce atacatorul în câmpul destinat numelui de utilizator :
Eu‟ OR 1=1
Exemplul de mai sus vizează un formular de autentificare ce are în spate funcția
PHP din tabel. Datorita faptului că datele de intrare, respectiv numele utilizatorului și
parola nu sunt validate (adica sa ne asigurăm că atacatorul va introduce un nume val id de
utilizator și nu alte date) atacatorul va putea insera cod SQL, în câmpul de user, astfel încât
sensul interogării SQL se schimbă complet, permițând ocolirea mecanismului de
autentificare.
Cea mai bună strategie de apǎ rare împotriva injecț iilor SQL se bazează pe
implementarea unor rutine puternice de validare a datelor de intrare, astfel încât atacatorul
să nu poată introduce alte date decât cele necesare aplicației.

Modalit ăți de asigurare a securit ății web -siteurilor

24
Între masurile specifice care pot fi implementate la nivelul bazelor de date și
aplicațiilor se regăsesc urmă toarele:
a) Utilizarea de variabile bine definite și de definiții ale coloanelor din baza de
date
Stocarea și manipularea numerelor (ID -uri de sesiune, coduri etc.) ca și numere
întregi sau ca alte tipuri numerice potrivite. Str ing-urile (varchars) ar trebui să conțină doar
caractere alfanumerice si să respingă semnele de punctuație și caracterele specifice sintaxei
SQL.
b) Atribuirea rezultatelor interogării unei variabile bine definite
Dacă aplicația caută valori numerice, at unci atribuiți rezultatul unui număr întreg,
acest lucru împiedicându -i pe atacatori să extragă informații din baza de date. De exem plu
nu ar trebui să fie posibilă obținerea și afiș area numelui unei coloane, dacă variabila c e
urmează să fie afișată în bro wser nu acceptă decât numere î ntregi. Aceasta tehnică
restricționează sever anumite atacuri.
c) Limitarea lungimii datelor
Toate șirurile de caractere ar trebui să se limiteze la o lungime potrivită scopului lor.
Un nume de utilizator, de exemplu, nu est e necesar să fie stocat și manipulat într -o
variabil ă care utilizează 25 6 de caractere. Limitarea număr ului de caractere care poate fi
introdus într -un câmp, poate împiedica în mod eficient succesul unei injec ții SQL,
reducând lungimea șirului de caractere pe care atacatorul îl poate introduce în cod.
d) Evitarea cre ării de interogări prin concatenarea de șiruri de caractere
Creaț i o funcție view sau o procedură care operează asupra variabilelor furnizate de
aplicație. Conc atenarea ș irurilor de caractere, unde interogarea este format ă direct din
datele furniz ate de utilizatori (de genul: “ SELECT something FROM table WHERE” +
variable a), este cea mai vulnerabilă la atacurile SQL Injection. Pe de altă parte, o view sau
o procedură particularizată, genereaz ă de obicei o eroare dacă primeș te date de intrare
incorecte, însă nu îi va permite unui atacator să manipuleze întreaga interogare.
e) Aplicarea sepa rării datelor și accesul pe bază de rol în interiorul bazei de date
Aplicația ar trebui sa folosească un cont care are privilegii de acces doar pentru
tabelele necesare respectivei funcții. Tabelele interne ale bazei de date, în special cele
legate de managementul conturilor și variabilele sistemului, nu ar trebui să fie accesibile.
Escaping -ul nu este sigur
mysql_real_escape_string nu este considerat sigur pentru prevenția atacurilor
de tip injectii sql.
Utilizați declarațiile parametrizate
Baza de date MySQL suportă declarațiile parametrizate. O declarație pregatită sau
declarație parametrizată este u tilizată pentru a executa aceeași declarație în mod repetat cu
eficiență ridicată. O execuție de declarație parametrizată constă în două faze: o fază
pregă titoare și o fază de execuție. În faza preg ătitoare, o declarație șablon este trimisă către
serverul de baze de date. S erverul verifică sintaxa și iniț ializează resursele interne pentru o
utilizare viitoare.

Modalit ăți de asigurare a securit ății web -siteurilor

25
Acestea sunt considerate destul de sigure. Într-o declarație pregatit ă, datele sunt
separate de comenzile SQL astfel încăt orice introduce un utilizato r este considerat ca fiind
date.

Elemente de securitate PHP

Comportamentul PHP este puternic influen țat de configurația dorită, care poate fi
setată în fișierul php.ini , de directivele de securitate Apache și de mecanismele de runtime.
Upgradați PHP la ultima versiune disponibilă
Trebuie remarcat că la momentul redactă rii acest ei lucrari, versiunea de PHP 5.4
este de -suportată în mod oficial. Aceasta înseamnă că în viitorul apropiat, dacă o problemă
de securitate va fi descope rită in ve rsiunea PHP 5.4, site -urile web care rulează pe această
versiune vor fi vulnerabile. De aceea este de importanță majoră să se facă upgrade la
versiunile de PHP 5.5 sau 5.6 .
Datele introduse de useri nu trebuie considerate de încredere
Datele trebuie vali date utilizând o metodologie adecvată sau filtrate î n prealabil.
Variabilele super glob ale care nu trebuie acceptate fă ră validare sunt $_SERVER,
$_FILES, $_COOKIE, $_GET, $_POST.
Este adevărat că nu toate datele din $_SERVER pot fi falsificat e de user, î nsă
trebuie acordată o atenție specială acelor date care privesc headerele HTTP_.
Upload -ul de fișiere
Fișierele î ncărcate de useri pot constitui amenință ri de securitate mai ales când alți
utilizator i pot downloada aceste fișiere. Se recomandă acordarea unei atenții sporite
oricăror fișiere HTML ( acestea po t servi unui atac de tip Cross Site S cripting) sau oricăror
fișiere cu extensia .php sau php.txt care pot fi utilizate î n remote execution.
PHP este proiectat să facă foarte facilă execuția codului PH P, este foarte important
pentru site -urile care rulează cod PHP să se asigure că fișierele uploadate sunt salvate
numai cu nume și extensii sanitizate.
Greșeli frecvente in procesarea $_FILES
Foarte frecvent, pe diverse site -uri se recomandă fragmente de cod PHP de genul:
if ($_FILES['some_name']['type'] == 'image/jpeg') {
//Proceed to accept the file as a valid image
}
După cum se observă, tipul de fișier nu este determinat/validat decâ t prin simpla
citire a datelor trimi se de clien t în requestul HTTP, care este creat de client. O modalitate
mai bună de validare a tipurilor de fișiere o reprezintă utilizarea clasei finfo.
$finfo = new finfo(FILEINFO_MIME_TYPE);
$fileContents = file_get_contents($_FILES['some_name']['tmp_ name']);
$mimeType = $finfo ->buffer($fileContents);
În codul de mai sus, $mimeType reprezintă o mai bună verificare a tipului de fișier.
Este adevă rat că se utilizează mai multe resurse la nivel de server dar asigură o mai bună

Modalit ăți de asigurare a securit ății web -siteurilor

26
prevenție î mpotriva trimit erii unui fișier peric ulos si eludare a codului PHP ( de exemplu în
cazul în care codul PHP detectează un fișier periculos drep t fișier î n format imagine ,
considerat ca un format sigur ).

SetHandler
Codul PHP ar trebui să fie configurat utilizâ nd directi va SetHand ler. Î n multe
cazuri aceasta este configurat utilizând o directivă de tip AddH andler. Problema este că
această directivă face ca alte fișiere să execute cod PHP, de exemplu un fișier numit
“catalog.php.tx t” va fi gestionat ca și cod PHP , care poa te consitui o vulnerabilitate de
execuție la distanță dacă “catalog.php.txt” vine de la un fișier uploadat de către un atacator.
Activa ți raportarea erorilor î n detaliu
Activați acele funcționalităti PHP care î nregistreaz ă erorile de aplicație. Adesea,
erorile de aplicație conduc la sau oferă indica ții despre posibile vulnerabilit ăți. De exemplu,
multe dintre erorile asociate cu variabila neini țializat ă register global pot fi detectate doar
prin creșterea nivelului de detal iu la care sunt afișate erorile in aplicație. Prezent ăm mai jos
un exemplu de cod PHP:
error_reporting(E_ALL); // in PHP 5.0 E_ALL | E_STRICT
ini_set(“display_errors”, 0);
ini_set(“log_errors”, 1);
ini_set(“error_log”, “/home/user/logs/app_xyz.php.log”);
Primele două linii de cod activează înregi strarea tuturor erorilor incluzâ nd
avertiz ări, erori critice, notific ări referitoare la variabilele neini țializate. A doua linie
dezactivează afi șarea erori lor astfel încât codul poate fi portat în mediile de producție în
timp ce liniile trei și patru indic ă faptul că erorile trebuie logate într-un fișier pe disc – ceea
ce reprezintă o cale facilă de a monitoriza mesajele de eroare în orice utilitar de editar e
cum ar fi vim sau less. Pentru a utiliza acest fragment de cod , el trebuie plasat la începutul
oricărui cod.
Înlocui ți Register Globals
Pe cât posibil, este recomand abil să schimba ți codul astfel încât să nu reg ăseasc ă
input -ul utilizator prin intermediu l register globals. Înainte de a dezactiva register_globals,
determinați dacă alternativele sale sunt utilizate , prin rularea unei comenzi grep asupra
întregului cod:
grep –rI “_ \(GET \|POST \|COOKIE \|SERVER \|REQUEST \)”
/home/user/app/*
Aceasta comandă caută recursiv prin toate fișierele non binare în interiorul
directoarelor specificate, căutând nume comune superglobale sau echivalentul lor,
HTTP_GET_VARS.
Cu aceasta comandă, se poate determina dacă cea mai mare parte a codului a fost
proiectat să se bazeze pe register globals. Dacă grep întoarce un număr mare de rezultate,
atunci se poate concluziona că superglobals nu sunt necesari și pot fi dezactivați în
siguran ță. Pe de altă parte, dacă aplicația este destul de mare și grep nu întoarce dec ât

Modalit ăți de asigurare a securit ății web -siteurilor

27
maxim um câteva rezultate, atunci cel mai probabil se impune un efort de modernizare a
codului.
De ce este necesară inactivarea register_globals? Pentru că permite unui atacator să
introducă un input de tip GET in coada unui URL cum ar fi:
http:// exem ple.mihai.ro ?override=1 .
Dacă în codul PHP s-ar fi utilizat variablila $override și s -ar fi omis inițializa rea ei
(prin intermediul $override=0 ), programul ar fi putut fi compromis de o asemenea
vulnerabilitate.
Setarea register_globals a fost implicită în versiunile de PHP până la 4.2.0.
Evitați $_REQUEST
Utilizarea $_REQUEST nu este recomandată pentru că include nu numai date GET
și POST dar și cookie -uri trimise de cererea http. To ate aceste date sunt combinate î ntr-un
array, facând aproape imposibil ă determinarea sursei datelor. Deși superglobalul
$_REQUEST se utilizează cu ușurință la accesarea inputului din surse multiple, el ascunde
sursa actuală a datelor. O asemenea opacitat e poate conduce la vulnerabilită ți și buguri
cauzate de un input non standard. De exemplu, un cookie poate suprascrie input -ul așteptat
prin intermediul GET sau POST. De aceea este mai sigur ca utliza rea lui $_REQUEST să
fie evitată . Din fericire, detectarea utilizării lui se poate face uș or cu comanda :
grep –rI “\$_REQUE ST” /home/user/app/*
Dezactivați Magic Quotes
Dacă in php.ini opțiunea magic_quotes_gpc este activată, toate variabilele GET,
POST si cookie -urile trimise aplicației sunt automat filtrate pentru a eluda caracterele
speciale cum ar fi backslash \ si carac terele speciale de citare ( single quotes si double
quotes). Utilizarea lui magic_quotes_gpc este de a face stringurile mai sigure pentru
utilizarea directă î n interogări SQL.
În literatura de specialitate există încă o dezbatere aprinsă asupra meritelor utilizării
magic_quotes_gpc, însă pentru a îmbunătâți securitatea, recomandarea cea mai sigură este
de a dezactiv a această funcționalitate ș i să se adauge o funcție de normaliz are pentru a
procesa toate intrările î n funcție de nevoile aplicației.
O funcți e de normalizare – ceva ce se furnizează – asigură ca valorile de intrare
sunt consistente independent de setările PHP.
Preveni ți Cross -Site Scripting XSS
Verificarea î mpotriva atacurilor de cross -scripting este dificil de automatizat pentru
că cere de m ulte ori verificarea manuală a tuturor formelor și parametrilor de intrare care
sunt afișate de utilizator.
Exist ă totuși o metod ă care poate simplifica procesul: spide rul XSS. Spiderul XSS
este un c aracter special cum ar fi >///\0/\\\< care conține toate caracterele care dacă sunt
lasate verbatim pot cauza prob leme. Prin completarea tuturor câmpurilor formularelor ș i
parametrilor GET cu acest marker se pot detecta locurile unde conținu tul nu este gestionat
corespunză tor de către aplicație.
În cazul unui input care este non validat, spiderul ar putea cauza blocajul codului
HTML , identificând astfel o problemă XSS. Cond iția de bază pe care se interoghează

Modalit ăți de asigurare a securit ății web -siteurilor

28
spiderul este ca atributele câmp ului, cum ar fi valoarea , sunt î n mod normal incluse în
interiorul cara cterelor de citare simple sau duble. O cotație necodată va cauza terminarea
prematură a unui atribut și > terminarea tagului . Datele imediat urmă toare vo r fi afișate pe
ecran, demonstrâ nd un potențial XSS.
Separat de validarea XSS, spiderul conține alte caractere speciale care , dacă sunt
lasate aș a, pot declanșa SQL I njection sau bloca Ja vaScript , ca de exemplu \ si „, facându -l
un marker de validare complet. În concluzie, câ nd se testeaza formele web, decâ t să se
plaseze valori va lide , se recomandă popularea câmpurilor form -ului cu spiderul și să se
identifice ce ef ect are asupra paginii generate. Rezultatele pot fi surp rinzătoare î n unele
cazuri.
Îmbunăt ățiți securitatea interogărilor SQL
Spre deosebire de m ăsurile anterioare, securizarea interogă rilor S QL cere mai mult
efort pentru că este adesea dificil să se identifice dacă o intergare poate face obiectul unei
injec ții SQL sau nu. Variabilele transmise î n interogare pot ve ni din oricare parte a codului
și nu va exista o alt ă opțiune decât identi ficarea originii lor ș i determinarea conținutului lor.
Oricând este posibil, se recomand ă utilizarea declarațiilor pregă tite care nu numai că
accelerează execuția , dar opresc și valorile dinamice plasate î n interogare să fie utilizate ca
orice altceva deca t valori.
pg_prepare($db, “qry1”, „SELECT * FROM users WHERE id=$1‟);
pg_execute($db, “qry1”, array((int)$_GET[„id‟]));
Când nu se pot utiliza interogări preg ătite – care sunt valabile pentru extensiile
MySQL si SQLite – se recomandă mare atenț ie la val idarea parametrilor.
Preveni ți Injec ția de Cod
Vulnerabilitățile de tip injecț ie de cod sunt foarte periculoase. Orice oper ațiune care
ar putea expune aplicația la aces t tip de atac ar trebui auditată cu mare atenț ie.
Primul ș i cel mai s implu pas pentru evitarea injecț iei de cod este examinarea
modului de uti lizare a contructorilor de incărcare de cod ș i funcțiilor. Din nou, comanda
grep este un instr ument foarte util pentru această sarcină .
grep –riI “\(include \|require \|eval \)” /home/user/app/*
Coman da grep de mai sus efectuează o căutare ( non case sensitive) pentru a
identifi ca toate mecanismele utilizate î n mod normal i n PH P pentru a executa cod. După ce
rezultate le au fost returnate, se va urmă ri dacă se utilizează calea completă pentru
include/require si că asemenea declarații să omită variabile î nglobate (embedded).
Dacă este nevoie de componente dinamice, se recomandă utilizarea constantelor
care nu pot fi injectate în script.
În final se va urmari ca include si require să s e utilize ze doar pentru codul PHP. O
eroare frecventă este utilizarea lui in clude sau require pentru a incărca date î n text clar cum
ar fi header sau footer, când aceasta se poate face cel mai bine cu readfile().
Renuntați la utilizarea funcției eval()
Funcția ev al() este utilizată la evaluarea unui string ca PHP.
De exemplu:

Modalit ăți de asigurare a securit ății web -siteurilor

29
<?php
$name = „M ihai‟ ;
$string = „echo “Hello, $name”; „ ;
eval($string) ;
?>
Codul de mai sus execută $string ca și când ar fi cod PHP si asta este echivalent cu
urmatorul:
<?php
$name = „M ihai‟ ;
echo “Hello, $name “;
?>
Deși este util ă, eval() este foarte periculoasă când este utilizată cu date corupte. De
exemplu dacă $name este corupt, un at acator poate executa cod la întâ mplare cod PHP:
<?php
$name = $_GET([„name‟] ;
eval($name) ;
?>
Ca regul ă generală, este rec omandăbil să se evite eval(). În cele mai multe cazuri,
este mult prea dificil de validat și chiar și cea mai mică greșeală poate conduce la injecț ie
de cod. Dac ă chiar trebuie utilizat eval(), conținutul de e valuat se recomandă să nu conțină
vreo variabilă care provine din sau poate fi m odificată de user input. Această funcție este
un bun candidat pentru rev izia de securitate a codului PHP .
Urm ăriți numele dinamice
Cel mai dificil de detectat într-un audit de securitate este utilizarea nu melui pentru
variabile dinamice , funcții , metode și propriet ăți. În aceste cazuri, obiectul de executat sau
evaluat se poate schimba în funcție de situație. Localizarea acestor cazuri se poate face în
parte prin utilizarea c omenzii grep:
grep –rI “\$[_a-zA-Z][A -Za-z0-9_]*[:space:]*(“ /home/user/app/*
Comanda grep menționată mai sus caut ă stringul $ urmat de un identificator PHP
valid( care const ă într-un caracter underscore sau o liter ă ca prim caracter urmat de orice
număr de litere, numere sau underscore) urmat de orice număr de spa ții opționale și
termin ând cu paranteze p ătrate . Aceasta ar trebui s ă detecteze funcția cea mai dinamic ă și
apelurile metodei , cu excep ția acelor a unde vari abila cu numele respectiv și paranteze le
sunt pe linii separate ( pentru c ă grep func ționează doar linie cu linie).
$user(“val”); // va fi detectata
$user
(“val”); // nu va fi detectata
Se mai pot utiliza expresii regul ate mai complexe sau scripturi î n Perl pentru a
identifica mai multe varia ții ale metodelor și funcțiilor cu nume dinamice.

Modalit ăți de asigurare a securit ății web -siteurilor

30
Minimiza ți utilizarea comenzilor externe
O anumită parte a aplicațiilor PHP apel ează aplicații externe. Se recomandă
validarea input -ului utilizator care este trimis funcțiilor exec(), system() , pope n() ,
passthru() si proc_open() . Încă o dată , utiliza rea comenzii grep poate fi utilă aici: se poate
identifica executarea comenzii foarte rapid:
grep –i “\(exec \|system \|popen \|passthru \|proc_open \)[:space:]*(“ *.php
Ascundeț i controalele administrativ e
Aceast ă masur ă asigur ă protec ție împotriva scripturilor automate de scanare a
vulnerabilit ăților care sunt proiectate sa ver ifice anumite loca ții sau să caute anumite
stringuri.

Elemente de s ecuritate la nivel de client (JavaScript, CSS, HTML )

Se recomandă utilizarea celor mai recente versiuni de browser din aceleași motive
menț ionate și pentru componentele server: se vor evita o se rie de vulnerabilită ți apărute la
versiunile anterioare ș i care, cel mai probabil, sunt fixate în ultima versiune disp onibilă. De
asem enea este foarte util ă testarea modului de func ționare a site -ului web pe browsere
diferite și chiar pe versiuni diferite ale aceluia și browser.
Se recomandă analizarea detaliat ă a codului de JavaScript executat la nivel de client.
Utiliz area JavaS cript este foarte utiliz ată în cazul formularelor HTML , sau când se
dorește să se evite transmiterea datelor incomplete către aplicație. Se recomandă ca
informațiile primite de la browser să fie totdeauna testate și filtrate prin cod JavaS cript la
nivel de client. În scopul analiz ării codului javascript, se poate utiliza JavaScript Security
Analyzer ( JSA ) sau Firebug ( dacă browserul este Mozilla Firefox). JavaScript Security
Analyzer poate detecta probleme de phishing prin open redirect, html 5 notification api,
html 5 injec ții sql la nivel de client, email attribute spoofing. Acest tool nu necesit ă
configur ări speciale, este simplu și rapid.
Toolul se poate descă rca de la adresa:

http://www -01.ibm.com/software/awdtools/appscan/standar d/

Mod de func ționare: JSA parcurge toate URL -urile v izitate de AppsScan web
crawler, una câ te una. Pentru fiecare URL, JSA salvează tot fluxul de răspunsuri HTTP.
Urmă torul pas este revizuirea punctelor de intrare Java Script în URL -urile vizitate și aplică
o serie de reguli de analiz ă specific ă.

Modalit ăți de asigurare a securit ății web -siteurilor

31
Capitolul IV. Cookie -uri și Managementul Sesiunilor
În acest capitol vom face o trecere în revistă a principalelor elemente care
influențează funcționarea cookie -urilor, gestiunea sesiunilor , precum și a protocoalelor
SSL și TLS.
Cookie -uri
Un cookie HT TP sau browser cookie reprezintă un fișier conținând text ( litere și
cifre ) si care este stocat pe un ca lculator care accesează un site web. Cookie -urile
reprezintă un element important pentru navigarea pe internet, acestea contribuind la
imbunătățirea experienței de browsing a site -urilor web. Unele din cele mai cunoscute
site-uri precum Google, Yahoo sau Y outube utilizează cookie -uri.
Un număr foarte mare de atacuri bazate pe cookie -uri exploatează punctele slabe
asociate cu versiunile mai vechi ale browserelor.
Cookie -urile sunt create atunci când browserul utilizat pentru navigarea pe internet
afișează un site. Site -ul web trimite i nformații către browser (incluzâ nd în headerul de
răspuns câmpul Set -Cookie ) și acesta din urmă cre ează un fișier în format text. În
momentul în care site -ul web este vizitat din nou, browserul trimite acest fișier către site.
Un browser cookie sau u n HTML cookie reprezintă un fișier conținând text (litere
și numere ) , deseori codifi cat, care se află pe un calculator.
Elementele unui cookie sunt urmă toarele:
Set-Cookie: nume=valoare; expires=data_calendaristica; path=cale ;
domain=domeniu ; secure ; httponly;
Expires = reprezintă data și timpul când cookie -ul va expira și va fi ș ters de pe disc .
Domain = numele serverului care a trimis cookie -ul.
Path = reprezint ă un grup de URL -uri aparțin ând domeniului asociat cu cookie -ul.
Secure = cookie -ul este transmis dacă comunicarea s -a realizat prin protocolul HTTPS.
HttpOnly = forțează browserul sa nu permită limbajelor de scripting ( JavaScript, VBScript)
să acceseze cookie -urile via document.cookie object.
Browserul va trim ite serverului î n headerul de HTTP, o linie de forma:
Cookie: nume=valoarel; nume=valoare;nume=valoare…
În PHP cookie -urile se pot crea utiliz ând funcția setcookie() .
Exemplu :
<?php
setcookie(‟‟culoare_noua‟‟ , ‟‟verde‟‟ );
Echo ‟‟Un cookie de alta culoare‟‟.$COOKIE[‟‟culoare_noua‟‟] ;
?>
Ștergerea unui cookie în PHP se poate face cu urmă torul cod:
//se asigură că cookie -ul expiră î n browser
setcookie ($name, "", 1);
// reprezintă modul standard de a șterge un cookie ; astfel nu se pot stoca cookie -uri false
setcookie ($name, false);
// codul următor șterge cookie -ul din script ; alternativ se utilizează time() -3600 pentru
//expirare
unset($_COOKIE[$name]);

Modalit ăți de asigurare a securit ății web -siteurilor

32
Cookieurile pot fi :
– De sesiune : Acestea nu mai sunt reț inute după ce utilizatorul iese de pe website .
– Persistente : Acestea sunt memorate și refolosite de fiecare dată când utiliz atorul
revine pe acel website, însă pot fi ș terse oricând de utilizator.
Un tip sepcial de cookies î l constituie Flash cookies – în cazul î n care Adobe Flash
este instalat, s -ar putea ca unele fișiere de mici dimensiuni să fie stocate local de către
website uri care conțin Flash, cum ar fi clipuri video. Aceste fișiere sunt cunoscute sub
denumirea de Local Shared Objects sau cookie -uri Flash. Acestea pot stoca date care sun t
conținute de obicei de cookie -urile obiș nuite. Când cookie -urile obișn uite sunt șterse
utilizând opț iunile din browser, cookie -urile flash nu sunt afectate. Mai mult, ele pot servi
ca backup pentru cookie -urile obișnuite. De aceea , un web site care a trimis către
calculatoru l local un cookie poate recunoaște utilizatorul la următoarea vizită dacă cookie –
urile obișnuite au fost ș terse dar un backup al lor există î n cookie -urile flash. Cu toate
acestea, cookie -urile flash pot fi controlate. Site -ul oficial al Adobe oferă instrumente
pentru a controla cookie -urile flash. Î n plus , utilizatorii de Firefox pot obț ine un add -on
pentru a detecta si șterge cookie -urile flash.
Serializarea datelor
Nu se recomand ă serializarea datelor stocate î ntr-un cookie pe ntru că aceasta poate
fi manipulată cu usurintă .
Atributul Http -only
Este r ecomandată utilizarea cookie -urilor HTTP -only. Acestea sunt disponibile în
limbajul PHP începâ nd cu versiunea 5.2. Pentru a utiliza aceste cookie -uri este necesară
setarea manuală a acestora .
Cele mai recente browsere suporta cookie -uri HTTP -only. Aceste cookie -uri sunt
acces ibile exclusiv via cereri HTTP ș i nu JavaScript , deci snipeturile XSS nu le pot accesa.
#prototype
bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [,
string $domain [, bool $secure = false [, bool $httponly = false ]]]]]] )
#usage
if (!setcookie("MyPHPSessionID", $secureRandomSessionID,
$generalTimeout, $applicationRootURLwithoutHost, NULL, NULL,true))
echo ("nu se poate seta HTTP -only cookie");

Când Http Only este setat ca True, cookie -ul va fi accesibil numai prin intermed iul
protocolului HTTP. Aceasta înseamnă că respectivul cookie nu va fi accesibil limbajelor
de scripting precum JavaScript.
Atributul Secure
Atributul Secure = True seteaz ă browserul s ă trimită cookie -uri numai printr -o
cone xiune criptată de tip HTTP S ( SSL/TLS ). Acesta reprezintă un mecanism de protecție
a sesiunii ș i este obligatoriu pentru a proteja împortiva detectă rii PHPSESSIONID -ului prin
atacuri de tip „Man in the Middle”. Setarea aplicațiilor web pentru a util iza nu mai HTTPS
pentru comunicații nu oferă protecție împotriva detectării id -ului de sesiune dacă atri butul

Modalit ăți de asigurare a securit ății web -siteurilor

33
Secure nu a fost setat ca True – browserul web a fost „păcă lit” să afișeze id -ul de sesiu ne
peste o conexiune HTTP necriptată . Atacatorul poate intercept a si manipula t raficul
userului luat ca victimă si injecta o referință HTTP necriptată către aplicația web, fapt care
va forța browserul web sa submită id -ul de sesiune î n text clar.
Cookie -urile sunt stocate pe hard -disk-ul calculatorului userului si val orile acestora
pot fi obținute de persoane rău intenț ionate. Din acest motiv se recomandă criptarea lor cu
ajutorul funcției Mcript, din biblioteca libmcrypt. Aceasta bibliotecă nu face parte din
distribuția standard PHP; din ac est motiv, ea trebuie descar cată de la
http://mcrypt.hellug.gr . De asemenea, se poa te utiliza criptarea PHP utilizâ nd funcțiile
MD5() si crypt(), funcții disponibile in distributia standard PHP.

Managementul sesiunilor in PHP

În PHP , o sesiune rep rezintă un interval de timp î n care o serie de scripturi,
accesate î n momente diferite, pot stoca și utiliza info rmații comune. O sesiune se iniț iază
atunci când codul PHP apelează funcția session_start și se încheie atunci când userul
închide browserul.
O sesiune se î ntinde pe mai m ulte request -uri (pe parcursul a mai multor accesă ri
ale diferitelor pagini), iar pentru a identifica existenț a unei sesiuni limbajul PHP poate
utiliza cookie -uri sau parametrii GET in URL -ul paginii.
În momentul î n care codul PHP apelează funcția session_start pentru prima dată
într-o sesiune de lucru, se trimite un cookie către browserul clientului (un header de tipul
'Set-Cookie' ).
Fiind vorba de un cookie, este necesar ca func ția session_start să fie apelată
înaintea oricărei instrucțiuni ce a fișează ceva (print, echo, etc .) si înaintea oricărui cod
HTML (deci inainte de tagul <html> ). Cookie -ul trimis către client conține un identificator
de sesiune care este unic, numit Session ID, cu ajutorul că ruia se poate face distin cție între
sesiunea curentă de lucru ș i celelalte sesiun i ale altor useri care accesează web site -ul in
acel moment.
Dacă browserul userului nu acceptă cookie -uri, identificatorul de sesiune va fi
trimis printr -un parametru GET, î n forma :
script.php?PHPSESSID=[session_id]
(se va face practic un redirect automat către aceeași pagină avâ nd specificat
parametrul in URL).
În pasul următor programatorul trebuie să includă manual acest identificator î n
toate celelalte link -uri de pe pagină, asigurându -se că toate paginile vor fi accesate cu acest
parametru.
Aceste situații sunt însă destul de rare, iar î n exemplele care urmează vom
considera ca browserele au coo kie-urile activate, astfel incât să nu fie necesar să
transmitem manual Session ID -ul. Din motive de securitate este mai bine să se activeze
opțiunea de utilizare a cookie -urilor pentru a pasa în acest mod ID -ul. Dacă se utilizează

Modalit ăți de asigurare a securit ății web -siteurilor

34
directiva session.use_only_cookies având valoarea ON pentru depozitarea identificatorului
de sesiune la nivel de client s e vor putea utiliza numai cookie -urile, prevenind î n acest fel
orice posibil atac care folosește id -ul de sesiune in URL -uri.
În momentul în care se accesează din nou aceeași pagină, sau o alta din cadrul
aceluiaș i web site, identificatorul de sesiune est e trimis de către browser (la fel ca oric e
cookie existent in browser). Î n felul acesta, orice script PHP are a cces la Session ID -ul
creat iniț ial si poate accesa sesiunea corectă.
Mai este nevoie de ceva î nsă: pentru a putea accesa informațiile persistat e, un script
trebuie să apeleze funcția session_start.
De această data î nsă, existând deja un Session ID disponibil (creat anterior), PHP
va ști că nu trebuie creată o sesiune nouă, ci continuată una existentă .
Așadar, session_start are două funcționalit ăți importante: să deschidă o sesiune
nouă (atunci când nu există un Session ID) sau să continue o sesiune existentă, identificată
printr -un Session ID.
Funcțiile principale de manipulare a sesiunii sunt prezentate mai jos. Există o
funcție care returneaz ă valoarea Session ID -ului curent: session_id. Aceasta este utilă când
este nevoie ca identificatorul să fie transmis in URL. Alternativ se poate utiliza constanta
globala SID. De asemenea există o funcție care permite î nchiderea unei sesiuni pe
parcursul execuției scriptului curent. Închiderea sesiunii înseamnă oprirea posibilităț ii de a
scrie/citi date, nu ștergerea datelor salvate deja. Datele ramân salvate și pot fi accesate din
nou după apelarea funcției session_start.
<?php
session_start();
echo se ssion_id();
echo SID; // are acelaș i efect ca instrucțiunea anterioară
…..
session_write_close(); // permite î nchiderea sesiunii in scriptul curent
?>

Accesarea datelor
Din momentul în care codul PHP apeleazǎ funcția session_start, acesta poate inc epe
deja să stochez e date care vor fi persistate. Î n limbajul programatorilor P HP se utilizează
expresia "să păstreze date î n sesiune" sau "pe sesiune". Aceste date sunt gestionate de PHP
(salvate, preluate, etc) .
Salvarea datelor pe sesiune se face prin intermediul vectorului super -global
$_SESSION.
Există și o funcție ce permite î nregi strarea datelor pe sesiune (nu ș i modificarea lor),
dar folosirea acesteia nu este recomandată. Funcția se numește session_register și a fost
marcată ca obsolete in versi unea 5.3 a limbajului PHP.
Citirea datelor persistate se poate realiza tot prin intermediul $_SESSION.

Modalit ăți de asigurare a securit ății web -siteurilor

35
<?php
session_start();
// se inregistreaza date in sesiune
$_SESSION[ 'text' ] = 'Mesaj persistent';
// citirea din sesiune
echo $_SESSION[ 'text' ];
// pe sesiune se pot inregistra cam toate tipurile de date
$vector = array('p', 'q' , 'r');
$_SESSION[ 'stringuri' ] = $vector;
// accesez o parte din vectorul stocat
echo $_SESSION[ 'stringuri' ][0];
// se afisează p
echo $_SESSION[ 'stringuri' ][2];
// se afisează r
?>
Scrierea și citirea datelor de sesiune se realizează practic la fel ca manipularea unui
associative array ( vector asociativ), ceea ce face această funcționalitate uș or de folosit.
Mecanismul implicit de management a sesiunii in PHP este consider at destul de
sigur, valoarea ID -ului de sesiune pentru PHPSessionID este generată aleator , dar stocarea
datelor despre sesiune nu mai este atât de sigură.
Fișierele corespunză toare sesiunii sunt stocate in direct orul temp care este, i n
general, accesibil la citire ș i scriere.
Preven irea atacurilor de tipul deturnă rii de sesiune ( session hijacking )
Este considerată o bună practică să se asocieze id -ul de sesiune cu adresa de IP ,
ceea ce ar preveni majoritatea s cenariil or de deturnare de sesiune. Totuși, această practică
nu este atâ t de eficientă dacă userii site -ului web utilize ază un tool de anonimizare a
IP-ului cum ar fi TOR sau GOSTIP.
Pentru asocierea IP -ului cu datele de sesiune, se poate stoca IP -ul cli entului în
momentul î n care sesiun ea este creată pentru prima dată .
Urmă torul fragment de cod returnează adresa de IP:
$IP = getenv ( "REMOTE_ADDR" );
Invalidarea ID -ului de sesiune
Se recomandă invalidar ea sesiunii prin resetarea cookie -urilor oricând se obs ervă că
două adrese de IP sunt înregistrate. Î n plus , se poate notifica userul când site -ul este accesat
de pe două adrese IP diferite.
Afisarea ID -ului de sesiune
ID-urile de se siune sunt considerate confidenț iale și nu ar trebui expuse nicăieri ,
mai ales când este legată de un user logat la website. De asemenea , nu se recomandă
utilizarea URL -ului ca mediu de tra nsmitere a datelor de sesiune. Î n plus, se recomandă
utilizarea protocolului TLS pentru transferarea informațiilor l egate de ID -ul de se siune,
oricând sesiunea utilizatorului privește date confidențiale.

Modalit ăți de asigurare a securit ății web -siteurilor

36
Fixarea sesiunii
Se referă la invalidarea ID -ului de sesiune după ce userul se loghează la site
utilizând session_regenerate_id() .
Expirarea sesiunii
O sesiune ar trebui să expire du pă un anumit timp de inactivitate și chiar după un
anumit timp de ac tivitate. Procesul de expirare î nseamnă invalidarea sesiunii și crearea
uneia noi.
Timeout pentru inactivitate
Se recomandă expirarea sesiunii după 30 de minute de inactivitate. Aceasta se
recomandă pentru a ajuta utilizatorii logați pe computere partajate care uită să se delogheze.
De asemenea, ajută împortiva deturnă rilor de sesiune.
Timeout general
De asemenea, nu se recomandă stocarea numelui de utilizator / parolelor sa u a altor
informații relevante î ntr-un cookie.
Măsuri suplimentare la nivel de client pentru managementul sesiunii
Aplicațiile Web pot completa mă surile descrise mai sus cu altele al nivelul de cli ent.
Protecț iile la niv el de client, de obicei verifică ri de cod Java Script nu consituie totuși o
garanție î mpotriva oricărui atac , ci introduce un alt nivel de apǎrare pe care atacatorii
trebuie sa -l treacă.
Timeout de la login -ul iniț ial
Aplicațiile Web pot utiliza cod JavaScript în pagina de login și pot măsura
interva lul de timp de când pagina a fost încărcată și ID -ul de sesi une a fost primit. Dacă o
nouă î ncercare de login este detectată după un anumit interval de timp, codul client poate
notifica userul că intervalul maxim de timp pentr u login a fost depășit si va r eîncărca
pagina de login, în acest fel generâ ndu-se un alt ID de sesiune. Acest gen de prote cție
suplimentară va produce reî nnoirea PHP Session ID -ului, evitând situațiile de tipul : o
sesiune anterioară (setată manual) este reutilizată de urmă toare a victi mă care utilizează
același calculator, de exemplu, î n atacuri de tipul fixarea sesiunii (session fixation).
Fortarea logout -ului de sesiune la î nchiderea web browserului
Aplicațiile web pot utiliza cod JavaScript pentru a cap tura toate evenimentele de ti p
închidere de tab sau de ferestre în browser si să ia măsuri adecvate pentru î ncheierea
sesiunii curent e înainte de î nchidere a browserului, simulând astfel î nchiderea manuală a
sesiunii de către utilizator utilizâ nd butonul de logout.
Dezactivarea ses iunilor inter -taburi ale web browserului
Aplicațiile web pot utiliza cod JavaScript de îndată ce userul se c onectează și o
sesiune este iniț iată pentru a forța userul să se re -autentifice d acă deschide o nouă fereastră
sau un nou tab în aceeaș i aplicație.
Acest mecan ism nu se poate utiliza dacă ID -ul de sesiune este t ransmis prin
intermediul cookie -urilor , pentru că acestea sunt partajate de toate ferestrele și taburile
dintr -un web browser.

Modalit ăți de asigurare a securit ății web -siteurilor

37
Delogarea automată a clientului
Și în această situație se poat e utiliza cod JavaScript pentru a deloga automat userul
de la sesiunea client , după expirarea timpulu i de inactivitate, prin redirecț ionarea userului
către pagina de logout. Avantajele î mbun ătățirii funcționalitații de timeout la nivel de
server c u cea la nivel de client este că userul poate vedea că sesiunea a luat sfarșit din
cauza inactivita ții sau chiar să fie notificat î n avans că sesiunea este pe punctul să expire ,
prin intermediul unu i ceas afișat în pagină . Această abordare ajută userul în evitarea
orică rei pierderi din cauza deconectă rii de la paginile web când sesiunea la nivel de server
expiră.

Măsuri pentru detectarea atacului asupra sesiunii

Detectarea atacurilor de tip ghicire ID de sesi une și atacuri prin forta brută.
Se recomandă ca site-urile web să poată detecta dacă un atacator aplică un atac de
tip forță brută, lansând î n mod succesiv cereri multiple de la una sau mai multe adrese de
IP. O altă modalitate de ghicire a ID -ului de sesiune o reprezintă utilizarea unor
instrumente de analiză statistică care sa analizeze predictabilitatea ID -ului de sesiune.
Asociarea ID -ului de sesiune de alte proprietăț i ale userului
Se recomandă asocierea ID -ului de sesiune cu alte atribu te/proprietăț i ale userului
cum ar fi adresa IP, certficatul digital sau User -Agent.
Această practică este recomandată in scopul protejării î mpotriva unor atacuri de tip
session hijacking sau session guessing . Orice schimba re sau anomalie asociată schimbării
acestei c ombinaț ii repre zintă un bun indicator al unei î ncercări de manipulare a sesiunii.
Sesiuni de conectare simultană a aceluiasi user
În cazul in care site -ul nu permite logarea c u sesiuni simultane ale aceluiaș i user, se
recomandă detectarea acestui tip de eveniment si implicit terminarea sesiunilor precedente.
De asemenea se recomandă ca aplicațiile web să permită verificarea detaliilor despre
sesiunile active, să monitorizeze ș i să informeze use rul despre sesiunile simultane ș i să
asigure func ționalități d e terminare manuală a sesiunilor. D e asemenea, este indicat să se
înregistreze istoricul activității userului prin î nregistrarea de detalii precum adresa de IP,
User -Agent -ul, data și ora de login, logut sau chiar timpul de inactivitate.

Criptografia sit e-urilor web. Protocoalele SSL si T LS

Protocolul SSL

SSL (Secure Sockets Layer) este un acronim care reprezintă un protocol web
dezvoltat de compania Netscape pentru a transmite fără risc documente private prin
Internet. Pentru a cripta datele, SSL uti lizează un sistem criptografic cu două chei: una
publică, cunoscută de oricine, și una privată, secretă, cunoscută numai de destinatarul
mesajului. Majoritatea navigatoarelor web suportă SSL, și multe site -uri web utilizează
protocolul de utilizator pentru a transmite informații confidențiale, cum ar fi numerele de

Modalit ăți de asigurare a securit ății web -siteurilor

38
carduri de credit. Prin convenție, URL -ul care are nevoie de o conexiune SSL începe cu
https: (în loc de http:).
TLS a fost lansat ca răspuns la cererile comunității pentru un protocol standardi zat.
IETF a oferit un loc de întâlnire pentru ca noul protocol să fie discutat, și a încurajat
dezvoltatorii să ofere contribuția lor la protocol.
Există șapte diferențe principale între SSL și TLS. Acest e diferențe variază de la
număr ul versiunii de protocol la generarea material ului cheie.
Versiunea protocolului î n mesaje
Pentru a diferenția TLS 1.0 de SSL 3.0, versiunea de protocol negociată de client și
serverul de comunicare prin TLS versiunea 1, este versiunea 3.1.
Tipuri de mesaje de alertă protocol
Următoarele tipuri de mesaje sunt cele care sunt permise ca Descriere alertă în
cadrul protocolului TLS. La examinarea listei, se observa că "NoCertificate" a fost
eliminată din lista SSL deoarece se presupune că în absența unui certificat pentru utilizator,
nu este nevoie de un mesaj separat. TLS consideră că , clientul poate re turna un mesaj de
certificat gol dacă nu are un certificat ce poate fi folosit.
In plus, alte câteva descrieri au fost adăugate pentru a aduce numărul de descrieri
de alert ă la 23 de la 12.
Autentificarea mesajului
TLS implementează un MAC standardizat (H -MAC) care a fost dovedit în multe
alte implementări. Principalul beneficiu pentru această schimbare este faptul că H -MAC
funcționează cu orice funcție hash, nu doar MD5 s au SHA.
Generarea materialului cheie
Diferența majoră este că SSL folosește RSA, Diffie -Hellman sau Fortezza / DMS
output pentru a crea un material cheie. Acest output generează informații secrete, bazate pe
CipherSuite și parametrii selectaț i în timpul negocierilor sesiunii.
CertificateVerify
În SSL, mesajul CertificateVerify necesită o procedură complexă de mesaje. Cu
TLS, totuși, informațiile verificate zunt conținute complet în mesajele schimbate anterior
în timpul sesiunii.
Finished
In TLS, output -ul PRF al algoritmului H -MAC este utilizat cu master secret si fie o
denumire “client terminat” sau “server terminat” , cu scopul de a crea mesajul final. În SSL,
mesajul final este creat în același mod ad -hoc ca și materialul cheie: utilizar ea unei
combinații de output hash, ciphersuite selectate și informațiile parametrului.
Baseline Cipher Suites
Așa cum am menționat mai devreme, SSL suport ă în special RSA, Diffie -Hellman
și Fortezza / ciphersuites DMS. TLS a incetat să permită Fortezza / DLS suport, dar
permite ciphersuites să fie adăugate la protocol în versiunile viitoare.
Ultima și cea mai curentă versiune oficială – TLS 1.2 – a fost lansată î n august 2008
și are o serie de î mbunăt ățiri documentate în RFC 5246, inclusiv eliminarea suit elor de
cifre ca DES sau IDEA si includerea suitelor SHA256.

Modalit ăți de asigurare a securit ății web -siteurilor

39
Încep ând cu aprilie 2015, a ap ărut un plan pentru versiunea 1.3 dar detaliile nu au
fost încă stabilite.

Implementarea protocolului SSL
Secure Sockets Layer a fost gândit ca un nivel separat de protocol, conceput special
pentru a se ocupa de securizare. Așa cum este cunoscut, comunicarea web se bazează pe
anumite protocoale, acestea jucând roluri importante in interacțiunea dintre client s i server
pe Internet. Începând cu nivelul cel mai de sus si terminând cu cel mai de jos, acestea sunt:

 HTTP (Hypertext Transfer Protocol)
 TCP (Transmission Control Protocol)
 IP (Internet Protocol)

Pentru a garanta o conexiune securizată , protocolu l SSL este interpus între HTTP și
TCP. Faptul că SSL este un protocol separat de celelalte ofe ră câteva avantaje importante.
În primul rând , celelalte niveluri nu necesită modificări majo re pentru a interacționa cu el
în această nouă structură: HTTP comunică și cu SSL, aproape identic cu modul î n care ar
comunica cu TCP, iar protocolul TCP nu suferă nicio modificare, comunicând cu SSL așa
cum ar face -o cu orice altă aplicație dintr -un strat superior sieși.
În plus, exist ă și avantajul flexibi lității: SSL poa te fi utilizat ț i pentru a securiza alte
aplicații ce nu sunt bazate pe HTTP, ci pe protocoale cum ar fi NNTP (Net News Transfer
Protocol) sau FTP (File Transfer Protocol).
Atunci când o conexiune HTTP este securizată cu ajutorul SSL, URL -ul
corespunzător va avea prefixul „ https :” (in loc de „ http:” pentru cazurile nesecurizate), iar
browserul va afișa un simbol indicând acest lucru.
În prezent, SSL este suportat de majoritatea browserelor existente.
Facând click pe simbolul sub forma de lacăt din browse r, se pot obține mai multe
informații despre con exiunea HTTPS. Prezentă m mai jo s un exemplu de conexiune sigură
(mail -ul de la Google):

Modalit ăți de asigurare a securit ății web -siteurilor

40

Fig. 7 – Setări SSL afișate în browser ul Mozilla Firefox

Protocolul SSL se poate implementa pe partea de server prin utiliza rea diverselor
unelte software ș i biblioteci existente pen tru realizarea acestui scop. Pri ntre ele se numără
OpenSSL, StartSSL, NSS, GnuTLS ș i multe altele.
Procesul descris m ai sus nu este însă suficient. Î n plus este necesară obținerea unui
certificat de la o organizație î n care browserele au încredere. La activarea SSL pe server,
acesta generează o cheie privată și o cheie publică. Această cheie publică trebuie plasată
într-un CSR (Certificate Signing Request), care la rândul lui este tri mis autorității de
certificare î n cadrul procesului de aplicare pentru un certificat SSL. După obținerea acestui

Modalit ăți de asigurare a securit ății web -siteurilor

41
certificat, serverul va verifica legătura dintre certi ficatul obținut si cheia privată . Din acest
moment, serverul poate folosi certificatul pentr u a stabili o conexiune criptată între
websiteul pe care îl găzduiește ș i clie nți (browserele care încearcă să -l acceseze).
Mod de funcționare a protocolului SSL
Protocolul SSL stabilește două roluri: cel al clien tului (reprezentat de browser) și
cel al serverului. Aceste două entități interacționează între ele pentru a stabili un canal
criptat de comunicare, având fiecare roluri bine stabilite ș i comportamente diferite.
În faza inițială, clientul este cel care începe „conversația”, trimițând serverului o
cerere pentru un canal securizat, î n timp ce serverul este cel care primește cererea ș i
transmite înapoi un răspuns clientului.
Principalul scop al comunicării dintre cele două roluri este stabilirea unui canal de
comunicare sigu r. La acest proces se po t adauga diverse alte opțiuni mai complexe, pe c are
le vom trece în revistă in cele ce urmează. Î n imaginea de mai jos se poate observa
procesul prin care se obține canalul criptat, prin transm iterea de mesaje între cele două
părți:

Fig. 8 – Procesul pri n care se ob ține canalul criptat

1. Prin intermediul primului mesaj (ClientHello), clien tul transmite serverului o
listă cu serviciile de secur itate pe care le poate suporta și pe care le dorește în această
conexiune.
Cele mai importante componente ale mesajului ClientHello transmis de client care
server sunt câmpurile: Version, RandomN umber, SessionID, CipherSuites ș i
CompressionMethods.

Modalit ăți de asigurare a securit ății web -siteurilor

42
– Version : comunică serverului care este cea mai nouă versiune de SSL pe care
clientul are capacitatea de a o suport a.
– RandomNumber : este un număr ales aleatoriu pe 32 de byte s, care va fi folos it in
calculele criptografice. Î n general, o parte din acest număr e formată din data si ora curentă ,
pentru ca același număr sa nu fie folosit de două ori sau pentru a preven i refolosirea un ui
mesaj SSL de către o persoană rău voitoare.
– SessionID : identificatorul sesiunii .
– CipherSuites : lista de parametrii criptografici pe care clientul î i poate suporta .
– CompressionMethods : metode de comprimare a datelor pe care clien tul le poate
suporta .
2. Dintre acestea, serverul ale ge una și transmite această alegere înapoi către client
printr -un mesaj ServerHello.

Mesajul transmis înapoi de server conține aceleași câmpuri ca și cel transmis de
client. Î n tim p ce clientul oferă informații ș i sugestii, serverul este cel care face al egerea
finală ș i doar informează clientul asupra căreia dintre opțiunile propuse de acesta vor fi
folosite. Bineînțeles, ș i serverul este supus unor limitări. El nu poate alege decât una dintre
opțiunil e propuse de client.
3. Mesajul transmis în cont inuare de server (ServerKeyExchange) conține
informațiile din cheia sa publică .

Deoarece acest mesaj este transmis fără a fi criptat, el nu p oate conține decât cheia
publică. Clientul va folosi această cheie pentru a cripta o cheie de sesiune ce va fi folosit ă
de ambii pentru a cripta informații transmise in sesiune.
4. Pentru a indica faptul ca a încheiat partea sa de comuni care, serverul transmite in
continuare mesajul ServerHelloDone.

Acest mesaj nu c onține nimic, dar are rolul de a -l anunța pe client ca p oate cont inua
procesul.
5. Clientul folosește cheia publică primită de la server pentru a cripta in formații
despre cheia sesiunii ș i le trimite înapoi serverului prin mesaj ul ClientKeyExchange. De
această dată , clientul transmite serverului o cheie. Difer ența este reprezentată de faptul că
acest mesaj est e criptat folosind cheia publică a serverului si această cheie va fi utilizată de
ambele părți pe durata sesiunii î n algoritmul de criptare simetrică . Astfel, clientul verifică
faptul că serverul este cine spune că este. Un atacator care se interpune între client si server,
pretinzând ca este s erverul, nu deține cheia privată a serverului ș i nu ar putea decripta acest
mesaj și nu ar putea să comunice î n continuare.

6. Prin următorul mesaj (ChangeCipherSpec), clientul activează metodele de
securitate asupra cărora cei doi au căzut de acord.

Modalit ăți de asigurare a securit ății web -siteurilor

43
Atât clientul, cât și serv erul, dețin o stare de scriere ș i o stare de citire. Starea de
scriere definește infor mațiile de se curitate pentru datele trimise ș i cea de citire – pentru
datele primite. Acest mesaj are rolul de a a nunța pe cel care îl primește că e timpul sa
activeze aceste informații. La trimiterea acestui mesaj, partea care îl trimite îș i activează
starea de scriere, în momentul î n care cealaltă parte primește un mesaj, aceasta își activează
starea de ci tire. Fiecare dintre aceste două stări (de citire ș i de scriere) pot fi active sau î n
așteptare.
7. Me sajul Finish transmite faptul că toate discuți ile inițiale au fost încheiate si s -a
stabilit o conexiune securizată . Prin acest mesaj , clientul permite serverului să verifice
opțiunile activate.
Prin intermediul acestui mesaj, amb ele părți pot verifica faptul că negocierea a fost
un succes si că securitatea nu a fost compromisă. Cazul î n care partea care primeșt e
mesajul nu il poate decripta și verifica indică o problemă .
8. Serverul răspunde prin aceeași succesiune de mesaje: ChangeCipherS pec pentru
a activa opțiunile.
Ca și punctul 6.
9. Finishe d pentru a permite clientului să le verifice.
Ca și punctul 8.
Opțiuni suplimentare:
La procesul descris mai sus se po t adăuga, in funcție de necesită ți, diverse opțiuni
suplimentare. Vom prezenta, pe scurt, câteva dintre acestea.
 Încheierea unei comunicări securizate:

Există cazuri î n care e necesar ca ambele părți să transmită un mesaj ClosureAlert.
Astfel, un atacator nu poate să compromită securitatea încheind o sesiune prea devreme.
Dacă o sesiune se încheie fără transmiterea ClosureAlert, partea care nu primește acest
mesaj va înțelege că nu s -a primit mesajul î n întregime.
 Autentificarea serverului

Criptarea canalului de comunicare are rolul de a nu permite informațiilor să fie
vizuali zate si de o a treia persoană. În sch imb, dacă această persoană ar reuși să se
interpună î n conversație, prefăc ându -se că este serverul dorit, o astfel de criptare nu ar
servi la nimic. Bineînțeles, logic ne -am gândi că ar trebui sa verifică m ambele părți pentru
a le garanta identitatea, totuși, este mult mai importantă verificarea serverului, deoarece
acesta primește din partea clienților date prin care le poate verifica identitatea. De exemplu ,
în cazul unei tranzacții prin card de credit, serverul poate verifica identitatea clientului
folos ind codul cardului sau bancar, î n schimb este vital ca identitatea serverul ui să poată fi
verificată . Nu am dori sa trimitem detaliile bancare unui atacator.
Autentificarea serverului intervine la pasul 3 din schimbu l de informații dintre cele
două părți. Cheia publică transmisă de server este înlocuită cu un certificat, iar la pasul 5,
clientul folosește aceasta cheie pentru a cripta cheia sa de sesiune.

Modalit ăți de asigurare a securit ății web -siteurilor

44
În plus, clientul verifica certificatul primit de la server, in general folosind trei
criterii: certi ficatul este publicat de o organizație in care browserul are încredere,
certificatul este încă in termen, adică nu a expirat si nu a fost revocat și nu î n ultimul rând,
certificatul este folosit de către site -ul we b pentru care a fost eliberat. În cazul î n care una
dintre cele trei verificări rezultă într -o neconcordanță , atunci browserul transmite userului
un mesaj prin care îl informează că ceva este în neregulă cu certificatu l site -ului pe care
dorește sa i ntre si ca nu ar trebui sa conținue si sa aibă î ncredere in site -ul respectiv.
 Autentificarea separată a serverului

În procesul de mai sus am descris cum se autentifică serverul ca pas din procesul de
stabilire a comunicării printr -un canal securizat. Acest lucru nu este mereu ideal, iar uneori
este chiar imposibil, deoarece in situația descrisă mai sus, se va folosi cheia publică a
certificatului. Există situații când ac easta cheie nu poate fi folosită decât pentru semnare,
dar nu și pentru criptare (de exemplu când se folosește algoritmul DSA (digit al signature
algorithm) ).
Pentru autentificare separată se introduce un pas suplimentar: astfel, la pasul 3 se
transmite de către server certificatul să u, iar la pasul 4 serverul transmite mesajul
ServerKeyExchance. La pasul 5, devenit între timp pasul 6, clientul folosește cheia primită
prin mesajul ServerKeyExchange si nu cea a certificatului (pe care o folosește doar pentru
a-i verifica identitatea).
 Autentificarea clientului

Deși folosit mult mai rar, protocolul SSL include și un proces de autentifi care a
clientului.
După ce trimite certificatul să u, serverul transmite și u n mesaj prin care î i cere
clientului să se autentifice: CertificateRequest, urmat de mesajul de ServerHelloDone.
Următoarele mesaje din secvență sunt transmise de către client in următoarea ordine:
Certificate, ClientKeyExchange, CertificateVerify, apoi p rocesul cont inuând ca mai
înainte cu mesajul ChangeCipherSpec si celelalte care îl urmează.
Mesajele care diferă în această situație sunt:
– CertificateRequest: prin care server ul cere clientului să se autentifice
– Certificate: prin care clientul trans mite cheia sa publică
– CertificateVerify: prin care clientul transmite informații importante despre
sesiune, semnând cu cheia sa privată . Serverul folosește cheia publică a clientului pentru
a-i verifica identitatea.

Modalit ăți de asigurare a securit ății web -siteurilor

45
Serverul nu are posibilitatea de a cere un certificat înainte de a se certifica el însuși,
astfel asigurându -se secu ritatea clientului care poate să îl verifice înainte de a trimite
propriul certificat.
Reluarea unei sesiuni începute anterior
Pentru a scurta procesul descris mai sus, exista și posibilitatea de a relua o sesiune
deja existentă . Pentru reluarea unei sesiuni este nevoie doar de 6 mesaje transmise între
server ș i client:
ClientHello: include d e această dată SessionID al unei sesiuni anterioare
ServerHello: in care serverul recunoaște sesiunea propusă
ChangeCipherSpec: transmis de server pentru a reactiva opțiunile sesiunii
Finished: transmis de server
ChangeCipherSpec: transmis de client
Finished: transmis de client
Probleme cunoscute și limitări ale protocolului SSL
Există trei categorii de limitări pe care protocolul SSL le are. In primul rând ne vom
referi la limitările provenite din proiectarea protocolului, apoi exista limitările da torate
uneltelor folosite de protocolul SSL, cu alte cuvinte slăbiciunile algoritmilor utilizați
pentru criptare si semnare. Ultima categorie este reprezentată de probleme ale mediului in
care protocolul acționează.
Limitări ale protocolului
Protocolul S SL se bazează pe protocolul TCP, deci nu poate funcționa utilizâ nd un
protocol de tran sport neconectat. Î n plus, protocolul SSL nu poate asigura serviciul prin
care, o dată create si semnate anumite date, persoana responsabilă nu poate nega acest
lucru. Pe ntru a garanta că autorul nu poate nega, trebuie folosite alte metode care să
completeze protocolul SSL.
Slăbiciuni ale algoritmilor
SSL se bazează pe algoritmi de criptografie si securitatea acestuia depinde de
implementarea core ctă a algoritmilor respe ctivi. În cazul î n care aceștia sunt slabi,
protocolul nu poate compensa și devine și el slab la rândul lui.
Probleme ale mediului
Din păcate, datele sunt protejate doar in timpul transferului, dar nu există nici un
mod de a asigura protecția acestora în ainte de a fi trimise sau după ce au fost primite.
Calculatoarele pe care sunt stocate datele sau elementul uman, pot reprezenta o verigă
slaba si pot compromite întregul proces prin rea intenție sau din neatenție.
De aceea, o securitate completă trebuie să includă mai multe elemente, î n timp ce
protocolul SSL este doar unul dintre aceste a, jucând doar rolul să u in sistem.

Modalit ăți de asigurare a securit ății web -siteurilor

46
Protocolul TLS
Protocolul TLS per mite comunicarea client -server în rețea î ntr-un mod sigur fară
interferențe.
Prima versiu ne oficiala de TLS(Transport Layer S ecurity) a aparut in 1999 ca o
îmbunătațire a SSL(Transport Layer Security) 3.0.
Într-o conexiune utilizator/browser tipică, autentificarea TLS este unilaterală, doar
serveru l este autentificat, clientul rămâ ne anonim. Autentificarea la nivelul browser -ului
presupune ca acesta să valideze certificatul serverului(să verifice semnatura digitală a
acestuia). O astfe l de legatură poate fi stabilită in siguranță dacă URL -ul, numele sau
adresa acestuia, este specificat in cert ificatul serverului. Paginile web nesigure nu pot
folosi certificatul altor pagini web deoarece nu au posibilitatea să cripteze mesajul astfel
incât să fie decriptat cu un certificat valid. Cum numai un CA (Certification Authoritie) de
încredere poate insc rie un URL in certificat, acest lucru asigură identificarea corectă a
paginilor de încredere.
TLS suportă si conexiunea bilaterală, mai sigură, in ca re între cei doi clienti există
o legatura sigură (fiecare are datele de identificare in certificatul celu ilalt). Aceasta
conexiune mai este cunoscută ca autentificare reciprocă. Conexiunea impune clientului să
detină certificat (acest lucru nu este necesar in cazul conexiunii utilizator/browser),
exceptând TLS -PSK sau protocolul Secure Remote Password (SRP) s au oricare alt
protocol care poate o feri o autentificare puternică î n cazul lipsei certificatului.
TLS presupune trei pași de bază :
1. Negocierea privind algoritmul
2. Schimbul de cheie și autentificarea
3. Cifru de criptare simetric și autentificarea mesajelor

În prima fază clientul și serverul negociază seturile de cifruri, și determină care din
aceste cifruri va fi folosit, schimbul de cheie si algoritmul de autentificare, cât și codurile
masajului de autentificare (MAC -uri). Algoritmii pentru schimbul de chei e si autentificare
sunt in general algoritmi pentru cheia publică. Codurile pentru autentificarea mesajelor
sunt compuse din funcții hash criptografice folosind HMAC pentru TLS și o funcție non –
standard pseudoaleatoare pentru SSL.
Algoritmii tipici folosi ți sunt:
 Pentru schimbul de cheie: RSA, Diffie -Hellman, ECDH, SRP, PSK

Modalit ăți de asigurare a securit ății web -siteurilor

47
 Pentru autentificare: RSA, DSA, ECDSA
 Cifru simetric: RC4, AES, IDEA, DES
 Pentru funcții hash criptografice: HMAC -MD5 sau HMAC -SHA pentru TLS,
MD5 sau SHA pentru SSL

Utilizare
TLS rulează î n straturile de sub protocoale le HTTP, FTS, SMTP, NNTP, XMPP ș i
deasupra protocolului de transpost de încredere, de exemplu TCP. Desi poate spori
securitatea or icarui protocol care foloseș te o conexiune de încredere (cum ar fi TCP), este
cel mai des folosit împreună cu HTTP pentru a forma HTTPS.

Securitate
TLS/SSL au o v arietate de mă suri de siguranță:
 Clientul poate folosi cheia publică a autori tății de certificare pentru a valida
semnatura digitală a acestuia in certificatul serverului. Dacă semnatura poate fi
verificată atunci clientul acceptă certificatul serverului;
 Clientul verifică dacă autoritatea de certificare care a eliberat certificatul apare
în lista de autorităț i de certificare de încredere;
 Clientul verifică valabilitatea certificatului. Procesul de autentificare se oprește
dacă aceasta este depașită;
 Protectie î mpotriva versiunilor anterioare (mai puțin sigure) a protocoalelor sau
a unui cifru slab;
 Mesajul care î ncheie un handshake (‚Finished‟) trimite un hash cu toate
mesajele handshake schimbate si vizualizate de către ambii utilizatori;
 Funcția pseudoaleat oare împarte datele de intrare în jumă tate și le procesează
pe fiecare cu un algoritm hash diferit (MD5 s i SHA -1), apoi XOR -ii lucrează
împreuna pentru a crea codul de autenificare a mesajului (M AC). Acest lucru
asigură protecț ia chiar dacă unul din algoritmi este considerat vulnerabil.

Modul de func ționare a protocolului TLS

Clientul și server ul care utilizează TLS negociază conexiunea utilizând procedura
handshake. Î n timpul acestui handshake, clientul și serverul stabilesc de comun acord
anumiți parametri pentru stabilirea securitǎții conexiunii.
Procedur a handshake î ncepe când clientul se conecteaza la un server ce are activat
TLS, solicitând o conexiune sigură si prezintă o listă de cifruri și funcții hash;
Din acesta listă serverul alege cel mai puternic cifru si funcție hash pe care le
suportă și anun ță clientul despre această decizie;

Modalit ăți de asigurare a securit ății web -siteurilor

48
Serverul trimite clientului datele de identificare sub forma certificatului digital.
Acest certificat conține numele serverului, CA (certificate authority) de încredere si cheia
publică de criptare;
Clientul poate acce sa serverul (CA) care a eliberat acel certificat pentru a confirma
că acesta este autentic.
Pentru a genera cheile de securizare a conexiunii, clientul cripteaza un număr
aleator (RN) folosind cheia publică a serverului (PbK) si î l transmite serverului. D oar
serverul poate decripta mesajul folosind cheia privată (PvK).
Din numărul aleator serverul și clientul generează o cheie pentru criptare si
decriptare.
Aceasta î ncheie handshak e-ul și se incepe conexiunea securizată, care este criptată
și decriptată folosind cheia până la î nchiderea conexiunii.
În cazul î n care unul din pașii de mai sus nu este realizat, handshak e-ul TSL este
abandonat și conexiunea nu se cre ează.
TLS handshake in detaliu
Protocolul TLS interschimbă înregistrări, care încă pulsează datele care u rmează a
fi transmise. Fiecare înregistrare poate fi comprimată, anexată cu un mesaj de autentificare
(MAC – message a uthentication code) sau criptată, toate depinzâ nd de stadiul co nexiunii.
Fiecare înregistrare conține un câmp content type ca re specifică înregistrarea, un câmp
pentru lungime și un câ mp pentru versiunea de TLS.
Un TLS handshake simplu
Un exemplu de o conexiune simplă, ilustrând un handshake î n care doar serverul
este autentificat folosindu -se certificatul acestuia, este urmă torul:
1. Faza de negociere:
 Un client trimite un mesaj ClientHello specificând versiunea cea mai recentă pe
care o suportă, un număr aleator, o lista cu cifruri si metode de comprimare;
 Serverul ră spunde cu un mesaj ServerHello , care conține versiunea d e protocol, un
număr aleator, cifrul si metoda de comprimare aleasă din lista trimisă de client.
Serverul mai poate trimite un ID al sesiunii in cuprinsul mesajului pentru a realiza
un handshake reluat.
 Serverul trimite certificatul (î n funcție de cifrul ales, acest lucru poate fi omis de
către server);
 Serverul trimite clientului un mesaj ServerHelloDone , indicând ca a î ncheiat
negocierea handshake;
 Clientul raspunde cu un mesaj ClientKeyExchange , care poate conține un
PreMasterSecret, cheia publică sau nimic ( depinde de cifrul ales);
 Clientul si serverul folosesc număr ul aleator si PreMasterSecret pentru a compune
un secret comun denumit ‚master secret‟. Toate datele privind cheia acestei
conexiuni sunt livrate prin acest master secret (si atât server ul cât și clientul
generează valori aleatoare), care este trecut printr -o funcție pseudoaleatoare atent
concepută.

Modalit ăți de asigurare a securit ății web -siteurilor

49
2. Clientul trimite o î nregistrare ChangeCipherSpec, spunându -i serverului că tot ce
urmează să primească este autentificat (și criptat dac ă parametrii de criptate au fost
transmiși și certificatul serverului). ChangeCipherSpe c este un protocol la nivel de
înregistrare si are tipul 20 nu 22.
În cele din urmă clientul trimite un mesaj ‚Finished‟ autentificat și criptat, care
conține un hash M AC peste mesajul handshake anterior;
Serverul va decripta mesajul ‚Finished‟ al clientului si verifica hash -ul si MAC -ul.
Dacă dec riptarea sau verificarea nu reuș esc, atunci conexiunea este întreruptă.

3. Serverul trimite clientului un ChangeCipherSpec, spunandu -i că tot ce urmează
să primească este autentificat (ș i criptat cu cheia privată a serverului asociată cheii publice
din certificat, dacă a fost negociată criptare).
Serverul trimite mesajul ‚Finished‟ autentificat și criptat;
Clientul îl decrip tează și î l verifică.

4. Faza de aplicare: în acest punct ‚handshake‟ este î ncheiat si este activat
protocolul de aplicare având content type 23. Mesajele care vor fi schimbate între server și
client vor fi aute ntificate si optional criptate în acelaș i mod ca mesajele ‚Finished‟ .

Modalit ăți de asigurare a securit ății web -siteurilor

50
Capitolul V Instrumente software utilizate în detectarea
vulnerabilit ăților site urilo r web
În acest capitol vom discuta despre o serie de utilitare utilizate fr ecvent de
dezvoltatorii web in îmbunatățirea securității site -urilor web, cum ar fi utilitarele din suita
IBM Security Scan, scanere de vulnerabilităț i, analizoare de cod precum si instrumente
utiliza te in vizualizarea cererilor/ ră spunsurilor HTTP.
Suita de utilitare IBM Security AppScan
Acestea s unt o suită de instrumente pentru testare si monitorizare a securitǎții web
furnizate de IBM. AppScan este utilizat la testarea aplicațiilor web pentru detectarea
vulnerabilităților de securitate, î n timpul procesului de dezvoltare, când aceste probleme
sunt cel mai ieftin de prevenit. Utilitarul detectează comportamentul aplicației si generează
un program pent ru testarea tuturor funcțiilor în vederea detectării vulnerabilită ților
generice sau specifice aplicației.
Acest produs software este livrat în ur matoarele formate ( prezentă m mai jos pe
cele mai importante) :
Standard Edition – aceasta este varianta desktop pentru testarea de securitate
automatizată , utilizată de auditori de securitate si specialisti in testarea securitǎții .
Tester Edition – aceasta variantă oferă si o integrare cu IBM Rational Quality
Manager pentru a construi un mediu de testare a securitǎții de tip QA ( quality assurance).
Enterprise Edition – aceasta variantă oferă o versiune client –server pentru a scala
testarea de securit ate.
Source Edition – aceasta variantă oferă funcționalități de prevenție a breș elor de
date prin locali zarea defectelor de programare ă n codul sursa.
Utilitarul este disponibil la adresa :
http://www -03.ibm.com/software/products/en/appscan

Scan nere d e vulnerabilită ți
Un scanner de vulnerabilită ți ale aplicației web este un program software care face
în mod automat testingul de tip black box asupra unei aplicații web si identifică
vulnerabilită ți de securitate. Scan nerele nu accesează codul sursă, ele doar fac testare
funcțională si încearcă să găsească posibile vulnerabilită ți.
Pe piață există diferite variante de scan nere, unele gratuite , altele contra cost.
Prezentă m mai jos o listă cu cele mai cunoscute scan nere open source.

Grabber
Poate detecta urmă toarele vulnerabilități:
Cross site scripting, SQL Injection, Ajax testing, File inclusion, JS source code
analyzer . Este disponibil la adresa : http://rgaucher.info/beta/grabber/

Modalit ăți de asigurare a securit ății web -siteurilor

51
Vega
Este un scanner de vulnerabilități si o platformă de testare. Acest tool este scris î n
Java si este disponibil pentru OS X, Linux si Wi ndows si poate fi extins utilizând o serie de
API-uri foarte puternice scrise î n JavaScript.
Zed Attack Proxy
Zed Attack Proxy este cunoscut sub numele de ZAP. Acest tool e ste dezvoltat de
AWASP. Este disponibil pe Windows, Linux/Unix si Mac OS. Este un tool simplu si usor
de folosit. Funcționalităti cheie ale ZAP:
Intercepting Proxy
Automatic Scanner
Spideri traditionali dar puternici
Fuzzer
Suport pentru web socket
Support plug -n-hack
Support autentificare
Certificare dinamice SSL
Support pentru smartcard si certificate digitale client
Acest tool se poate utiliza ca un scanner , prin introducerea manuală a URL -ului
site-ului de evaluat sau se poate utiliza acest t ool ca un intercepting proxy pentru a testa
manual doar anumite pagini.
WebScarab
WebScarab este un sistem pe bază de Java pentru analizarea aplicațiilor web
utilizând protocoalele HTTP sau HTTPS. Funcționalitatea acestui tool se poate extinde cu
anumite plugin -uri. Acest tool funcț ionează ca un proxy de interceptare. De aceea, se pot
analiza cererile si răspunsurile schimbate între browser si server. Se pot modifica cererile
sau răspunsurile inainte ca ele să fie receptionate de către server sau browser. Totusi, acest
tool nu este recomandat începătorilor. El poate fi utiliz at de către cei care au o bună
înțelegere a protocolului HTTP. WebS carab oferă multe funcționalități care ajută testerii sa
lucreze m ai bine cu aplicațiile web si să identifice vulnera bilită țile web. Programul conține
un spider care p oate identifica automat noi URL -uri ale site -ului țintă . De ase menea, poate
extrage cu usurință scripturile si HTML -ul unei pagini. Proxy -ul observă traficul între
server si browser si se pot controla cerer ile si răspunsurile prin utilizarea unor plugin -uri.
Modulele disponibile pot detecta us or cele mai comune vulnerabilități precum SQL
Injection, XSS, CFRL ș i multe altele. Codul sursă este disponibil pe GitHub.
Wapiti
Wapiti este de asemenea un instrument interesant care asigură auditarea securitǎții
aplicațiilor web.
El asigură testarea de tip black box prin scanarea paginilor web si injectare de date.
Incearcă să injecteze siruri de caractere pentru a determina dacă un script este vulnerabil.
Suportă at ât atacuri de tip GET cât și POST HTTP și este capabil să detecteze
vulnerabilități multiple.

Modalit ăți de asigurare a securit ății web -siteurilor

52
Tipuri de vulnerabilități detectate:
File disclosure
File inclusion
Cross site scripting
Command execuțion detection
CRFL Injection
SEL Injection and XPATH Injection
Weak .htaccess configuration
Backup file disclosure
Etc.
Wapiti este o aplicație la nivel de linie de comandă, de aceea ar putea fi dificil de
utlizat de începă tori.
W3af
W3af reprezintă un sistem de atac al aplicați ei web si de audit de securitate. Acesta
are ca scop furnizarea unei platform e de penetration testing. Este dezvoltată în Python. Prin
utilizarea acestui tool se pot identifica mai bin e de 200 de tipuri vulnerabilită ți web
incluzând injecții SQL , cross sit e scripting. Dacă un website are nevoie de autentificare se
pot utiliza modulele de autentificare pentru a scana paginile protejate de sesiune.
Skipfish
Skipfish este de asemenea un tool performant. Utilitarul vizitează sit e-ul web și
verifică fiecare pa gină contra unor ameni nțări de securitate dintre cele mai variate si in
final generează un raport. Acest utilitar a fost scris in C și este disponibil in Linux,
Windows, MacOS si F reeBSD. Programul se poate descărca de la următoarea locaț ie:
http://code.google.com/p/skipfish/
Wfuzz
Acest utilitar poate fi utilizat pentru testarea impotri va unor tipuri variate de injecț ii
de cod cum ar fi: SQL, XSS, LDAP și multe altele prin metoda forței brute.
Suporta multi -threading, URL encoding, coo kies, etc.
Ratproxy
Acest utilitar este de asemenea disponibil in Linux, Windows, MacOS si FreeBSD.
Programul este proiectat să depașească multe din problemele c u care utilizatorii se
confruntă de obicei când utilizează alte tool -uri proxy pentru auditur ile de securitate.
Utilit arul este capabil să distinga între style -sheet -uri CSS si coduri JavaScript.
De asemenea suportă atacuri SSL “ man in the middle ” , ceea ce înseamnă că se
poate vizualiza data trecând prin SSL. Utilitarul este disponibil la adresa :
http://code.google.com/p/ratproxy/
SqlMAP
Este un alt utilitar destul de popular pentru testare. El automatizează procesul de
identificare a vulnerabilităților de tip SQL I njection din baza de date aparținând site -ului.
Utilitarul este prevazut cu un m otor foarte puternic de detectare deci testerul poate efectua
verificari de tip SQL Injection asupra unui si te web. Programul suportă o gamă largă de
baze de date incluzand MySql , Oracle, PostgreSQL, Microsoft SQL Server, Microsoft

Modalit ăți de asigurare a securit ății web -siteurilor

53
Access, IBM DB2, SQLite , Firebird, Sybase si SAP MaxDB. Oferă support pentru șase
tipuri de tehnici de SQL Injection: time -base blind, Boolean -based blind, error -based,
UNION query, stacked query si out -of-band.
Codul sursă se poate accesa de pe GitHub:
https://github.com/sqlma pproject/sqlmap iar programul poate fi descarcat de la urmatoarea
locatie: https://github.com/sqlmapproject/sqlmap .
Arachni
Este un utilitar open source dezvoltat pentru a asigura un mediu de testare pentru
teste de genul penetration testing. Acest util itar poat e detecta diferite vulnerabilită ți de
securitat e ale aplicației cum ar fi SQL Injection, XSS , local file inclusion, remote file
inclusion, redirect nevalidat și multe altele.
Watcher
Watcher este un scanner de securitate web pas iv. Aces ta nu at acă cu cereri sau
vizitează site -ul web țintă . Nu este un tool separat , ci un add -on la Fiddler. De aceea, este
necesar să se instaleze Fiddler și apoi Watcher. Utilitarul analizează cererile și răspunsurile
generate de interactiunea serverului cu utilizato rul si genereaz ă un raport asupra aplicației.
X5S
X5S este de asemenea un add -on la Fiddler si este utilizat p entru a identifica
vulnerabilită ți de tipul cross site scripting. Nu este un utili tar automat. De aceea, trebuie
înțeles mai întâ i cum problemele de encoding pot duce la XSS. Trebuie identificat manual
punctele de injection si apoi verificat unde poat e fi in aplicație XSS.
NESSUS
Este cel mai ra spandit scanner de vulnerabilită ți din lume, conform unor concluzii
ale sectools.org . Rulează atât î n medii on -premise, on -cloud sau hibride. Este recomandat
de Centrul de Răspuns la Incidente de Securitate Cibernetică CERT -RO. Utilitarul este
dezvoltat de compania Tenable Network Security. Se estimează ca acest utilitar este
utilizat de peste 750 00 organizatii din întreaga lume.
Nessus permite scanarea pentru următoarelor tipuri de vulnerabilități:
– Vulnerabilităț i care permit unui atacator de la distanță să preia controlul și să
acceseze date de pe sistem.
– Configuraț ii incomplete sau greșit e (cum ar fi lipsa unor patch -uri importante,
open mail relay, etc).
– Parole implicite, parol e comune sau lipsa parolelor as ociate cu unele conturi de
sistem. Nessus poate apela un dictionar extern numit Hydra, pentru a testa un atac pe baza
de dicționar .
– Atacuri de tip DOS asupra stivei TCP/IP utilizând pach ete malformate .
În mod opțional, rezultatele scanării pot fi raportate în forme variate: text, XML,
HTM L sau LaTEX. Rezultatele pot deasemenea fi salvate î ntr-o bază de cunoștințe pentru
debug.
OpenVas este altă aplicați e de management al vulnerabilită ților. Aceasta este
opensource și se trage din vechea versiunea gratuită a NESSUS (înainte de a fi cumparat
de Te enable). Produsul poate fi descă rcat de la adresa http://www.openvas.org/

Modalit ăți de asigurare a securit ății web -siteurilor

54
Dacă se con sideră că o versiune gratuită nu este de ajuns, sunt disponibile și unelte
comerciale de scanare, specifice mediului web, precum HP WEB Inspect sau Acunetix .
O listă detaliată despre diferite aplicații de scanare sau alte aplicații de securitate
poate fi găsită pe adresa www.cert -ro.eu, secțiunea Programe.

Analiz oare de cod PHP si instrumente de testare

Aceste instru mente se dovedesc foarte utile în analiza de cod în faza de dezvoltare
si pre -deployment. Aceste a sunt extrem de utile pentru că IDE -urile obișnuite nu pot
detecta î n mod eficient erorile de cod PHP. Pe piață există un număr destul de mare de
instrumente pentru analiza statică a codului PHP. Prin aceste instrumente se pot impune
standarde, gestiona complexitatea codului ș i detecta probleme d e natură semantică. Printre
acestea amintim urmă toarele:
PHP Code Checker – este un instrument online disponibil la adresa
http://phpcodechecker.com/. Acesta verifică erorile de sintaxă care nu sunt detectate de
IDE-uri. Este simplu de utilizat și rapid.
DevBug – este un analizor de cod PHP static, disponibil online la adresa
http://www.devbug.co.uk/ . Este scris in JavaS cript. Poate fi utilizat pentru t estarea rapidă a
unei pagini php susceptibilă a avea probleme de securitate.
RIPS – analiz or static de cod sursă foarte util in detectarea vulnerabilită ților codului
sursă PHP. Prin tokeni zare si parsarea fișierelor conț inând codul su rsă, RIPS transformă
codul sursă într -un model de program și poate detecta funcții potenț ial vulnerabile care pot
fi comprom ise de date d e intrare / user input (influențate de utilizatori rău intenționaț i).
RIPS este disponibil la adresa: http://rips -scanner.sourceforge.net/
PHP_CodeSniffer este unul dintre cele mai populare instrumente pentru asigurarea
unui stil clar de coda re a proiectului P HP. Este de obicei livrat cu su port pentru standarde
de codare cum ar fi Zend, Pear sau PSR2 . Acest instrument este disponi bil la adresa:
http://pear.php.net/package/PHP_CodeSniffer/ . Prezentăm mai jos un exemplu de output
generat de PHP _CodeSniffer.

Modalit ăți de asigurare a securit ății web -siteurilor

55

Fig. 9 – Exemplu de output generat de PHP_CodeSniffer
Alte analizoare sunt: php-sat , PHP Mess Detector , Php Tracer Tool , PHPLint,
PhpCallGraph , PhP Analyzer.
IDE-uri PHP

PHPStorm . Acest utilitar este disponibil la adresa
https://www.jetbrains.com/phpstorm/
Printre funcționalităț i amintim: editor de cod php , analiza calităț ii codului , editor
HTML, JavaScript, CSS, funcționalităț i de debugging și testing.
PHP Designer este un IDE si editor de cod HTML5, CSS3 si JavaScrip t care oferă
un ajutor consistent developerului în crearea de web site -uri complexe. Are o interfață
grafică intuitivă, ușor de utilizat și oferă suport pentru FTP si SFTP.
Utilitare pentru detectarea headerului HTTP
HTTP Watch – este un utilitar disponi bil la adresa: http://www.httpwatch.com/ ,
poate fi instalat pe Internet Explorer sau Firefox si oferă următoarele funcționalităț i:
debugging de pagini web, perfo rmance tunning, testare automată http, testare de securitate.
Live HTTP Header – este un util itar disponibil pentru Googl e Chrome sau
MozillaFirefox ca ș i add -on, extensie la browser si oferă informații despre headerul http al
site-urilor vizitate. Este disponibil la adresa http://livehttpheaders.mozdev.org/ sau de pe
Chrome W ebstore. Pri ntre func ționalități, amintim: debuggingul aplicațiilor web,
vizualizarea cookie -urior trimise de web site -uri, vizualizarea tipului de server web al
site-ului vizitat, oferă informaț ii despre headerul http trimis către server, oferă informaț ii
despre head erul http pe care serverul î l trimite browserului.

Modalit ăți de asigurare a securit ății web -siteurilor

56

Fig. 1 0 – Interfața grafică a utilitarului Live HTTP Header

HTTP Header Online – este un utilitar online, disponibil la adresa
http://h eaders.cloxy.net/ cu o interfață grafică simplă care oferă rapid i nform ații despre
headerul de http al site -ului vizitat.
Exemplu de output:
HTTP Status for: "http:// exempl e.mihai .ro"
HTTP/1.1 200 OK
Date: Mon, 08 Jun 2015 15:33:24 GMT
Server: Apache
X-Powered -By: PHP/5.4.41
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache -Control: no -store, no -cache, must -revalidate, post -check=0, pre -check=0
Pragma: no -cache
Set-Cookie: PHPSESSID=fd76280a37eec832fde438bf8cb3a834; path=/
Vary: Accept -Encoding,User -Agent
Connection: close
Content -Type: text/html

Modalit ăți de asigurare a securit ății web -siteurilor

57
Studiu de caz – Site web de social networking scris in PhP/MySql
Proiectul constă într-un site web de social networking care să asigure colaborarea
între memb rii diverselor echipe de proiect din tr-o organiza ție. În aceast ă aplica ție
utilizatorii se pot autentifica, pot încarca fișiere și se pot conecta cu al ți utilizatori.
Aplica ția ruleaz ă pe desktop -uri și trebuie s ă conțină următoarele func ționalit ăți:
• Un proces de înregistrare useri
• O form ă de login
• Func ționalitate de logout
• Profilul userului cu foto (thumbnail)
• Funcționalitatea de schimbare a parolei de către utilizator
• Un listing cu utilizatorii
• Func ționalitatea de catalogare a utilizatorilor c a prieteni
• Mesaje publice și private între useri .

Detalii tehnice

Limbajele de programare utilizate :
– pentru partea de server, se va utiliza P HP, versiunea 5 .6.19
– pentru partea de client se va utiliza HTML, CSS, Javascript, AJAX
– pentru portarea fișierelor pe server se va utiliza utilitarul FileZilla .
– pentru ges tionarea bazei de date MySQL se va utiliz a PHPMyAdmin v.4.5.1

Mediul de dezvoltare utilizat este XAMPP v3.2.2 .
Administrarea bazei de date

Administrarea bazei de date MySql se va face cu phpMyAdmin. Baza de date
conține urm ătoarele tablele: Members , Messages , Friends , Profiles .
Tabelele utilizate vor avea următoarea structură:
Members ('user VARCHAR(16), pass VARCHAR(32 ), INDEX(user(6) ')
Messages
('id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
auth VARCHAR(16), recip VARCHAR(16), pm CHAR(1), time INT UNSIGNED,
message VARCHAR(4096), INDEX(auth(6)), INDEX(recip(6))')

Friends ('user VARCHAR(16), friend VARCHAR(16), INDEX(user(6)),
INDEX(friend(6))')

Profiles ('user VARCHAR(16), text VARCHAR(4096), INDEX(user(6))');

Modalit ăți de asigurare a securit ății web -siteurilor

58

Schema bazei de date:

Estim ări asupra performan țelor

Efectiv, site -ul ocup ă mai pu țin de 1 .2 GB pe HDD cu tot cu con ținut, iar load
average este ~ 10% CPU, 1GB de memorie fiind ocupaț i.
În full load, ~50% -70% CPU folosit cu 4GB RAM. (majoritatea ocupată de cache).
Sistemul poate face fa ță deoarece mai exist ă și SWAP files care pot prelua activit ățile de
memorie în cazul în care cei 4GB de memorie fizic ă sunt ocupa ți. Activitatea cea mai
intensiv ă este introducerea de noi mesaje și poze (necesit ă autentificare, upload,
introducere date și salvare). Num ărul de cereri concurente nu este anticipat a fi peste 100
(limitare de lățime de bandă ). Lățime de band ă alocat ă: 100MB garantat.

Modalit ăți de asigurare a securit ății web -siteurilor

59

Diagrama cazurilor de utilizare

Diagrama de activit ăți pentru înregistrarea unui user în
aplica ție

1. Utilizatorul acceseaz ă aplica ția de la adresa http indicată .
2. Utilizatoru l acceseaza butonul de ”Sign Up” și îș i alege un nume de ut ilizator .
3. Aplica ția valideaz ă dacă numele de utilizator ales este unic .
4. Dac ă numele de utilizator este unic, aplica ția permite înregistrarea .
5. Dac ă numele de utilizator este deja în baza de date a aplica ției, se va afi șa un
mesaj , cerând utilizatorului să aleagă un alt nume.
6. Dupa ce înregistrarea s -a efectuat cu succes, utilizatorul este invitat să acceseze
butonul ”Sign I n”, pentru logarea în aplica ție.

Modalit ăți de asigurare a securit ății web -siteurilor

60
Perspective de dez voltare ulterioar ă a aplica ției

Aplica ția poate fi dezvoltat ă ulterior în sensul extinderii capabilit ăților de stocare a
fișierelor multimedia și a adaug ării de noi funcț ionalit ăți cum ar fi postarea de articole,
link-uri sau ata șamente precum și a cre ării unor roluri de superuser care s ă permit ă
înlocuirea muncii administratorului de baze de dat e în ceea c e prive ște ștergerea de mesaje.

Interfa ța grafic ă a site -ului

Fig. 11 – Pagina principal ă a site ului web

Fig. 12 – Pagina de inregistrare

Modalit ăți de asigurare a securit ății web -siteurilor

61

Fig. 13 – Pagina de login

Fig. 14 – Interfaț a utilizator

Modalit ăți de asigurare a securit ății web -siteurilor

62

Fig. 1 5 – Interfata Membri

Fig. 1 6- Exemplu de editare a paginii de profil utilizator

Modalit ăți de asigurare a securit ății web -siteurilor

63

Fig. 17 – Interfața paginii de schimbare a parolei
Anexa2 – codul sursă al aplicației
Pentru instalarea aplica ției se va utiliza fi șierul setup.php care va crea în baza de
date tabelele necesare rulării aplica ției. Principalele fi șiere ale aplica ției:

functions.php
Fișier care con ține func țiile principale precum și detaliile de login la baza de date.
Proiectul va utiliza cinci func ții principale.
createTable
Verific ă dacă un tabel exist ă deja, iar, dacă nu, îl creează.

queryMysql
Transmite un select catre MySQL, afi șând un mesaj de eroare dac ă query -ul
eșuează.

destroySession
Distruge o sesiune PHP și îi șterge toate datele de îndată ce userul face logout .

sanitizeString
Îndeparteaz ă cod php poten țial periculos sau taguri din user input .

showProfile
Afișeaza imaginea userului și un mesaj de introducere – dacă exist ă unul.
–––––––––––––––––––––––––––
<?php
$dbhost = 'localhost'; // Nerecomandata schimbarea
$dbname = 'Mihai_DB'; // Aceste variabile….
$dbuser = 'mihai_u1'; // …se pot schimba…
$dbpass = 'Performance88'; // …dupa bunul dumneavoastra…

Modalit ăți de asigurare a securit ății web -siteurilor

64
$appname = "Mihai's House"; // …plac.

$connection = new mysqli($dbhost, $dbuser, $dbpass, $dbname);
if ($connection ->connect_error) die($connection ->connect_error);

functio n createTable($name, $query) // creeaza tabelul, in caz ca acesta nu exista
{
queryMysql("CREATE TABLE IF NOT EXISTS $name($query)");
echo "Table '$name' created or already exists.<br>";
}

function queryMysql($query)
// transmite un SELECT catre MySQL, afisand un mesaj de eroare daca esueaza
{
global $connec tion;
$result = $connection ->query($query);
if (!$result) die($connection ->error);
return $result;
}

function destroySession()
// distruge o sesiune PHP si ii sterge toate datele de indata ce userul face logout
{
$_SESSION=arra y();

if (session_id() != "" || isset($_COOKIE[session_name()]))
setcookie(session_name(), '', time() -2592000, '/');

session_destroy();
}

function sanitizeString($var)
// indeparteaza cod PHP potential periculos sau tag -uri din user input
{
global $connection;
$var = strip_tags($var);
$var = htmlentities($var);
$var = stripslashes($var);
return $connection ->real_escape_string($var);
}

function showProfile($user)
// afiseaza imaginea si un mesaj de introducere, daca exista
{
if (file_exists("$user.jpg"))
echo "<img src='$user.jpg' style='float:left;'>";

$result = queryMysql("SELECT * FROM profiles WHERE user='$user'");

Modalit ăți de asigurare a securit ății web -siteurilor

65

if ($result ->num_rows)
{
$row = $result ->fetch_ar ray(MYSQLI_ASSOC);
echo stripslashes($row['text']) . "<br style='clear:left;'><br>";
}
}
?>
–––––––––––––––––––––––––––

header.php

Pentru uniformitate, fiecare pagin ă a proiectului trebuie sa aib ă acces la acela și set
de functionalit ăți.
Acestea au fost plasate în fișierul header.php – acesta este fi șierul care este de fapt
inclus de c ătre celelalte fisiere, și el include, la r ândul lui fi șierul functions.php.
Aceasta înseamn ă că numai un singur require_once este cerut în fiecare fi șier.

–––––––––––––––––––––––––––
<?php
session_start();

echo "<!DOCTYPE html> \n<html><head>";

require_once 'functions.php';

$userstr = ' (Guest)';

if (isset($_SESSION['user'])) // deschide sesiunea pentru userul logat
{
$user = $_SESSION['user'];
$loggedin = TRUE;
$userstr = " ($user)";
}
else $loggedin = FALSE;

echo "<title>$appname$userstr< /title><link rel='stylesheet' " .
"href='styles.css' type='text/css'>" .
"</head><body><center><canvas id='logo' width='624' " .
"height='96'>$appname</canvas></center>" .
"<div class='appname' >$appname$userstr</div>" .
"<script src='javascript.js'></script>";

if ($logged in) // afiseaza bara de meniu, in functie de utilizator(logat sau nelogat)
{
echo "<br ><ul class='menu'>" .
"<li><a href='members.php?v iew=$user'>Home</a></li>" .

Modalit ăți de asigurare a securit ății web -siteurilor

66
"<li><a href='members.php'>Members</a></li>" .
"<li><a href='friends.php'>Friends</a></li>" .
"<li><a href='messages.php'>Messages</a></li>" .
"<li><a href='profile.php'> Edit Profile</a></li>" .
"<li><a href='logout.php'>Log out</a></li></ul><br>" ;

}
else
{
echo ("<br><ul class='menu'>" .
"<li><a href='index.php'>Home</a></li>" .
"<li><a href='signup.php' >Sign up</a></li>" .
"<li><a href='login.php'>Log in</a></li></ul><br>" .
"<span class='info'>&#8658; Trebuie sa te loghezi pentru " .
"a vedea paginile urmatoare.</span><br><br>");
}
?>
–––––––––––––––––––––––––––

setup.php

Acest fi șier creeaz ă tabelele bazei de date. Acesta trebuie rulat în browser înaintea
celorlalte fi șiere .
–––––––––––––––––––––––––––

<!DOCTYPE html>
<html>
<head>
<title>Setting up database</title>
</head>
<body>

<h3>Setting up…</h3>

<?php
require_once 'functions.php';

createTable(' members',
'user VARCHAR(16),
pass VARCHAR(32),
INDEX(user(6))');

createTable('messages',
'id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
auth VARCHAR(16),
recip VARCHAR(16),
pm CHAR(1),

Modalit ăți de asigurare a securit ății web -siteurilor

67
time INT UNSIGNED,
message VARCHAR(4096),
INDEX(auth(6)),
INDEX(recip(6))');

createTable('friends',
'user VARCHAR(16),
friend VARCHAR(16),
INDEX(user(6)),
INDEX(friend(6))');

createTable('profiles',
'user VARCHAR(16),
text VARCHAR(4096),
INDEX(user(6))');
?>

<br>…done.
</body>
</html >
–––––––––––––––––––––––––––

index.php

Acest fi șier afi șează un mesaj de bun venit. Fi șierul se încarc ă în browser.
–––––––––––––––––––––––––––
<?php
require_once 'header.php';

echo "<br><span class='main'>Welcome to $appname,";

if ($loggedin) echo " $user, you are logged in."; // afiseaza un mesaj de bun venit
else
echo ' please sign up and/or log in to join in.';
?>

</span><br><br>
<a href="http://www.startssl.com/"><img src="secured.png" border="0" alt="Free SSL
Secured By StartCom" title="Free SSL Secured By StartCom"></a>
</body>
</html>
–––––––––––––––––––––––––––

Modalit ăți de asigurare a securit ății web -siteurilor

68

signup.php – Pagina de înregistrare

Asigur ă funcționalitatea de înregistrare pe site a noilor useri, proces securizat SSL de
StartCom.
–––––––––––––––––––––––––––
<?php
require_once 'header.php';

echo <<<_END
<script>
function checkUser(user)
{
if (user.value == '')
{
O('info').innerHTML = ''
return
}

params = "user=" + user.value
request = new ajaxRequest()
request.open("POST", "checkuser.php", true)
request.setRequestHeader("Content -type", "application/x -www -form -urlencoded")
request.setRequestHeader("Content -length", params.length)
request.setRequestHeader("Connection", "close")

request.onreadystatechange = function()
{
if (this.readyState == 4)
if (this.status == 200)
if (this.responseText != null)
O('info').innerHTML = this.responseText
}
request.send(params)
}

function ajaxRequest()
// trimite un request catre server, pentru a schimba date cu acesta
{
try { var request = new XMLHttpRequest() }
catch(e1) {
try { request = new ActiveXObject("Msxml2.XMLHTTP") }
catch(e2) {
try { request = new ActiveXObject("Microsoft.XMLHTTP") }
catch(e3) {
request = false
} } }
return request

Modalit ăți de asigurare a securit ății web -siteurilor

69
}
</script>
<div class='main'><h3>Please enter your details to sign up</h3>
_END;

$error = $user = $pass = "";
if (isset($_SESSION['user'])) destroySession();

if (isset($_POST['us er']))
{
$user = sanitizeString($_POST['user']);
$pass = sanitizeString($_POST['pass']);
$aux = 'criptareparola'; // variabila auxiliara, care ajuta la sporirea criptarii
parolei si implicit, ingreuneaza decriptarea acesteia
if ($user == "" || $pass == "")
$error = "Not all fields were entered<br><br>";
else
{
// verifica daca numele de utilizator este disponibil in baza de date
$result = queryMysql("SELECT * FROM members WHERE user='$user'");

if ($result ->num_rows)
// returneaza un mesaj daca acel nume exista deja in baza de date
$error = "That username already exists<br><br>";
else
{
// criptarea parolei cu sirul auxiliar la inceput si la sfarsit
$pass = md5($aux . $pass . $aux);
queryMysql("INSERT INTO members VALUES('$user', '$pass')");
// introduce userul si parola in baza de date
die("<h4>Account created</h4>Please Log in.<br><br>");
}
}
}

echo <<<_END
<form method='post' action='signup.php'>$error
<span class='fieldname'>Username</span>
<input type='text' maxlength='16' name='user' value='$user'
onBlur='checkUser(this)'><span id='info'></span><br>
<span class='fieldname'>Password</span>
<input type='text' minlength='8' maxlength='16' name='pass'
value='$pass'><br> _END;
?>

<span class='fieldname'>&nbsp;</span>
<input type='submit' value='Sign up'>
</form></div><br>

Modalit ăți de asigurare a securit ății web -siteurilor

70
</body>
</html>
–––––––––––––––––––––––––––

checkuser.php – func ționalitatea de verificare pentru username

–––––––––––––––––––––––––––
<?php
require_once 'funct ions.php';

if (isset($_POST['user']))
// verifica daca numele de utilizator introdus este valabil(exista sau nu in baza de date)
{
$user = sanitizeString($_POST['user']);
$result = queryMysql("SELECT * FROM members WHERE user='$user'");

if ($result ->num_rows)
echo "<span class='taken'>&nbsp;&#x2718; " .
"This username is taken</span>";
else
echo "<span class='available'>&nbsp;&#x2714; " .
"This username is available</span>";
}
?>
–––––––––––––––––––––––––––

login.php – pagina de login

Asigur ă funcționalitatea de logare a utilizatorului.
–––––––––––––––––––––––––––
<?php
require_once 'header.php';
echo "<div class='main'><h3>Please enter your details to log in</h3>";
$error = $user = $pass = "";

if (isset($_POST['user']))
{
$user = sanitizeString($_POST['user']);
$pass = sanitizeString($_POST['pass']);
$aux = 'criptareparola';
$crypt_pa ss = md5($aux . $pass . $aux); // cripteaza parola cu sirul auxiliar

if ($user == "" || $pass == "")
$error = "Not all fields were entered<br>";
else

Modalit ăți de asigurare a securit ății web -siteurilor

71
{
// verifica daca datele sunt corecte(extrage din baza de date si verifica daca exista
corelatie intre nume si parola)
$result = queryMySQL("SELECT user,pass FROM members
WHERE user='$user' AND pass='$crypt_pass'");

if ($result ->num_rows == 0) // mesaj de eroare, in caz de incorectitudine
{
$error = "<span class='error'> Username/Password invalid</span><br><br>";
}
else // logheaza utilizatorul, daca datele sunt corecte
{
$_SESSION['user'] = $user;
$_SESSION['pass'] = $crypt_pass;
die("You are now logged in. Please <a href='members.php?view=$user'>" .
"click here</a> to continue.<br><br>");
}
}
}

echo <<<_END
<form method='post' action='login.php'>$error
<span class='fieldname'>Username</span><input type='text'
maxlength='16' name='user' value='$user'><br>
<span class='fieldname'>Password</span><input type='password'
maxlength='16' name='pass' value='$pass'>
_END;
?>
–––––––––––––––––––––––––––

profile.php – pagina de profil

–––––––––––––––––––––––––––
<?php
require_once 'header.php';

if (!$loggedin) die();

echo "<div class='main'><h3>Your Profile</h3>";

$result = queryMysql("SELECT * FROM profiles WHERE user='$user'");

if (isset($_POST['text'])) // opereaza asupra mesajului din profilul userului si il
introduce(sau il u pdateaza) in baza de date
{

Modalit ăți de asigurare a securit ății web -siteurilor

72
$text = sanitizeString($_POST['text']);
$text = preg_replace('/ \s\s+/', ' ', $text);

if ($result ->num_rows)
queryMysql("UPDATE profiles SET text='$text' where user='$user'");
else queryMysql("INSERT INTO profiles VALUES('$user', '$text')");
}
else
{
if ($result ->num_rows)
{
$row = $result ->fetch_array(MYSQLI_ASSOC);
$text = stripslashes($row['text']);
}
else $text = "";
}

$text = stri pslashes(preg_replace('/ \s\s+/', ' ', $text));

if (isset($_FILES['image']['name'])) // opereaza asupra fotografiei utilizatorului, ii
verifica tipul, o redimensioneaza la valorile potrivite si o incarca pe pagina
{
$saveto = "$user.jpg";
move_ uploaded_file($_FILES['image']['tmp_name'], $saveto);
$typeok = TRUE;

switch($_FILES['image']['type'])
{
case "image/gif": $src = imagecreatefromgif($saveto); break;
case "image/jpeg": // valabil pentru amandoua extensiile, jpeg si pjpeg
case "image/pjpeg": $src = imagecreatefromjpeg($saveto); break;
case "image/png": $src = imagecreatefrompng($saveto); break;
default: $typeok = FALSE; break;
}

if ($typeok)
{
list($w, $h) = getimagesize($saveto);

$max = 100;
$tw = $w;
$th = $h;

if ($w > $h && $max < $w)
{
$th = $max / $w * $h;
$tw = $max;
}

Modalit ăți de asigurare a securit ății web -siteurilor

73
elseif ($h > $w && $max < $h)
{
$tw = $m ax / $h * $w;
$th = $max;
}
elseif ($max < $w)
{
$tw = $th = $max;
}

$tmp = imagecreatetruecolor($tw, $th);
imagecopyresampled($tmp, $src, 0, 0, 0, 0, $tw, $th, $w, $h);
imageconvolution($tmp, array(array( -1, -1, -1),
array( -1, 16, -1), array( -1, -1, -1)), 8, 0);
imagejpeg($tmp, $saveto);
imagedestroy($tmp);
imagedestroy($src);
}
}

showProfile($user);

echo <<<_END
<form metho d='post' action='profile.php' enctype='multipart/form -data'>
<h3>Enter or edit your details and/or upload an image</h3>
<textarea name='text' cols='50' rows='3'>$text</textarea><br>
_END;
?>

Image: <input type='file' name='image' size='14'>
<input type='submit' value='Save Profile'>
<h2><a href = 'change_pass.php'><i>Change your password.</i></a></h2>
</form></div><br>
</body>
</html>
–––––––––––––––––––––––––––

change_pass.php – Schimbarea parolei din profilul de utilizator
–––––––––––––––––––––––––––
<?php
// Schimbarea parolei ca utilizator
require_once 'header.php';

echo "<div class='main'><h3>Enter your details to chang e your password.</h3>";

$new = $pass = $error = "";

if (!$loggedin) die();

Modalit ăți de asigurare a securit ății web -siteurilor

74

if (isset($_POST['user']))
{
$user = sanitizeString($_POST['user']);
$pass = sanitizeString($_POST['pass']);
$new = sanitizeString($_POST['new_pass']);
$aux = 'criptareparola';
$crypt_pass = md5($aux . $pass . $aux); // cripteaza parola veche…
$crypt_n ew = md5($aux . $new . $aux); // …si pe cea noua

if ($user == "" || $pass == "" || $new =="")
$error = "Not all fields were entered.Please try again.<br><br>";
else
{
// verifica, cu principiul apararii in adancime(care necesita inca o data credentialele de
acces), daca exista corelatie intre user si parola veche. Schimba parola veche cu cea noua
doar in caz afirmativ.
$result = queryMySQL("SELECT user,pass FROM members
WHERE user='$user' AND pass='$crypt_pass'");

if ($result ->num_rows == 0)
{
$error = "<span class='error'>Username/Password
invalid.Please try again.</span><br><br>";
}
else
{
queryMySQL("UPDATE members SET pass='$crypt_new'
WHERE user='$user'");
die("Your password was changed.Please log out and then log
in with your new password.<br><br>");
// utilizatorul ramane logat, dar este indicat sa se delocheze si apoi sa se loghez e din nou.
}
}
}

echo <<<_END
<form method='post' action='change_pass.php'>$error
<span class='fieldname'>Username:</span>
<input type='text' maxlength='16' name='user' value='$user'>
<br>
<span class='fieldname'>Password:</ span>
<input type='password' maxlength='16' name='pass' value='$pass'>
<br>
<span class='fieldname'>New password:</span>
<input type='password' maxlength='16' name='new_pass' value='$new'>
<br><br>
_END;

Modalit ăți de asigurare a securit ății web -siteurilor

75
?>

<input type='submit' value='Change Password'>
</form></div><br>
</body>
</html>
–––––––––––––––––––––––––––

members.php

Cu acest cod utilizatorii vor putea s ă gaseasc ă alți membri și să opteze s ă-i adauge
în lista de prieteni.
–––––––––––––––––––––––––––
<?php
require_once 'header.php';

if (!$loggedin) die();

echo "<div class='main'>";

if (isset($_GET['view']))
{
$view = sanitizeString($_GET['view']);

if ($view == $user) $name = "Your";
else $name = "$view's";

echo "<h3>$name Profile</h3>";
showProfile($view);
echo "<a class='button' href='messages.php?view=$view'>" .
"View $name messages</a><br><br>";
die("</div></body></html>");
}

if (isset($_GET['add'])) // adauga prietenii selectati de utilizator
{
$add = sanitizeString($_GET['add']);

$result = queryMysql("SELECT * FROM friends WHERE user='$add' AND
friend='$user'");
if (!$r esult ->num_rows)
queryMysql("INSERT INTO friends VALUES ('$add', '$user')");
}
elseif (isset($_GET['remove'])) // sterge prietenii selectati de utilizator
{
$remove = sanitizeString($_GET['remove']);
queryMysql("DELETE FROM friends WHE RE user='$remove' AND friend='$user'");

Modalit ăți de asigurare a securit ății web -siteurilor

76
}

$result = queryMysql("SELECT user FROM members ORDER BY user");
$num = $result ->num_rows;

echo "<h3>Other Members</h3><ul>";

for ($j = 0 ; $j < $num ; ++$j)
{
$row = $result ->fetch_array(MYSQLI_ASSOC);
if ($row['user'] == $user) continue;

echo "<li><a href='members.php?view=" .
$row['user'] . "'>" . $row['user'] . "</a>";
$follow = "follow";

$result1 = queryMysql("SELECT * FROM friends WHERE
user='" . $row['user'] . "' AND friend='$user'"); // extrage urmaritorii userului
$t1 = $result1 ->num_rows;
$result1 = queryMysql("SELECT * FROM friends WHERE
user='$user' AND fr iend='" . $row['user'] . "'"); // extrage membrii pe care
utilizatorul ii urmareste
$t2 = $result1 ->num_rows;

if (($t1 + $t2) > 1) echo " &harr; is a mutual friend"; // daca se urmaresc reciproc
elseif ($t1) echo " &larr; you are following"; // daca userul ii urmareste
elseif ($t2) { echo " &rarr; is following you"; // daca userul este urmarit
$follow = "recip"; }

// posibilitatea de adaugare prieteni care urmaresc userul
if (!$t1) echo " [<a href='members.php?add=" .$row['user'] . "'>$follow</a>]";
else
// posibilitatea de stergere prieteni pe care ii urmareste userul
echo " [<a href='members.php?remove=".$row['user'] . "'>drop</a>]";
}
?>

</ul></div>
</body>
</html>
–––––––––––––––––––––––––––

Modalit ăți de asigurare a securit ății web -siteurilor

77
messages.php – Posibilitatea trimiterii de mesaje publice sau private între useri
–––––––––––––––––––––––––––

<?ph p
require_once 'header.php';

if (!$loggedin) die();

if (isset($_GET['view'])) $view = sanitizeString($_GET['view']);
else
$view = $user;

if (isset($_POST['text'])) // opereaza asupra mesajului si il introduce in baza de date
{
$text = sanitizeString($_POST['text']);

if ($text != "")
{
$pm = substr(sanitizeString($_POST['pm']),0,1);
$time = time();
queryMysql("INSERT INTO messages VALUES(NULL, '$user',
'$view', '$pm', $time, '$text' )");
}
}

if ($view != "")
{
if ($view == $user) $name1 = $name2 = "Your"; // afiseaza mesajele userului
else
{
$name1 = "<a href='members.php?view=$view'>$view</a>'s";
$name2 = "$view's";
}

echo "< div class='main'><h3>$name1 Messages</h3>";
showProfile($view);

echo <<<_END
<form method='post' action='messages.php?view=$view'>
Type here to leave a message:<br>
<textarea name='text' cols='40' rows='3'></textarea><br>
Public<input type='radio' name='pm' value='0' checked='checked'>
Private<input type='radio' name='pm' value='1'>
<input type='submit' value='Post Message'></form><br>
_END;

if (isset($_GET['erase'])) // sterge mesajele selectate
{

Modalit ăți de asigurare a securit ății web -siteurilor

78
$erase = sanitizeString($_GET['erase']);
queryMysql("DELETE FROM messages WHERE id=$erase AND recip='$user'");
}

$query = "SELECT * FROM messages WHERE recip='$view' ORDER BY time
DESC";
$result = queryMysql($query);
$num = $result ->num_rows;

for ($j = 0 ; $j < $num ; ++$j)
{
$row = $result ->fetch_array(MYSQLI_ASSOC);

if ($row['pm'] == 0 || $row['auth'] == $user || $row['recip'] == $user)
// transmite mesaje, doar daca userii se urmaresc(sunt prieteni)
{
echo date('M jS \'y g:ia:', $row['time']);
echo " <a href='messages.php?view=" . $row['auth'] . "'>" . $row['auth']. "</a> ";

if ($row['pm'] == 0)
echo "wrote: &quot;" . $row['message'] . " &quot; "; // mesaj public
else
echo "whispered: <span class='whisper'>&quot;" . // mesaj privat
$row['message']. "&quot;</span> ";

if ($row['recip'] == $user)
echo "[<a href='messages.php?view=$view" .
"&erase=" . $row['id'] . "'>erase</a>]";

echo "<br>";
}
}
}

if (!$num) echo "<br><span class='info'>No messages yet</span><br><br>";
// mesaj de informare, in caz ca nu exista mesaje

echo "<br><a class='button' hre f='messages.php?view=$view'>Refresh messages</a>";
?>

</div><br>
</body>
</html>
––––––––––––––––––––––––

Modalit ăți de asigurare a securit ății web -siteurilor

79
friends.php – Listarea membrilor care sunt prieteni
––––––––––––––––––––––––
<?php
require_once 'header.php';

if (!$loggedin) die();

if (isset($_GET['view'])) $view = sanitizeString($_GET['view']);
else $view = $user;

if ($vi ew == $user)
{
$name1 = $name2 = "Your";
$name3 = "You are";
}
else
{
$name1 = "<a href='members.php?view=$view'>$view</a>'s";
$name2 = "$view's";
$name3 = "$view is";
}

echo "<div class='main'>";

// Sterge comentariul daca vrei ca profilul sa se vada aici
// showProfile($view);

$followers = array();
$following = array();

$result = queryMysql("SELECT * FROM friends WHERE user='$view'");
$num = $result ->num_rows;

for ($j = 0 ; $j < $num ; ++$j) // extrage urmaritorii userului
{
$row = $result ->fetch_array(MYSQLI_ASSOC);
$followers[$j] = $row['friend'];
}

$result = queryMysql("SELECT * FROM friends WHERE friend='$view'");
$num = $result ->num_rows;

for ($j = 0 ; $j < $num ; ++$j) // extrage membrii urmariti de user
{
$row = $result ->fetch_array(MYSQLI_ASSOC);
$following[$j] = $row['user'];
}

Modalit ăți de asigurare a securit ății web -siteurilor

80
$mutual = array_intersect($followers, $following);
$followers = array_diff($followers, $mutual);
$following = array_diff($following, $mutual);
$friends = FALSE;

if (sizeof($mutual))
// afiseaza lista de prieteni, in functie de caz: prieten, urmarit sau urmaritor.
{
echo "<span class='sub head'>$name2 mutual friends</span><ul>";
foreach($mutual as $friend)
echo "<li><a href='members.php?view=$friend'>$friend</a>";
echo "</ul>";
$friends = TRUE;
}

if (sizeof($followers))
{
echo "<span class='subhead'>$name2 follo wers</span><ul>";
foreach($followers as $friend)
echo "<li><a href='members.php?view=$friend'>$friend</a>";
echo "</ul>";
$friends = TRUE;
}

if (sizeof($following))
{
echo "<span class='subhead'>$name3 following</span><ul>";
foreach($following as $friend)
echo "<li><a href='members.php?view=$friend'>$friend</a>";
echo "</ul>";
$friends = TRUE;
}

if (!$friends) echo "<br>You don't have any friends yet.<br><br>";

echo "< a class='button' href='messages.php?view=$view'>" .
"View $name2 messages</a>";
?>

</div><br>
</body>
</html>
––––––––––––––––––––––––

Modalit ăți de asigurare a securit ății web -siteurilor

81
logout.php
––––––––––––––- ––––––––––
<?php
require_once 'header.php';

if (isset($_SESSION['user']))
{
destroySession();
echo "<div class='main'>You have been logged out. Please " .
"<a href='index.php'>click here</a> to refresh the screen.";
}
else echo "<div class='main'><br>" .
"You cannot log out because you are not logged in";
?>

<br><br></div>
</body>
</html>
––––––––––––––––––––––––

Modalit ăți de asigurare a securit ății web -siteurilor

82
Bilbliografie

1. Anghel, Traian , Dezvoltarea aplicațiilor Web folosind PHP si AJAX , EduSoft, 2007.
2. Buraga, Sabin (coord.) , Tendinte actuale in proiectarea si dezvoltarea aplicațiilor
Web, Matrix Rom, Bucuresti, 2006.
3. Darie, Cristian; Brinzarea, Bogdan; Cheeches -Tosa, Filip; Bucica, Mihai, AJAX and
PHP: Building Responsive Web Applications, Packt Publishing, 2006
4. Davis, Michele; Phillips, Jon, Learning PHP & MYSQL: Step -By-Step Guide to
Create Database -Driven Web Sites , O‟Reilly, 2007.
5. Deslie, Marc , Mastering phpMyAdmin 1.3 for Effective MySQL Management , Packt
Publishing, 2009.
6. DuBois, Paul, MySQL, 5th Edition , Developer's Library, 2013.
7. Harwood , Mike; Goncalves , Marcus; Pemble ,Matthew , Security Strategies in Web
Applications and Social Networking , Jones & Bartlett Learning, 2010.
8. Lavin, Peter, Object -Oriented PHP, Concepts, Techniques and Code , No Starch
Press, 2006.
9. Lerdorf, Rasmus; Tatroe, Kevin; MacIntyre, Peter, Programming PHP , O‟Reilly,
2006.
10. Lepofsky , Ron, The Manager’s Guide to Web Application Security: A Concis e
Guide to the Weaker Side of the Web , Apress, 2014.
11. Nahari , Hadi; Krutz, Ronald, Web Commerce Security Design and Development ,
John Wiley & Sons, 2011.
12. Palmer, Steven, Web Application Vulnerabilities , Syngress, 2011.
13. Schafer, S. , Web St andards Programmer’s Reference: HTML, CSS, JavaScript,
Perl, Python and PHP , Wrox, 2005.
14. Shema, Mike, Hacking Web Apps , Syngress, 2012.
15. Shiflett, Chris, Essential PHP Security , O‟Reilly, 2005.
16. Ullman, Larry, PHP și MySQL pentru site -uri web dinamice , Editura Teora, 2014.
17. Welling, Luke; Thomson, Laura, PHP and MySQL Web Development , Fourth
Edition, Addison -Wesley, 2009.
18. http://www.php.net/
19. http://www.w3schools.com/php/php_intro.asp
20. http://www.mysql.com
21. https://www.startssl.com