Cross-Site Scripting (XSS)

Cross-Site Scripting – cunoscut sub numele de XSS – este o vulnerabilitate a aplicațiilor care are potențialul de a face ravagii în aplicații și site-uri web. XSS este atât de răspândită și potențial dăunătoare încât continuă să fie inclusă în lista celor mai importante 10 vulnerabilități a Open Web Application Security Project (OWASP).

De fapt, Cross-Site Scripting este cea mai frecventă vulnerabilitate descoperită începând cu 2014, iar în 2019 continuă să apară în Top 3 al vulnerabilităților raportate.

În unele cazuri, scriptul din partea browserului poate introduce, de asemenea, această vulnerabilitate, permițând unui atacator să o exploateze fără ca utilizatorul țintă să facă o cerere către aplicația web.

Atacatorii exploatează XSS prin crearea unui cod malițios care poate fi direcționat către un alt utilizator, este apoi executat de browserul neștiutor. Deoarece scriptul este de cele mai multe ori inclus în conținutul răspunsului aplicației web, acesta este executat și are același acces ca și cum scriptul ar fi legitim. Se poate permite accesul la jetoane de sesiune, cookie-uri și chiar la informații confidențiale sau sensibile la care browserul are acces pe site-ul respectiv, chiar și la rescrierea conținutului paginii HTML.

Atacurile XSS reflectate

În atacurile XSS reflectate, scriptul malițios este injectat într-o cerere HTTP (de obicei, prin intermediul unui link special creat furnizat utilizatorului). Fiind cea mai simplă variantă, acesta utilizează parametri de intrare în cererea HTTP care pot fi ușor de manipulat pentru a include conținutul scriptului dăunător. Scriptul malițios este apoi reflectat de server într-un răspuns HTTP și este executat în browserul victimei.

În acest caz, acționează ca un XSS stocat fără a stoca efectiv date malițioase pe server.

Iată un exemplu de atac XSS reflectat:

Să spunem că exemplu.com/profile conține un parametru nume. URL-ul pentru cerere ar arăta în felul următor: https://example.com/profile?user=Tammy. Pe baza acestei intrări, aplicația web ar răspunde astfel cu „Bună Tammy” în partea de sus a paginii. Dacă parametrii nu sunt validați pentru a se asigura că aceștia conțin doar datele așteptate, un atacator ar putea face ca un utilizator să viziteze o versiune malițioasă a URL-ului, cum ar fi aceasta: https://example.com/profile?user<script>some_malicious_code</script>.

Când răspunsul este trimis către browser, acesta include acel script malițios, care este apoi executat în browser, probabil fără ca utilizatorul să știe. Acesta este un exemplu de atac XSS reflectat, deoarece codul malițios este imediat „reflectat” înapoi către utilizatorul care face cererea.

Atacurile XSS stocate

În ceea ce este cunoscut ca un atac XSS stocat sau persistent, conținutul malițios este livrat direct, împreună cu răspunsul serverului atunci când utilizatorul încarcă o pagină web. Astfel, conținutul este deja stocat în baza de date a site-ului web (de unde și numele pentru astfel de atacuri). Utilizatorii intră apoi pur și simplu pe pagina web piratată și cad victime ale unor astfel de atacuri.

Care utilizator care deschide un astfel de site web compromis riscă astfel să i se fure datele personale, astfel că acesta ar putea fi considerat cel mai periculos tip de atac XSS.

Dar cum ajunge conținutul malițios în baza de date pentru început? În cele mai multe cazuri, acesta este introdus prin intermediul unor formulare de pagină web neprotejate, în care datele introduse de utilizator nu sunt validate și dezinfectate corespunzător. Dacă datele introduse de un hacker nu sunt validate atât pe partea de client, cât și pe partea de server, acestea vor fi salvate în baza de date. De exemplu, o astfel de intrare ar putea include o zonă de text pentru comentarii, un editor de text pentru postări, un editor de date personale sau alte formulare.

După ce un atacator reușește să trimită conținut malițios către server și acel conținut apare nefiltrat pe o pagină web, toți utilizatorii devin potențiale victime.Remediul comun pentru atacurile XSS stocate este de a igieniza intrările atât în partea frontală cât și în partea din spate a aplicației. Sanitizarea implică o combinație de validare a datelor și de scăpare a caracterelor speciale sau de filtrare completă a acestora și este o bună practică comună pentru securitatea web și JavaScript.

Atacurile XSS bazate pe DOM

Document Object Model (DOM) este o interfață care permite aplicațiilor să citească și să manipuleze structura unei pagini web, conținutul și stilul acesteia. Într-un atac XSS bazat pe DOM, vulnerabilitatea se află în codul de script din partea browserului și poate fi exploatată fără nicio interacțiune cu serverul, modificând mediul din browserul victimei care nu bănuiește nimic.

Câteodată, atacurile XSS bazate pe DOM sunt similare cu atacurile reflectate. Exemplul de mai sus al unui atac XSS reflectat poate fi aplicat în acest caz cu o singură ipoteză: Aplicația web citește datele direct dintr-un șir de interogare.

Să spunem că aplicația utilizează parametrul de interogare „nume” pentru a afișa instantaneu numele utilizatorului pe ecran în timp ce așteaptă să se încarce restul paginii. Fără o validare adecvată, acest lucru poate avea același rezultat ca și în cazul unui atac reflectat, dacă hackerul reușește să facă victima să deschidă un link suspect.

