Cross-Site XSS skriptiranje. Koristeći XSS ranjivosti do maksimuma. Uklanjanje vlastitog koda
I je sveobuhvatan udžbenik na skripti za križanje.
Prvi dio: Pregled
Što je XSS?
Prekomjerno skriptiranje ( engleski Križanje skriptiranje- Ovo je napad koji je usmjeren na provedbu koda koji omogućuje napadaču da izvedi zlonamjerni JavaScript u drugom korisničkom pregledniku.
Napadač ne napada svoju žrtvu izravno. Umjesto toga, koristi ranjivost web-lokacije koja posjećuje žrtvu i provodi zlonamjerni JavaScript kod. U pregledniku žrtve, zlonamjerni JavaScript prikazuje se kao legitiman dio web-lokacije, a sama web stranica djeluje kao izravni suučesnik napada.
Provedba zlonamjernog JavaScript koda
Jedini način da napadate lansiranje zlonamjernog JavaScripta u pregledniku žrtve je da ga predstavi s jednom od stranica koje se žrtva preuzima s web-mjesta. To je moguće ako web-lokacija korisnicima omogućuje unos podataka na njihovim stranicama, a napadač će moći umetnuti niz koji će se odrediti kao dio koda u pregledniku žrtve.
Primjer u nastavku prikazuje jednostavnu skriptu poslužitelja koja se koristi za prikaz zadnjeg komentara na web-lokaciji:
ispis " "
Ispis "Posljednji komentar:"
Ispis baze podataka.LatestComment
Ispis ""
Skripta pretpostavlja da se komentar sastoji samo od teksta. Međutim, od neposrednog prilagođeni ulazNapadač može napustiti ovaj komentar: "". Bilo koji korisnik koji je posjetio stranicu će sada dobiti sljedeći odgovor:
Posljednji komentar:
Kada korisnički preglednik učita stranicu, učinit će sve, uključujući i JavaScript kod sadržane unutar oznaka , To sugerira da je jednostavna prisutnost scenarija koju je proveo napadač je problem, bez obzira na to koji je određeni kôd skripte zapravo izvršen.
Drugi dio: XSS-napada
Sudionici napada XSS
Prije opisivanja kako detaljno opisati kako XSS napad radi, moramo identificirati subjekte XSS napada. Općenito, u napadu XSS-a postoje tri sudionika: web stranica, žrtva, I. provalnik.
- Web stranica Daje html stranicama za korisnike koji su ih zatražili. U našim primjerima nalazi se na http: // web stranice /.
- Baza podataka web-lokacije To je baza podataka koja pohranjuje neke podatke unesene od strane korisnika na stranice stranice.
- Žrtva - ovo je normalan korisnik Web stranica koja traži stranice s preglednikom.
- Napad - Ovo je napadač koji namjerava započeti napad za žrtvu kroz korištenje XSS ranjivosti na mjestu.
- Burglarski poslužitelj - Ovo je web poslužitelj pod kontrolom napadača s jedinom svrhom - krađe povjerljivih informacija o žrtvama. U našim primjerima nalazi se na http: // napadač /.
Primjer scenarijskog napada
Ova skripta će stvoriti HTTP zahtjev na drugi URL, koji će preusmjeriti korisnički preglednik na napadački poslužitelj. URL uključuje žrtve kolačiće kao parametar upita kada HTTP zahtjev dolazi na napadača poslužitelja, napadač može izdvojiti te kolačiće s zahtjeva. Nakon što je napadač primio kolačiće, može ih upotrijebiti da se daju žrtvovanju i započnite naknadni napad.
Od ove točke na HTML kodu prikazane će se nazvati zlonamjerni niz ili zlonamjerna skripta, Važno je shvatiti da je sam niz zlonamjeran samo ako se u konačnici obrađuje kao HTML kod u pregledniku žrtve, a to se može dogoditi samo ako je XSS ranjivost dostupan na web stranici.
Kako radi ovaj primjer
Shema u nastavku prikazuje primjer napada napadača:
- Napadač koristi jedan od oblika web-lokacije kako bi umetnuo zlonamjernog niza na bazu podataka web-lokacije.
- Žrtva postavlja stranicu s web-lokacije.
- Stranica uključuje zlonamjerni niz iz baze podataka kao odgovor i šalje ga žrtvi.
- Preglednik žrtve obavlja zlonamjerni scenarij u odgovoru, slanje žrtava na napadača poslužitelja.
Vrste XSS.
Svrha XSS napada uvijek je zbog zlonamjernog JavaScript skripta U pregledniku žrtve. Postoji nekoliko fundamentalno različitih načina za postizanje tog cilja. XSS napadi često su podijeljeni u tri vrste:
- Pohranjeni (trajni) XSSgdje zlonamjerni niz potječe iz baze podataka web-lokacije.
- Odražava (nestalna) XSSgdje je zlonamjerni niz generiran od zahtjeva žrtve.
- XSS DOM modeligdje se ranjivost javlja u kodu na strani klijenta, a ne na strani poslužitelja.
U prethodnom primjeru prikazan je pohranjeni XSS napad. Sada opisujemo još dvije vrste XSS-napada: odražava XSS i XSS-napada dom modela.
Odražava XSS.
U slučaju reflektiranog XSS napada, zlonamjerni niz je dio zahtjeva žrtve na web stranicu. Stranica prima i umeće ovaj zlonamjerni niz korisniku poslanom korisniku. Shema ispod ilustrira ovu skriptu:
- Žrtva prijevarno šalje zahtjev URL-a na web-lokaciju.
- Stranica uključuje zlonamjerni niz iz URL upita kao odgovor na žrtvu.
- Preglednik žrtve obavlja zlonamjerni scenarij sadržan u odgovoru, slanje žrtava na uljeznog poslužitelja.
Kako uspješno provesti reflektirani XSS napad?
Reflektirani XSS napad može izgledati bezopasno, jer zahtijeva od žrtve iz njegovog imena da pošalje zahtjev koji sadrži zlonamjerni niz. Budući da nitko ne može dobrovoljno napasti, čini se da ne postoji način stvarnog izvršenja napada.
Kako se ispostavilo, postoje barem dva uobičajena načina kako bi žrtvovanje početi odražavajući XSS napad na sebe:
- Ako je korisnik određena osobnost, napadač može poslati zlonamjernog URL-a žrtvi (na primjer, koristeći e-poštu ili glasnika), i prevariti da ga prisili da otvorite link za posjet web-lokaciji.
- Ako je cilj velika skupina korisnika, napadač može objaviti vezu na zlonamjerni URL (na primjer, na vlastitoj web-lokaciji ili u društvena mreža) I čekati posjetitelje koji će ići na link.
Obje ove metode su slične, a oboje mogu biti uspješniji koristeći usluge "skratiti" URL, prikrivaju zlonamjerni niz od korisnika koji bi ga mogli identificirati.
XSS u dom modelu
XSS u dom modelu je opcija kao pohranjeni i odražavajući XSS napad. U ovom XSS napada, zlonamjerni niz se ne obrađuje po pregledniku žrtve, sve dok se ne izvrši pravi JavaScript web stranice. Shema ispod ilustrira ovu skriptu za odražene XSS napade:
- Napadač stvara URL koji sadrži zlonamjerni niz i šalje ga žrtvi.
- Žrtva prijevarno šalje zahtjev URL-a na web-lokaciju.
- Stranica prima zahtjev, ali ne uključuje zlonamjernog niza kao odgovor.
- Preglednik žrtve obavlja legitiman scenarij koji se nalazi u odgovoru, što je rezultiralo zlonamjerna skripta će biti umetnuta u stranicu.
- Preglednik žrtve izvodi zlonamjernu skriptu umetnutu na stranicu, šaljući žrtve kolačiće na uljeznog poslužitelja.
Koja je razlika između XSS u dom modelu?
U prethodnim primjerima pohranjenih i reflektiranih XSS napada, poslužitelj umeće zlonamjerne skripte na stranicu, koja se zatim šalje kao odgovor na žrtvu. Kada je preglednika žrtve primio odgovor, pretpostavlja da je zlonamjerna skripta dio legitimnog sadržaja stranice i automatski ga obavlja tijekom učitavanja stranice, kao i bilo koji drugi scenarij.
U primjeru XSS napada u dom modelu, zlonamjerna skripta nije umetnuta kao dio stranice; Jedina skripta koja se automatski izvršava tijekom opterećenja stranice je legitiman dio stranice. Problem je u tome što ovaj legitiman scenarij izravno koristi korisnički unos kako bi dodao HTML na stranicu. Budući da je zlonamjerni niz umetnut u stranicu pomoću InnerhTML, analizira se kao HTML, kao rezultat toga će se izvršiti štetna skripta.
Ova razlika je mala, ali vrlo važna:
- U tradicionalnim XSS-u, zlonamjerni JavaScript se izvodi kada se stranica učita, kao dio HTML poslanog poslužitelja.
- U slučaju XSS u dom modelu, zlonamjerni JavaScript se obavlja nakon učitavanja stranice, kao rezultat, ova stranica s legitimnim JavaScriptom naziva se nesiguran način korisničkog unosa (koji sadrži zlonamjerni niz).
Kako XSS radi u dom modelu?
U prethodnom primjeru nema potrebe za JavaScriptom; Poslužitelj može generirati sve HTML samo po sebi. Ako kod na strani poslužitelja ne sadrži ranjivosti, web-lokacija ne bi bila podložna XSS ranjivosti.
Međutim, budući da web aplikacije postaju sve naprednije, povećana količina HTML stranica generira se pomoću JavaScripta na strani klijenta, a ne na poslužitelju. U bilo kojem trenutku, sadržaj se mora promijeniti bez ažuriranja cijele stranice, moguće je koristiti JavaScript. Konkretno, to je slučaj kada se stranica ažurira nakon upita Ajaxa.
To znači da XSS ranjivosti mogu biti prisutni ne samo u dijelu poslužitelja koda vaše web-lokacije, već i na strani JavaScript koda klijenta vaše web-lokacije. Prema tome, čak i uz potpuno siguran kod na strani poslužitelja, kôd klijenta još uvijek može biti siguran za unos korisničkih podataka prilikom ažuriranja dom nakon preuzimanja stranice. Ako se to dogodi, kod klijenta će omogućiti da XSS napad nije pogreška koda s poslužitelja.
XSS na temelju DOM modela može biti nevidljiv na poslužitelju
Postoji poseban slučaj XSS napada u dom model u kojem zlonamjerni niz nikada ne šalje poslužitelju web-mjesta: to se događa kada se zlonamjerni niz nalazi u fragmentu identifikatora URL-a (nešto nakon simbola #). Preglednici ne šalju ovaj dio URL-a na poslužitelju, tako da web-lokacija nema pristup pomoću koda na strani poslužitelja. Međutim, kod klijenta ima pristup i stoga je moguće provesti napad XSS nesigurnim obradom.
Ovaj slučaj nije ograničen na identifikator fragmenta. Tu je i drugi korisnički ulaz koji je nevidljiv poslužitelju, na primjer, nove HTML5 funkcije, kao što su Localstorage i IndexddB.
Dio tri:
XSS prevencija
Metode prevencije XSS-a
Sjetite se da je XSS napad vrste implementacije koda: korisnik koji je unio korisnik pogrešno se tumači kao zlonamjerni programski kod. Kako bi se spriječila ova vrsta injekcije koda, potrebna je sigurna obrada unosa. Za web developer, postoje dva fundamentalno različite metode Izvršite sigurnosnu obradu unosa:
- Kodiranje - Ovo je način koji vam omogućuje da unesete podatke od strane korisnika samo kao podatke i ne dopušta obradu preglednika kao kod.
- Validacija - Ova metoda filtrira korisnički unos tako da preglednika ga interpretira kao kod bez zlonamjernih naredbi.
Iako su to fundamentalno različite metode sprečavanja XSS-a, imaju nekoliko općih osobina koje su važne za razumijevanje kada koristite bilo koji od njih:
Kontekst sigurna unosna obrada mora biti različito ovisno o tome gdje se korisnički unos koristi na stranici. Dolazni / odlazni siguran ulazni obrada može se izvršiti ili kada vaša web-lokacija primi ulazne podatke (dolazni promet) ili izravno prije nego što web-lokacija umeće prilagođeni unos u sadržaj stranice (odlazni). Obrada unosa klijenta / poslužitelja može se izvesti na strani klijenta ili na strani poslužitelja, svaka je opcija potrebna u različitim okolnostima.
Prije objašnjenja u detaljima kako radi kodiranje i validacija, opisujemo svaku od tih stavki.
Obrada korisničkog unosa u kontekstima
Postoji mnogo konteksta na web-stranici gdje se može primijeniti prilagođeni ulaz. Posebna pravila moraju biti ispunjena za svaku od njih tako da korisnički unos ne može "izbiti" iz svog konteksta i ne može se tumačiti kao zlonamjerni kod. U nastavku su najčešći konteksti:
Što je značenje konteksta?
U svim opisanim kontekstima, ranjivost koja vodi do XSS može se pojaviti ako korisnik unese korisnik je umetnut u prvi kodiranje ili validaciju. Napadač može uvesti zlonamjerni kod jednostavno umetanje zatvaranja separatora za ovaj kontekst i nakon zlonamjernog koda.
Na primjer, ako u nekom trenutku web-lokacija uključuje unos podataka od strane korisnika izravno u HTML atribut, napadač će moći provesti zlonamjernu skriptu pokretanjem unosa navodnika kao što je prikazano u nastavku:
To se može spriječiti, jednostavno uklanjanje svih citata u korisničkom unosu, a sve bi bilo u redu, ali samo u tom kontekstu. Ako je ulaz umetnut u drugi kontekst, separator za zatvaranje će se razlikovati i injekcija će postati moguća. Iz tog razloga, sigurna obrada unosa treba uvijek biti prilagođena kontekstu u kojem će se umetnuti korisnički unos.
Obrada dolaznog / odlaznog korisničkog unosa
Instinktivno, može se činiti da se XSS može spriječiti kodiranjem ili potvrđivanjem cijelog korisničkog unosa, čim je naša stranica primi. Dakle, sve zlonamjerne linije će se već neutralizirati kad god su uključene u stranicu, a skripte HTML generacije ne moraju se brinuti o sigurnoj obradi korisničkog unosa.
Problem je u tome što je prethodno opisano od strane korisnika unesenog od strane korisnika može se umetnuti u nekoliko konteksta na stranici. I ne jednostavan način Odredite kada korisnik unos dođe u kontekst - kao što će se na kraju umetnuti, a isti korisnički ulaz često mora biti umetnut u različite kontekste. Oslanjajući se na obradu dolaznog ulaza kako bi se spriječilo XSS, stvaramo vrlo krhko rješenje koje će biti podložno pogreškama. (Zastarjeli "čarobni citati" PHP su primjer takvog rješenja.)
Umjesto toga, obrada odlaznog ulaza mora biti vaša glavna zaštitna linija od XSS-a, jer može uzeti u obzir specifičan kontekst, koji korisnik uneseni korisnik će biti umetnut. U određenoj mjeri, dolaznu validaciju može se koristiti za dodavanje sekundarnog sloja zaštite, ali ovo kasnije.
Gdje je moguće izvršiti siguran korisnički ulazni obrada
U većini modernih web aplikacija, korisnički unos se obrađuje i na strani poslužitelja i na strani klijenta. Kako bi se zaštitili od svih vrsta XSS, sigurna obrada unosa mora se izvršiti u kodu na strani poslužitelja i kôd klijenta.
- Kako bi se zaštitili od tradicionalne XSS, sigurna obrada unosa mora se izvesti u kodu na strani poslužitelja. To se radi s jezikom koji podržava poslužitelj.
- Kako bi se zaštitili od XSS napada u dom modelu, gdje poslužitelj nikada ne prima zlonamjerni niz (na primjer, prethodno opisani napad putem fragmenta identifikatora), sigurna obrada unosa mora se izvesti u kodu na strani klijenta. To se radi s JavaScriptom.
Sada, kada smo objasnili zašto je kontekst važan, zašto je razlika između dolazne i odlazne obrade ulaznih unosa važna, i zašto se sigurno prerada unosa mora izvršiti na obje strane, i na strani klijenta i na strani poslužitelja, možemo nastaviti objasniti Kako se zapravo izvode dvije vrste sigurnosti unosa (kodiranje i validacija).
Kodiranje
Kodiranje je izlaz iz situacije kada je potrebno da preglednika unosa korisnika interpretira samo kao podatke, a ne kod. Najpopularnija vrsta kodiranja u web razvoju je maskiranje HTML koji pretvara znakove kao što je < i > u < i > odnosno.
Sljedeći Pseudokod je primjer kako korisnik unesen od strane korisnika (Custom ENTER) može se kodirati pomoću HTML maskiranja, a zatim umetnuti na stranicu pomoću scenarija poslužitelja:
ispis " "
Ispis "Posljednji komentar:"
Ispis ENCODOHTML (usersput)
Ispis ""
Ako korisnik uđe na sljedeću liniju Rezultirajući HTML će izgledati ovako:
Posljednji komentar:
Budući da su svi simboli s posebnim vrijednostima bili prikriveni, preglednik neće rastavljati bilo koji dio korisničkog unosa kao HTML.
Kodirajući kod na strani klijenta i poslužitelju
Prilikom kodiranja koda kodiranja od klijenta, uvijek se koristi JavaScript jezik koji ima ugrađene funkcije koje kodiraju podatke za različite kontekste.
Prilikom kodiranja u vašem kodu na strani poslužitelja se oslanjate na značajke dostupne na vašem jeziku ili okviru. zbog veliki broj Jezici i dostupni okviri tutorial Neće pokriti detalje kodiranja u bilo kojem određenom poslužitelju ili okviru. Ipak, funkcije kodiranja JavaScript koji se koriste na strani klijenta također se koriste prilikom pisanja koda na strani poslužitelja.
Kodiranje na strani klijenta
Kada kodira prilagođeni ulaz klijenta pomoću JavaScripta, postoji nekoliko ugrađenih metoda i svojstava koja automatski kodiraju sve podatke u kontekstualno ovisan stil:
Posljednji kontekst već spomenut (vrijednosti u JavaScriptu) nije uključena u ovaj popis, jer JavaScript ne pruža ugrađeni način kodiranja podataka, koji će biti omogućen u JavaScript izvorni kod.
Ograničenja kodiranja
Čak i kada se kodiraju moguće koristiti zlonamjerne linije u nekim kontekstima. Svijetli primjer toga je kada se korisnički unos koristi za pružanje URL-a, na primjer, u donjem primjeru:
dokument.Querylector ("a"). Href \u003d userputput
Iako je navedena vrijednost u imovine HREF elementa automatski kodira tako da ne postane više od vrijednosti atributa, to samo po sebi ne ometa napadača umetnite URL koji počinje s "JavaScript:". Kada kliknete na vezu, bez obzira na izgradnju, ugrađeni JavaScript unutar URL-a će se izvršiti.
Kodiranje također nije učinkovito rješenje kada želite korisnike koristiti dio HTML kodova na stranici. Primjer je stranica profila korisnika, gdje korisnik može koristiti korisnički HTML. Ako je ovaj uobičajeni HTML kodiran, stranica profila će se moći sastojati samo od jednostavnog teksta.
U takvim situacijama kodiranje treba nadopuniti validacijom s kojom ćemo upoznati dalje.
Validacija
Validacija je čin filtriranja korisničkog unosa tako da se svi zlonamjerni dijelovi uklanjaju bez potrebe za uklanjanjem cijelog koda u njemu. Jedan od najčešće korištenih vrsta provjere u web razvoju omogućuje vam korištenje nekih HTML elemenata (na primjer, i ), Ali zabranjen drugi (na primjer,