Articles

DOM baseret Cross Site Scripting

Posted on
  • DOM står for Document Object Model
  • HSS står for cross-site scripting
  • hovedforskellen mellem DOM-baserede HSS-sårbarheder er, at nyttelasten er indlejret på klientsiden snarere end på serversiden
  • DOM-baserede HSS-sårbarheder skal derfor forhindres på klientsiden

Cross-site scripting sårbarheder først blev kendt gennem cert Advisory CA-2000-02 (ondsindede HTML-Tags indlejret i Klienthjemmeanmodninger), selvom disse sårbarheder var blevet udnyttet før. SF har allerede eksisteret i et stykke tid. Og som du ville forvente, har der allerede været en række Labs artikler om emnet, herunder Cross Site Scripting – den undervurderede fare og Cross-Site-Scripting og forebyggelse af Scriptinjektion – en kort vejledning. Denne artikel fokuserer dog stort set på DOM-baseret scripting på tværs af steder, et udtryk, der først blev opfundet i 2005 af Amit Klein. Han offentliggjorde definitionen af DOM baseret Cross-site scripting og afgrænsede det fra andre cross-site scripting sårbarheder. For at forstå DOM-baseret scripting på tværs af steder har du først brug for en dybere forståelse af DOM.

hvad er DOM?

Dokumentobjektmodellen er en programgrænseflade, der definerer strukturen af dokumenter. Det, der er relevant for vores formål, er, at DOM sørger for den objektorienterede repræsentation af HTML-dokumenter, specifikt:

  • hvordan et HTML-element er repræsenteret som et objekt
  • hvad attributterne for et HTML-element er
  • hvilke metoder kan bruges til at få adgang til et HTML-element
  • hvad begivenhederne for et HTML-element er

dette betyder, at DOM specificerer, hvordan HTML-elementer kan findes, tilføjes, ændres eller slettes i HTML-elementet

det skal bemærkes, at hver bro.ser implementerer DOM-standarden forskelligt. Dette kan påvirke, om et specifikt DOM-angreb fungerer i en bestemt bro.ser.

hvad er DOM-baseret?

en dom-baseret sårbarhed opstår, når DOM bruges til at generere dynamisk indhold, der indeholder brugerinput, der kan behandles uden kontrol. Denne form for angreb udføres med JavaScript i brugerens bro.ser. Her betegnes de placeringer, som (ondsindet) brugerinput bringer ind i DOM, som kilde. De steder, hvor (ondsindet) brugerinput kan udføres i DOM, betegnes som sink.

et eksempel på en simpel cross-site scripting sårbarhed:

<!DOCTYPE html><html> <body> <script> var source = "Hello " + decodeURIComponent(location.hash.split("#")); //Source var divElement = document.createElement("div"); divElement.innerHTML = source; //Sink document.body.appendChild(divElement); </script> </body></html>

sårbarheden kan for eksempel udløses med følgende GET-anmodning:

GET www.vulnerable-website.example#<img src="test" onerror="alert('XSS')">

vi kan se, at dette eksempel kræves ved hjælp af decodeURIComponent – metoden. Dette skyldes, at moderne bro.Serere koder specialtegn i URL ‘ en, og angrebet ikke fungerer, uden at disse specialtegn afkodes. Indholdet af variablen sourceføjes til div-elementet ved hjælp af innerHTML. Dette er det problematiske element i koden, fordi dets tildeling til innerHTML får den værdi, der følger med den, til at blive fortolket som HTML. Hvis værdien indeholder JavaScript, udføres dette også.

det skal påpeges, at dette ikke ændrer serverresponset. Den ondsindede ændring opstår kun, når JavaScript-koden udføres på klientsiden, som DOM efterfølgende ændrer.

de mest kendte kilder og dræn er angivet nedenfor. Det skal bemærkes, at dette på ingen måde er en udtømmende liste.

kilder

  • dokument.URL
  • dokument.henvisning
  • beliggenhed
  • beliggenhed.href
  • beliggenhed.søg
  • beliggenhed.hash
  • beliggenhed.stinavn

dræn

  • eval
  • setTimeout
  • setInterval
  • dokument.skriv
  • element.innerHTML

forebyggelse af DOM-baseret HSS

da der er tilfælde, hvor nyttelasten faktisk aldrig kommer til serveren, er det ikke en opgave for serversiden at forhindre denne sårbarhed. Eksemplet ovenfor er et sådant tilfælde. Årsagen er, at indhold, der vises efter et # – tegn, ikke sendes af bro.sereren til serveren.

den første og vigtigste anbefaling er at undgå at bruge brugerstyrede data til dynamisk generering af indhold, når det er muligt. Hvis dette er helt uundgåeligt, er den bedste måde at forhindre DOM-baseret på at bruge sikre outputmetoder (sink), der forhindrer udførelsen af ondsindet indlejret kode. I kodestykket ovenfor er den eneste måde at gøre koden sikker på at erstatte .innerHTML med .textContent. Dette skyldes – i modsætning til innerHtml – HTML-elementer i textContent – metoden udføres ikke.

den DOM baseret på forebyggelse Cheat Sheet har masser af nyttige tips til at udvikle sikre dynamiske hjemmesider med JavaScript. Der finder du også beskrivelser af kontekstafhængig kodning, som kræves, når det er umuligt at skifte til en sikker outputmetode.

forskelle fra andre sårbarheder

den vigtigste forskel er, hvor angrebet er indlejret i koden. I modsætning til andre sårbarheder på tværs af site scripting er koden ikke indlejret på serversiden, men snarere på klientsiden. Dette betyder, at nyttelasten ikke kan findes i svarkoden. Dom-baserede sårbarheder kan derfor kun opdages ved kørsel eller ved at kontrollere hjemmesidens DOM.

i de fleste tilfælde er det ikke let at finde Dom-baserede sårbarheder. En nyttig tilgang, der bruger den statiske kodeanalysemetode, er beskrevet i artiklen Burp-baseret.

om forfatteren

Andrea Hauser

Andrea Hauser er uddannet med en Bachelor of Science FHO i informationsteknologi ved University of Applied Sciences. Hun fokuserer sit offensive arbejde på sikkerhedstest af internetapplikationer og realiseringen af sociale ingeniørkampagner. Hendes forskningsfokus er at skabe og analysere deepfakes. (ORCID 0000-0002-5161-8658)

Links

  • http://www.webappsec.org/projects/articles/071105.html
  • https://support.portswigger.net/customer/portal/articles/2325926-using-burp-scanner-to-test-for-dom
  • https://www.cert.org/historical/advisories/CA-2000-02.cfm
  • https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet
  • https://www.w3.org/DOM/

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.