Ca și în cazul XSS-ului stocat, pentru a preveni atacurile reflectate și bazate pe DOM, dezvoltatorii ar trebui să implementeze validarea datelor și să evite afișarea intrărilor brute ale utilizatorului, în ciuda prezenței sau absenței comunicării cu serverul.

Care sunt vectorii de atac Cross-site Scripting?

Există mai mulți vectori utilizați în mod obișnuit în atacurile XSS:

• <eticheta script>: O etichetă script poate fi utilizată pentru a face referire la codul JavaScript extern, ceea ce face ca acesta să fie cel mai simplu punct XSS. Atacatorii pot încorpora, de asemenea, codul malițios în cadrul tag-ului script.
• Evenimente JavaScript: Un alt vector XSS popular utilizat de atacatori, atributele de eveniment, pot fi aplicate într-o varietate de tag-uri. Atribute cum ar fi „onerror” și „onload” sunt exemple.
• <body> tag: Atributele de eveniment pot fi, de asemenea, sursa scriptului atunci când sunt furnizate prin intermediul tag-ului „body”.
• <img> tag: În funcție de browserul utilizat, acest atribut poate fi folosit de atacatori pentru a executa codul JavaScript.
• <iframe> tag: Deosebit de eficient pentru atacurile de phishing, acest vector permite atacului XSS să încorporeze o altă pagină HTML în pagina curentă.
• <input> tag: Unele browsere permit manipularea prin acest vector, care poate fi folosit pentru a încorpora un script.
• <link> tag: Această etichetă poate conține un script, în locul utilizării normale a legăturii către foi de stil externe.
• <table> tag: În cazul în care atributul background se referă în mod normal la o imagine, acesta poate fi compromis pentru a se referi la scriptul incriminat.
• <div> tag: Această etichetă conține, de asemenea, o referință de fundal și poate fi utilizată în același mod ca și <table> pentru a face referire la un script.
• <object> tag: Scripturile de pe un site extern pot fi incluse folosind această etichetă.

Chiar dacă există și alți vectori pe care atacatorii XSS îi folosesc în eforturile lor de a fura informații și de a compromite site-urile web, acestea sunt unele dintre cele mai frecvent utilizate metode. Dezvoltatorii trebuie să adere la practici adecvate de evadare și igienizare pentru a se proteja împotriva acestor atacuri.

În funcție de atacator și de intenția sa malițioasă, atacurile XSS pot avea efecte diferite, inclusiv:

• deturnarea sesiunii unui utilizator, utilizarea acreditărilor pentru a accesa alte site-uri sau redirecționarea utilizatorului către site-uri web neintenționate,
• alterarea paginilor web sau inserarea de secțiuni într-o pagină web,
• executarea de scripturi pentru a extrage informații sensibile din cookie-uri sau baze de date,
• dacă victima are drepturi administrative, atacul s-ar putea extinde la partea serverului, provocând daune suplimentare sau extragând informații sensibile suplimentare.

Pasii cheie în testarea vulnerabilităților XSS pentru aplicațiile web critice includ:

• utilizarea unui instrument de scanare a codului pentru a detecta vulnerabilitățile care permit corecții ale codului în timpul procesului de dezvoltare,
• implementarea unei funcționalități de testare automată care va dezvălui vulnerabilitățile potențiale în mod complet și rapid.

Să spunem că exmple.com/profile conține un parametru nume. URL-ul pentru cerere ar arăta ca https://example.com/profile?user=Tammy. Aplicația web răspunde cu „Bună Tammy” în partea de sus a paginii pe baza acestei intrări.

Dacă parametrul utilizatorului nu este validat pentru a se asigura că acesta conține doar datele așteptate, un atacator ar putea face ca un utilizator să viziteze o versiune malițioasă a URL-ului care arată astfel:
https://example.com/profile?user<script>some_malicious_code</script>.
Când răspunsul este trimis către browser, acesta include acel script malițios care este apoi executat în browser, probabil fără ca utilizatorul să știe. Acesta este un exemplu de atac XSS reflectat. Codul malițios este imediat „reflectat” înapoi către utilizatorul care a făcut cererea.

• Educație și conștientizare: Asigurați-vă că toți dezvoltatorii, proiectanții de site-uri web și echipele de control al calității sunt conștienți de metodele pe care hackerii le folosesc pentru a exploata vulnerabilitățile și oferiți orientări și cele mai bune practici de codare. Aceasta include tehnici adecvate de evadare/codificare pentru mediul aplicației (JavaScript, HTML etc.).
• Sanitizați intrările: Fie că este vorba de pagini web interne sau de site-uri web publice, nu vă încredeți niciodată în validitatea datelor introduse de utilizator. Screenizați și validați orice câmp de date, mai ales dacă acestea vor fi incluse ca ieșire HTML.
• Scanați codul: Implementați un software care scanează codul pentru vulnerabilități, inclusiv cross-site scripting, pentru a vă asigura că sunt respectate cele mai bune practici și pentru a minimiza expunerea la XSS și alte vulnerabilități listate de OWASP.
• Politica de securitate a conținutului: Utilizați Content Security Policy (CSP) pentru a defini ceea ce poate face un site web și, prin aceasta, reduceți riscul unui atac XSS. Prin utilizarea CSP, XSS poate fi blocat în întregime (prin blocarea tuturor scripturilor în linie) sau poate fi redus la un risc mult mai scăzut.

OWASP oferă îndrumări suplimentare cu privire la modul de prevenire a vulnerabilității XSS cu o fișă de consultații cuprinzătoare.