Articles

DOM gebaseerd Cross Site Scripting

Posted on

De minder bekende XSS-Techniek

  • DOM staat voor Document Object Model
  • XSS staat voor cross-site scripting
  • Het grootste verschil tussen een DOM-based XSS en andere XSS kwetsbaarheden is dat de belading is ingesloten op de client, niet de kant van de server
  • DOM-based XSS kwetsbaarheden hebben daarom vermeden te worden op de client

Cross-site scripting (XSS) kwetsbaarheden eerste werd bekend door de CERT Advisory CA-2000-02 (kwaadaardige HTML-Tags ingebed in Client Web Requests), hoewel deze kwetsbaarheden eerder waren uitgebuit. XSS bestaat dus al een tijdje. En zoals je zou verwachten, zijn er al een aantal Labs artikelen over het onderwerp, met inbegrip van Cross Site Scripting – het onderschatte gevaar en Cross-Site-Scripting en het voorkomen van Script injectie-een korte gids. Echter, dit artikel richt zich grotendeels op DOM gebaseerde cross-site scripting, een term voor het eerst bedacht in 2005 door Amit Klein. Hij publiceerde de definitie van DOM gebaseerde cross-site scripting (XSS) en omlijnde het van andere cross-site scripting kwetsbaarheden. Om dom gebaseerde cross-site scripting te begrijpen, heb je eerst een dieper begrip van DOM nodig.

Wat is DOM?

het Document Object Model is een programma-interface die de structuur van documenten definieert. Wat relevant is voor onze doeleinden is dat DOM voorziet in de objectgeoriënteerde representatie van HTML-documenten, in het bijzonder:

  • Hoe een HTML-element wordt weergegeven als een object
  • Wat de kenmerken van een HTML-element
  • Welke methoden kunnen worden gebruikt om toegang te krijgen tot een HTML-element
  • Wat de gebeurtenissen van een HTML-element

Dit betekent dat het DOM bepaalt hoe HTML-elementen kunnen worden gevonden, toegevoegd, gewijzigd of verwijderd in de browser. Dat betekent dat DOM een mogelijkheid biedt om HTML-pagina ‘ s te manipuleren. Deze dagen, JavaScript wordt meestal gebruikt voor dit soort manipulatie.

opgemerkt moet worden dat elke browser de DOM-standaard anders implementeert. Dit kan van invloed zijn of een specifieke Dom XSS-aanval werkt in een bepaalde browser.

Wat is DOM – gebaseerde XSS?

een op DOM gebaseerde XSS-kwetsbaarheid ontstaat wanneer de DOM wordt gebruikt om dynamische inhoud met gebruikersinvoer te genereren die zonder controle kan worden verwerkt. Dit soort aanval wordt uitgevoerd met JavaScript in de browser van de gebruiker. Hier de locaties die (kwaadaardige) user input brengen in de DOM zijn aangewezen als bron. De locaties waar (kwaadaardige) user input kan worden uitgevoerd in de DOM worden aangeduid als sink.

een voorbeeld van een eenvoudige cross-site scripting kwetsbaarheid:

<!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>

de kwetsbaarheid kan, bijvoorbeeld, worden geactiveerd met de volgende GET request:

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

We kunnen zien dat dit voorbeeld vereist is met behulp van de decodeURIComponent methode. Dit komt omdat moderne browsers coderen speciale tekens in de URL en de aanval zou niet functioneren zonder deze speciale tekens worden gedecodeerd. De inhoud van de variabele source wordt toegevoegd aan het div-element met innerHTML. Dit is het problematische element in de code, omdat de toewijzing aan innerHTML ervoor zorgt dat de waarde die erin zit wordt geïnterpreteerd als HTML. Als de waarde JavaScript bevat, wordt dit ook uitgevoerd.

er dient op gewezen te worden dat dit het antwoord van de server niet verandert. De kwaadaardige wijziging ontstaat alleen wanneer de JavaScript-code wordt uitgevoerd aan de kant van de klant, die de DOM vervolgens verandert.

de bekendste bronnen en putten worden hieronder vermeld. Er zij op gewezen dat dit geenszins een uitputtende lijst is.

bronnen

  • document.URL
  • document.referrer
  • locatie
  • locatie.href
  • locatie.zoek
  • locatie.hash
  • locatie.padnaam

Sinks

  • eval
  • setTimeout
  • setInterval
  • document.element
  • schrijven.innerHTML

voorkomen van op DOM gebaseerde XSS

omdat er gevallen zijn waarin de lading nooit daadwerkelijk de server bereikt, is het voorkomen van deze kwetsbaarheid geen taak voor de server. Het voorbeeld hierboven is zo ‘ n geval. De reden is dat de inhoud die na een # – teken verschijnt, niet door de browser naar de server wordt verzonden.

de eerste en belangrijkste aanbeveling is om, waar mogelijk, het gebruik van door de gebruiker gecontroleerde gegevens voor het dynamisch genereren van inhoud te vermijden. Als dit volledig onvermijdelijk is, is de beste manier om op DOM gebaseerde XSS te voorkomen het gebruik van secure output methods (sink) die het uitvoeren van kwaadwillige ingebedde code voorkomen. In het codefragment hierboven is de enige manier om de code veilig te maken door .innerHTML te vervangen door .textContent. Dit komt omdat – in tegenstelling tot innerHtml – HTML-elementen in de textContent methode niet worden uitgevoerd.

de DOM gebaseerde XSS preventie spiekbrief van OWASP heeft tal van nuttige tips voor het ontwikkelen van veilige dynamische websites met JavaScript. Daar vindt u ook beschrijvingen van context-afhankelijke codering, die nodig is wanneer het onmogelijk is om over te schakelen naar een veilige output methode.

verschillen met andere XSS kwetsbaarheden

het belangrijkste verschil is waar de aanval is ingebed in de code. In tegenstelling tot andere cross-site scripting kwetsbaarheden, de code is niet ingebed aan de server kant, maar eerder aan de client kant. Dit betekent dat de payload niet kan worden gevonden in de response code. DOM gebaseerde XSS kwetsbaarheden kunnen daarom alleen worden gedetecteerd tijdens runtime of door het controleren van de website DOM.

in de meeste gevallen is het niet eenvoudig om op DOM gebaseerde XSS-kwetsbaarheden te vinden. Een handige aanpak die gebruik maakt van de statische code analyse benadering wordt beschreven in het artikel Burp based-xss.

over de auteur

Andrea Hauser

Andrea Hauser studeerde af met een Bachelor of Science FHO in informatietechnologie aan de University of Applied Sciences Rapperswil. Ze richt haar offensieve werk op het testen van de beveiliging van webapplicaties en de realisatie van social engineering campagnes. Haar onderzoeksfocus is het creëren en analyseren van deepfakes. (ORCID 0000-0002-5161-8658)

koppelingen

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

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.