Securitatea Informaţiei

Vulnerabilitatea Cross-Site Request Forgery (CSRF) [se pronunţă Sea-Surf] se caracterizează prin faptul că aplicaţia web nu poate efectua verificări suficiente, pentru a determina dacă cererea primită de aplicaţie este consistentă, formată corect şi dacă a fost efectuată într-adevăr de către utilizatorul care a efectuat cererea şi nu de către altcineva.

Dacă un server/o aplicaţie web este concepută pentru a primi o cerere din partea unui client, fără nici un mecanism de verificare a autencităţii cererii (dacă aceasta a fost trimisă în mod intenţionat), atunci ar putea fi posibil ca un atacator să forţeze browserul unui client să efectuieze o cerere neintenţionată către serverul web, care va fi tratată ca o cerere autentică. Exploatarea acestei vulnerabilităţi poate fi efectuată prin intermediul unui URL, a unei imagini, a unei cereri XMLHttpRequest, etc. şi poate avea drept consecinţă divulgarea de date sau executarea de cod neintenţionat.

Exploatarea vulnerabilităţii Cross-Site Request Forgery(CSRF) este un alt tip de atac. În loc să exploateze încrederea pe care o are un utilizator într-o aplicaţie web, atacurile CSRF exploatează încrederea pe care o are un site în utilizatorii săi.

Impact

Consecinţele vor varia în funcţie de natura funcţionalităţii vulnerabile la CSRF. Un atacator ar putea efectua în mod eficient orice operaţiuni în calitate de victimă. În cazul în care victima este un administrator sau utilizator privilegiat, consecinţele pot fi: obţinerea control complet asupra aplicaţiei web – stergerea sau furtul de date, dezinstalarea produsului, sau utilizarea aplicaţiei pentru a lansa alte atacuri împotriva tuturor utilizatorilor produsului. Deoarece atacatorul a identitatea victimei, domeniul de aplicare al CSRF este limitat doar de drepturile de acces ale victimei. Deci putem afirma că în cazul în care ţinta atacului CSRF va fi utilizatorul aplicaţiei cu drepturi depline de acces, impactul va fi maximal: sistemul va fi compromis din punct de vedere al confidenţialităţii, integrităţii şi confidenţialităţii.

Probabilitate

1. Necesitatea autentificării utilizatorului în sistem – Ţinta atacurilor de exploatare a vulnerabilităţii CSRF sunt utilizatorii autentificaţi în sistem. De aceea o autentificare suplimentară nu e necesară.

2. XSS favorizează substanţial exploatarea CSRF. Pentru a concentra atacul asupra utilizatorilor autentificaţi în sistem, această vulnerabilitate poate fi favorizată de vulnerabilitatea Cross Site Scripting (XSS). Exploatarea vulnerabilităţii XSS poate fi utilizată pentru a obţine date de autentificare ale utilizatorului, care apoi pot fi utilizate în atacul asupra vulnerabilităţii CSRF, compromiţînd astfel măsuri de control existente de protecţie împotriva atacurilor de exploatare a vulnerabilităţii CSRF.

3. În dependenţă de nivelul de competenţă în abordare a dezvoltatorului aplicaţiei asupra mecanismelor de interacţiune utilizate pentru a efectua o operaţiune, exploatarea acestei vulnerabilităţi în unele cazuri necesită careva cunoştinţe în domeniu dezvoltării aplicaţiilor web şi cunoştinţe despre sistemul vulnerabil, însă în majoritatea cazurilor cunoştinţele necesare sunt minime şi în mare parte acţiunile efectuate pentru exploatare sunt intuitive.

Ţinînd cont de aceste 3 aspecte putem afirma că probabilitatea de exploatare a vulnerabilităţii CSRF este de la medie spre mare.

Exemple

Exemplul 1.

Acest exemplu presupune următorul context:
- În directoriul fişiere sunt stocate în fişiere (de tip: articol_1.txt, articol_2.txt, etc) articolele unui autor.
- Articolul care necesită a fi şters va fi specificat prin parametrul ARTICOL_ID. Adică dacă se cere a fi şters fişierul articol_5.txt trebuie de indicat ARTICOL_ID cu valoarea 5.
- Operaţiunea de ştergere a fişierului din sistem este reglementată prin drept de acces implicit de către administratorul aplicaţiei. Adică, ştergerea unui fişier din sistem prin intermediul interfeţei aplicaţiei web, va putea fi efectuată doar de către un utilizator căruia administratorul aplicaţiei i-a acordat acest drept.

<?php
...
/*
 * Verificare: dacă utilizatorul care a efectuat cererea 
 * este autorizat de a efectua operaţiunea de "stergere"
 *  a unui fisier in sistem
 */
