In zilele noastre cea mai mare parte a informatiei, de care avem nevoie atat în viata de zi cu zi cat si în 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 în magazinele virtuale sau chiar e-banking, folosim aceasta minunata unealta aparent buna la toate, internetul. Însa, ceea ce majoritatea utilizatorilor nu stiu despre internet este ca, pe cat este de atractiv pe atat este de vulnerabil în fata atacurilor cibernetice.
Acestea sunt cele mai mai des întalnite vulnerabilitati ale aplicatiilor web, dupa clasamentul celor de la Trustwavea??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 pre 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 în cazul diferitelor servere de bazele de date, însa, 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 într-o interogare SQL sau cand, prin injectarea sintaxei, logica declaratiei, sa fie modificata în asemenea fel încat sa execute o actiune diferita. Injectia SQL poate fi cruciala pentru sistem dar, în ciuda pericolului pe care îl prezinta, este una din cele mai frecvente vulnerabilitati.
Atacul: Metode de prevenire a atacurilor de tip SQL injection:
Metodele de aparare împotriva atacurilor ar trebui sa fie adresate direct tipurilor de atac specifice bazelor de date si sa poata minimiza impactul unui brese în cazul în care una din metodele de aparare s-a dovedit inadecvata. Cea mai buna metoda de aparare împotriva injectiilor SQL se bazeaza pe rutine puternice de validare a datelor de intrare.
Exista masuri specifice care pot fi luate în 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 întregi 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 întreg, acest lucru îi împiedica 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 în browser nu accepta decat numere întregi. 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 într-o variabila care utilizeaza 256 de caractere. Limitarea numarului de caractere care poate fi introdus într-un camp poate împiedica în mod eficient succesul unei injectii SQL, reducand, lungimea sirului de caractere pe care atacatorul îl poate introduce în 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” + variablea), 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, însa, nu îi va permite unui atacator sa manipuleze întreaga intrerogare.
• Aplicati separarea datelor si accesul pe baza de rol în 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, în 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 într-un limbaj de programare, nu înseamna nimic altceva decat descompunerea unui process complex în pasi mici si simplii, pentru, a aduce ceea ce este pe întelesul oamenilor la nivelul la care poate fi executat de catre computer iar atunci cand un numar mare de programatori si designer diferiti, lucreaza în 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, însa, sunt trecute cu vedrea deoarece, rareori, poat fi scanate cu programe specializate în 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 în considerare un anumit efect (cel pe care el intentioneaza sa-l implementeze în primul rand) si omitand alte efecte posibile (secundare). Deoarece, în general, sunt mai greu de înteles 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 învatate 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 într-o aplicatie web utilizata de catre o societate de servicii financiare si, de asemenea, în aplicatia AIM Enterprise AOL Gateway.
Functionaliatea: aplicatia consta într-o functie pentru schimbarea parolei de catre utilizatorii finali, în 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 în aplicare în cadrul aceluiasi script pe partea serverului.
Presupunerea: Interfetele afisate clientilor si administratorilor difereau într-un singur aspect a?? 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 în faptul ca programatorii au presupus ca utilizatorii obisnuiti for furniza intotdeuna vechea parola.
String existingPassword = request.getParameter(a??existingPassword”);
if (null == existingPassword)
{
trace("Old password not supplied, must be an administrator”);
return true;
}
else
{
Trace("??Verifying usera??s old password”);
...
}
Atac : Odata ce ipoteza a fost formulata în mod explicit în 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 într-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, înregistrand fiecare actiune efectuata si identitatea utilizatorului care a responsabil. Aplicatia includea o functie care le permitea administratorilor sa sterga anumite înregistrari de audit, însa pentru a evita exploatarea în scopuri rau-voitoare, orice utilizare a functiei de stergere era la randul ei înregistrata, pentru a se putea sti utilizatorul responsabil de utilizarea acestei functii.
Presupunerea: designerii aplicatiei au crezut ca nimeni nu poate sterge înregistrarile de audit fara a lasa macar o urma (aceasta presupunere a fost testata de catre administratorii lor, intotdeuna ramanand ultima înregistrare 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 îti sterge urmele în întregime. 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 înregistrarile generate de primele trei etape.
Fiecare din actiuni genereaza înregistrari în jurnalul de audit, dar pentru ca în ultima faza ultimul cont sterge toate datele legate de intrarile precedente, în 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 înregistrarile 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 întelese de cineva din exterior.
• Lasati comentarii în codul sursa care sa includa urmatoarele informatii:
Scopul si functionalitatea fiecarei bucati de cod.
Presupunerile facute de fiecare componenta în 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 îl folosesc.
• În timpul recenziilor de securitate referitoare la cod, plecati de la ideea pe care a avut-o designerul si mergeti înspre modul în care ar putea influenta utilizatorii aplicatia.
• În timpul verificarii de securitate puneti accent pe modul în care se comporta aplicatia în momentul în 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, în concordanta cu politicile sistemului, indiferent de identitalea lui/ei reala (aici ne referim la aplicatii web unde în general utilizatorii nu îsi folosesc numele reale ci pseudonime) poarta numele de autorizatie.
Vulnerabilitatile ce tin de autorizatii si acces pot aparea oriunde în aplicatia web, si se refera la ce se întampla atunci cand un atacator are acces la o resursa, la care, în mod normal au acces doar utilizatorii autentificati sau care detin anumite privilegii în 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 în 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 într-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 în: http://www.exemplu.com/index.php?page=../../../../../../../etc/passwd.
Luati în 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, într-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 împotriva 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 într-un eventual atac informatic, acest lucru nu se refera doar la campurile în 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 înainte 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, în HTML (Hypertext Markup Language)/ JavaScript (numit malware)), pe care îl executa ulterior în 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 în browser, deoarece, adevarata tinta a atacului este utilizatorul. Hackerul va folosi doar site de încredere pentru a efectua atacul , si odata ce are control asupra browser-ului utilizatorului, îl va putea folosi pentru a îi: fura un cont victimei, înregistrarea tastelor apasate de la tastatura victimei, furtul înregistrarilor 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 în JavaScript poate deveni rezident pe o pagina web:
• Proprietarul paginii web îl poate încarca 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 într-o zona publica a paginii web.
• Victima poate accesa un link special pregatit în 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 întai 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 înapoi (de obicei un camp pentru cautare).
Daca introduce a??test pentru xss” în 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: “>;;alert(‘XSS%20Testing’). 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 în plus pentru afisarea promotiilor si ca interogarile din URL-urile pentru afiseare produselor îsi 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 în acest fel:
Din: http://vulnerabil/promo?product_id=100&title=Last+Chance!
În: http://victim/promo?product_id=100&title=Foo#;alert(‘XSS%20Testing’)<;/script>;
În acest caz JavaScript-ul de pe partea clientului are încredere orbeste în 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 îi spune browser-ului în ce punct al documentului curent sa sara (ramane în 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 într-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, în timp ce, codarea datelor de iesire va ofere posibilitatea de a face fata tuturor utilizarilor textului si pozitionarea acestuia în 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 în 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 întelegeti în 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 împotriva 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 înainte de a stoca informatii în 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 în 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, într-o oarecare masura, identitatea unei persoane sau entitati. De exemplu, toti folosim parole pentru a ne loga în conturile personale de e-mail. Prin asta ne dovedim identitea. Paginile web folosesc certificate Secure Socket Layer (SSL) pentru a valida ca traficul provine într-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 îi se atribuie un token de sesiune unic de obicei sub forma de cookie-uri. Acest lucru ajuta site-ul web sa îsi diferentieze utilizatorii între ei si li se atribuie utilizatorilor atunci cand acceseaza pagina web, înainte 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 îl compromite, ghicindu-i valoarea sau furandu-l, reuseste sa treaca cu success de mecanismul de autentificare a paginii respective si sa îi 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 ; 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 în mod automat o cerere catre pagina tinta folosind cookie-ul de sesiune al victimei.
• SQL Injection: unele aplicatii web stocheaza cookie-urile de sesiune într-o baza de date, în loc sa le stocheze într-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, însa majoritatea aplicatiilor web folosesc HTTP pentru restul paginilor, HTTPS protejeaza parola utilizatorului, în timp ce, HTTP expune cookie-ul de sesiune în vazul tuturor, mai ales prin retelele wireless din locurile publice (cafenele, aeroporturi, scoli, etc.).
Metode de aparare impotriva atacurilor de tip authentication bypass:
Autentificarea dovedeste, într-o oarecare masura, identitatea unei persoane sau entitati. De exemplu, toti folosim parole pentru a ne loga în conturile personale de e-mail. Prin asta ne dovedim identitea. Paginile web folosesc certificate Secure Socket Layer (SSL) pentru a valida ca traficul provine într-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 îi se atribuie un token de sesiune unic de obicei sub forma de cookie-uri. Acest lucru ajuta site-ul web sa îsi diferentieze utilizatorii între ei si li se atribuie utilizatorilor atunci cand acceseaza pagina web, înainte 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 îl compromite, ghicindu-i valoarea sau furandu-l, reuseste sa treaca cu success de mecanismul de autentificare a paginii respective si sa îi 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
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 în mod automat o cerere catre pagina tinta folosind cookie-ul de sesiune al victimei.
• SQL Injection: unele aplicatii web stocheaza cookie-urile de sesiune într-o baza de date, în loc sa le stocheze într-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, însa majoritatea aplicatiilor web folosesc HTTP pentru restul paginilor, HTTPS protejeaza parola utilizatorului, în timp ce, HTTP expune cookie-ul de sesiune în vazul tuturor, mai ales prin retelele wireless din locurile publice (cafenele, aeroporturi, scoli, etc.).
Mecanismele de sesiune si autentificare a unui site trebuie sa fie folosite în cadrul unor practici bune de securitate, deoarece fara masuri bune de contraatac, o slabiciune într-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 înainte 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 a??admin”. Aceasta este o bresa grava de securitate deoarece, fiind atat de usor de a??ghicit” numele de utilizator si parola, un atacator poate accesa orice parte a aplicatiei web, inclusive cea a consolei de comanda, în 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 înainte 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 într-un program va pot pune în pericol întreaga 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 în 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.
• Între 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 în 30 de zile de la lansarea pe piata.
• Vulnerabilitatea la injectiile cu cod SQL scade încet.
• Construirea de software bine securizat nu trebuie sa consume mult timp.
Nu exista nici o aplicatie care este 100% lipsita de vulnerabilitati, însa, puteti încerca sa reduceti cat mai mult aceste probleme, dar acest lucru nu se va întampla decat daca testati amanuntit întreaga aplicatie web pentru a descoperi punctele ei slabe si a încerca 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, însa acestea nu sunt foarte raspandite datorita costurilor mari de achizitionare. O gama larga de erori legate de conturi si managementul sesiunilor rezulta în 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, în toate aspectele aplicatiei web. Paginile web au nevoie de sesiuni pentru a putea monitoriza valul de cereri venit de la fiecare utilizator în 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, însa multi dezvoltatori prefera sa îsi creeze propriile token-uri de sesiune.
Daca toate credentialele de autentificare si identificatorii de sesiune nu sunt protejate corespunzator, prin SSL în permanenta, protejate împotriva divulgarii si alte tipuri de erori, cum ar fi vulnerabilitatea la cross-site scripting, un atacator poate fura sesiunea unui utilizator si sa îsi 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 îndeplinesc 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 îsi 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 încerca într-o anumita unitate de timp iar tentativele esuate de autentificare ar trebui logate, însa parolele introduse nu ar trebui înregistrate, 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 în care acest lucru se inatmpla. Utilizatorul sa trebuiasca întotdeauna 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 îsi 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 a??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: în mod ideal, întreaga sesiune a utilizatorului ar trebui protejata prin SSL (în acest mod cookie-ul de sesiune nu ar putea fi furat).
• Liste de conturi: sistemele ar trebui proiectate în asa fel încat sa nu permita accesul utilizatorilor la lista de conturi înregistrate pe site. Daca este imperativ sa fie prezentata o lista de acest gen se recomanda folosirea pseudonimelor în locul numelor reale. În acest fel, pseudonimul nu poate fi folosit pentru logare în cont în timpul unei încercari de autentificare a unui atacator pe site.
• Relationari bazate pe încredere: arhitectura paginii dumneavoastra ar trebui sa evite relatiile implicite de încredere între componente ori de cate ori este posibil acest lucru. Fiecare componenta în parte ar trebui sa se autentifice fata de o alta cu care interactioneaza. Daca o relatie de încredere este absolut necesara, atunci ar trebui ca aceasta nu poata fi , prin mecanisme procedurale de , care protejeze chiar cadrul unei dezvoltari timp.
8. Cross-site Request Forgery (CSRF)
Cross a??site Request Forgery (CSRF sau XSRF) este o forma de atac asupra aplicatiilor web care se foloseste de relatiile de încredere existente între aplicatiile web si utilizatorii autentificati prin a forta acei utilizatori sa faca tranzactii sensibile în numele atacatorului. Aceasta vulnerabilitate, desi mai putin cunoscuta ca XSS, este mult mai periculoasa decat cross-site scripting, deoarece, îsi are radacinile în natura lipsita de stare ale specificatiilor HTTP-ului, care cer ca un token de autentificare sa fie trimis cu fiecare cerere a utilizatorului.
În mod obisnuit, vulnerabilitatile web apar ca urmare a unor greseli facute de dezvoltatorii paginilor web în timpul proiectarii si dezvoltarii acestora, sau de catre administratori în 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, carré le permite utilizatorilor sa transfere fonduri dintr-un cont în 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">// <![CDATA[ ; Var i document.createElement(a??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 în HTML (), 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 în fundal o cerere HTTP GET legata la sursa imaginii dinamice iar actiunea va fi executata ca si cum utilizatorul ar fi facut-o în mod voluntar.
Metode de prevenire a vulnerabilitatilor de tip Cross-site Request Forgery:
• Cookie-uri postate de doua ori: aceasta metoda de aparare consta în 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 într-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, în 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 împotriva CSRF si consata în construirea fiecarui formular folosind un camp ascuns care contine un nonce (number used once) obtinut folosind un generator pseudoaleator de numere securizate prin încriptare, 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 în 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 în care sunt autentificati ori de cate ori fac o tranzactie sensibila. Acesta strategie este des întalnita în aplicatiile web în cadrul carora tranzatiile de o natura sensibila se întampla rar (cel mai adesea fiind schimbari ale informatiilor de pe profilul utilizatorului).
9. Verbose Errors
Nu sunt un tip de atac în sine, însa 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 în care ruleaza.
Un formular tipic de autentificare îi 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 în mod evident sa îti dai seama ca una din informatiile introduse nu au fost corecte, însa uneori, apicatia, te anunta care din ele a fost gresita, acest lucru poate fi folosit pentru a diminua eficienta mecanismului de autentificare. În 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:
Într-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 în general numele utilizatorilor nu sunt considerate a fi secrete, identificarea lor îi 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.
În 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 în 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 înainte 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 îndeplinesc tipul de baza, formatul, si lungimea cerute.
• Utilizati codarea securizata a caracterelor si validarea datelor de iesire: caracterele utilizate în formatele HTML si SQL ar trebui codate în asa masura încat, sa împiedice aplicatia sa le interpreteze gresit. Acest tip de validara a datelor de iesire sau de reformatare a caracterelor reprezinta un nivel additional de protejare împotriva atacurilor prin injectare HTML, chiar daca un cod malitios reuseste sa treaca de un filtru de intrare a datelor, efectele acestuia vor fii neglijate în momentul în care ajunge în 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, în final cand vine vorba de tratarea exceptiilor. Incearcati o actiune, descoperiti exceptiile specifice care pot fi cauzate de acea actiune; în final închideti aplicatia daca nimic altceva nu functioneaza. De asemenea creati un mesajde eroare politicos care însa nu dezvaluie nici o informatie despre sistem.
• Solicitati autentificare: în unele cazuri s-ar putea sa fie necesar sa configurati serverul în asa masura încat sa fie solicitata autentificarea la nivelul de director pentru toate fisierede din interiorul acelui director.
10. Source pre Disclosure
Divulgarea codului sursa este o eroare de codare foarte des întalnita în aplicatiile web, care poate fi exploatate de catre un atacator pentru a obtine codul sursa si configurearea fisierelor prin intermediul HTTP, acest lucru îi ofera atacatorului o întelegere 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 întai serverul executa fisierul si apoi returneaza rezultatul în 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 îi ofera atacatorului o imagine mai buna asupra logicii aplicatiei, modul în care aplicatia gestioneaza cererile si parametrii lor, structura bazei de date, vulnerabilitatile codului si comentariile introduse în 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 în 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 în serverele IIS cand vine vorba de gestionarea fisierelor .asp, care îi 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 în Unipre pentru a obtine un fisier .asp (%61%73%70 este codul Unipre pentru a??asp”), serverul IIS nu îl va recunoaste ca si fisier ASP asadar nu îl va executa, ci va trimite codul sursa ASP direct browserului.
Metode de prevenire a atacurilor de tip Source pre 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 într-o lume în 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 într-o afacere este cea facuta pentru protejarea datelor pe care aceasta le detine.
Sursa: worldit.info