Articles

DOM baserad Cross Site Scripting

Posted on

den mindre kända XSS-tekniken

  • DOM står för Document Object Model
  • XSS står för cross-site scripting
  • huvudskillnaden mellan DOM-baserad XSS och andra XSS-sårbarheter är att nyttolasten är inbäddad på klientsidan snarare än serversidan
  • DOM-baserad XSS-sårbarheter måste därför förhindras på klientsidan

XSS-sårbarheter (Cross-site scripting) först blev känd genom CERT Advisory CA-2000-02 (skadliga HTML-taggar inbäddade i Klientwebbförfrågningar), även om dessa sårbarheter hade utnyttjats tidigare. Så XSS har redan funnits ett tag. Och som du förväntar dig har det redan funnits ett antal Labs – artiklar om ämnet, inklusive Cross Site Scripting-den underskattade faran och Cross-Site – Scripting och Preventing Script Injection-en kort Guide. Denna artikel fokuserar dock till stor del på DOM-baserad cross-site scripting, en term som först myntades 2005 av Amit Klein. Han publicerade definitionen av DOM-baserad cross-site scripting (XSS) och avgränsade den från andra cross-site scripting sårbarheter. För att förstå DOM-baserad cross-site scripting behöver du först en djupare förståelse för DOM.

vad är DOM?

dokumentobjektmodellen är ett programgränssnitt som definierar dokumentens struktur. Det som är relevant för våra ändamål är att DOM tillhandahåller objektorienterad representation av HTML-dokument, specifikt:

  • hur ett HTML-element representeras som ett objekt
  • vad attributen för ett HTML-element är
  • vilka metoder kan användas för att komma åt ett HTML-element
  • vad händelserna i ett HTML-element är

detta innebär att DOM anger hur HTML-element kan hittas, läggas till, ändras eller raderas i webbläsaren. Det betyder att DOM erbjuder en möjlighet att manipulera HTML-sidor. Idag används JavaScript vanligtvis för denna typ av manipulation.

det bör noteras att varje webbläsare implementerar DOM-standarden annorlunda. Detta kan påverka om en specifik DOM XSS-attack fungerar i en viss webbläsare.

vad är DOM baserat XSS?

en DOM-baserad XSS-sårbarhet uppstår när DOM används för att generera dynamiskt innehåll som innehåller användarinmatning som kan bearbetas utan kontroll. Denna typ av attack utförs med JavaScript i användarens webbläsare. Här anges de platser som (skadlig) användarinmatning leder till DOM som källa. De platser där (skadlig) användarinmatning kan utföras i DOM betecknas som diskbänk.

ett exempel på en enkel serveröverskridande skriptsårbarhet:

<!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årbarheten kan till exempel utlösas med följande GET-begäran:

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

vi kan se att detta exempel krävs med decodeURIComponent – metoden. Detta beror på att moderna webbläsare kodar specialtecken i webbadressen och attacken skulle inte fungera utan att dessa specialtecken avkodas. Innehållet i variabeln sourceläggs till i div-elementet med innerHTML. Detta är det problematiska elementet i koden, eftersom dess tilldelning till innerHTML gör att värdet som ingår i det tolkas som HTML. Om värdet innehåller JavaScript körs detta också.

det bör påpekas att detta inte förändrar serverns svar. Den skadliga modifieringen uppstår endast när JavaScript-koden körs på klientsidan, som DOM därefter ändrar.

de mest kända källorna och sänkorna listas nedan. Det bör noteras att detta inte alls är en uttömmande lista.

källor

  • dokument.URL
  • dokument.referens
  • plats
  • plats.href
  • plats.sök
  • plats.hash
  • plats.sökväg

sänkor

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

förhindra DOM-baserad XSS

eftersom det finns fall där nyttolasten aldrig faktiskt gör det till servern, är det inte en uppgift för serversidan att förhindra denna sårbarhet. Exemplet ovan är ett sådant fall. Anledningen är att innehåll som visas efter ett # – tecken inte skickas av webbläsaren till servern.

den första och viktigaste rekommendationen är att undvika att använda användarstyrda data för dynamisk generering av innehåll när det är möjligt. Om detta är helt oundvikligt är det bästa sättet att förhindra DOM-baserad XSS att använda säkra utmatningsmetoder (sink) som förhindrar körning av skadlig inbäddad kod. I kodavsnittet ovan är det enda sättet att göra koden säker att ersätta .innerHTML med .textContent. Detta beror på att – till skillnad från innerHtml – HTML-element i metoden textContent inte körs.

DOM-baserade XSS-förebyggande fuskblad från OWASP har många användbara tips för att utveckla säkra dynamiska webbplatser med JavaScript. Där hittar du också beskrivningar av kontextberoende kodning, vilket krävs när det är omöjligt att byta till en säker utmatningsmetod.

skillnader från andra XSS-sårbarheter

den viktigaste skillnaden är var attacken är inbäddad i koden. Till skillnad från andra serveröverskridande skriptsårbarheter är koden inte inbäddad på serversidan utan snarare på klientsidan. Detta innebär att nyttolasten inte kan hittas i svarskoden. DOM – baserade XSS-sårbarheter kan därför endast upptäckas vid körning eller genom att kontrollera webbplatsens DOM.

i de flesta fall är det inte lätt att hitta DOM-baserade XSS-sårbarheter. Ett användbart tillvägagångssätt som använder den statiska kodanalysmetoden beskrivs i artikeln Burp based-xss.

om författaren

Andrea Hauser

Andrea Hauser tog examen med en Bachelor of Science FHO i informationsteknologi vid University of Applied Sciences Rapperswil. Hon fokuserar sitt offensiva arbete på webbapplikationssäkerhetstestning och förverkligandet av sociala ingenjörskampanjer. Hennes forskningsfokus är att skapa och analysera deepfakes. (ORCID 0000-0002-5161-8658)

länkar

  • 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/

Lämna ett svar

Din e-postadress kommer inte publiceras.