verificare_autorizare("stergere"); 
 
/*
 * Operaţiunea propriu-zisă de ştergere a fişierului
 */
 
if(isset($_GET['ARTICOL_ID']))
{
 unlink('fisiere/articol_'.$ARTICOL_ID.'.txt');
 echo ('Fişierul a fost şters.')
}
else
{
die('Fişierul nu a fost şters');
}
...
?>

Accesarea acestui script de către un utilizator autorizat în sistem prin accesarea http://securitate.md/exemplul_1.php?ARTICOL_ID=5 va şterge şterge fişierul fisiere/articol_5.txt. Tot ce rămîne de făcut este de a convinge un utilizator cu drepturile de acces de rigoare să acceseze acest URL.

Exemplul 2.

Cred că mulţi îşi amintesc că în anul 2002 serviciul gratuit de e-mail mail.md era vulnerabil CSRF şi XSS, şi exploatînd aceste vulnerabilităţi în ansamblu, era posibil de obţinut acces complet, la cutia poştei eletronice a victimei.

La adresa URL http://mail.md/cgi-bin/login?sessionid=nume_utilizator:0:1:0:6:xxxxxxxx:16:26:0:1 era accesibilă funcţionalitatea de modificare a întrebării secrete şi răspunsului la aceasta. Însă pentru efectuarea operaţiunii de modificare a parolei era nevoie de un token “xxxxxxxx” care era unic pentru fiecare autentificare a utilizatorului. Însă funcţionalitatea de ataşare a fişierelor, era vulnerabilă XSS, ceea ce permitea executarea unui cod javascript care obţine token-ul în mod automatizat. Astfel acesarea unui fişier textual cu conţinutul de mai jos, ataşat la o scrisoare modifica întrebarea secretă şi răspunsul la aceasta.

<img src="http://" onmouseover=" 
line1=parent.frames[0].document.links[0]; 
line2=line1.href; 
a3=line2.length; 
a3Ј-7; 
line3=line2.substring(43,a3); 
line3=line3+'16:26:1:1'; 
document.forma.sessionid.value=line3; 
document.forma.submit();"> 
<form name=forma action="/cgi-bin/login" method=post> 
<input type=hidden name="sessionid" value=""> 
<input type=hidden name="questionr" value="intrebarea secreta noua"> 
<input type=hidden name="passremin" value="raspunsul secret nou"> 
</form>

Măsuri de control

1. Transmiterea informaţiilor prin POST, în cazul efectuării unor operaţiuni, omite doar posibilitatea de a exploata această vulnerabilitate prin includerea unei imagini şi accesarea unui link. Însă la momentul actual, Javascript este capabil de a efectua cereri prin POST, adică această măsură de control nu este suficientă pentru a asigura o protecţie adecvată împotriva exploatării vulnerabilităţii CSRF.

2. Verificarea HTTP_REFERER. E logic de considerat că atacurile CSRF au ca sursă de lansare surse web-externe, adică HTTP_REFERER este altul decât cel care ar trebui să fie cînd funcţionalitatea e utilizată legitim, însă nu e corect de considerat că implementarea acestei măsuri de control va asigura protecţie adecvată împotriva acestor atacuri. Fiindcă s-a demonstrat că anumite tehnici Flash ActionScript şi anumite browsere permit evitarea acestei măsuri de control.

3. Vulnerabilităţile XSS sunt capabile de a face inutilă orice soluţie de protecţie împotriva atacurilor CSRF. De ex. Samy Worm orientat pe MySpace a reuşit să evite protecţiile CSRF ale site-ului prin utilizarea XSS pentru a obtine token-uri şi de a compromite sistemul.
Important: Dacă aveţi de gând să implementaţi măsuri de control CSRF, trebuie să omiteţi toate vulnerabilităţile XSS (Cross Site Scripting).

4. Cea mai bună metodă de protecţie împotriva atacurilor de exploatare a vulnerabilităţilor CSRF este implementarea token-urilor imprevizibile – date care serverul le poate utiliza pentru a valida o cerere, date pe care utilizatorul nu le poate ghici. De exemplu: O cerere importantă poate conţine un hash al sesiunii utilizatorului autorizat, diferită pentru fiecare utilizator, combinat cu timpul accesării token-ului.
token = md5(sesiune + timestamp)

Exemplu de token implementat:

POST http://securitate.md/operatiune_critica.php HTTP/1.1
Host: securitate.md
Cookie: PHPSESSIONID= 4353DD35694D47990BCDF36271740A0C
from=314159265&to=011235813&amount=5000&date=11072006&token=4e0fc1a82c3ca3b9d2a146
2570f6c674&timestamp=1184001456

Sugestiile şi comentariile sunt binevenite. Be Safe.