XSS-aanvallen stellen aanvallers in staat om client-side scripts te injecteren in webpagina's die door andere gebruikers worden bekeken. De belangrijkste gevolgen van deze kwetsbaarheid zijn de mogelijkheid om acties uit te voeren in de context van de ingelogde gebruiker en het lezen van gegevens in de context van de ingelogde gebruiker.
Aanvalsscenario
De aanvaller lokaliseert de XSS-kwetsbaarheid op een website die door het slachtoffer wordt gebruikt, bijvoorbeeld de website van een bank.
Het slachtoffer is momenteel aangemeld op deze pagina
De aanvaller stuurt het slachtoffer een vervalste URL
Het slachtoffer klikt op de URL
Op het slachtoffer bank website, JavaScriptcode begint uit te voeren om de gegevens van de gebruiker te onderscheppen of namens hem een overdracht uit te voeren naar de rekening van de aanvaller
Het is de moeite waard om op te merken dat bewerkingen die worden uitgevoerd namens het slachtoffer onzichtbaar kunnen zijn voor het slachtoffer, omdat ze op de achtergrond kunnen plaatsvinden met behulp van de API van de bank, of de aanvaller kan ze later uitvoeren met de gegevens die nodig zijn voor authenticatie, tokens, cookies, enz.
XSS-types
1. Gereflecteerde XSS
Dit is er een waarbij HTML/JavaScript-code in een parameter (bijv. GET, POST of cookie) wordt weergegeven in het antwoord.
Een pagina met een tekstinvoer om iets te zoeken die de parameter zoeken=eten in het URL-einde wanneer de API wordt opgevraagd. Na het invoeren van een zin, als deze niet wordt gevonden, wordt een retourbericht geplaatst in HTML ex.
<div>Geen resultaat gevonden voor <b>foo</b></div>
We kunnen proberen de URL in te voeren zoeken=..
2.DOM XSS
Dit is wanneer de uitvoering ervan wordt ingeschakeld door het gebruik van gevaarlijke functies in JavaScript, zoals `eval` of `innerHtml`. Het "Live voorbeeld" hieronder toont een DOM XSS-aanval gebaseerd op de `innerHtml` functie.
3. Opgeslagen XSS
Hier wordt de kwaadaardige code aan de serverkant geschreven. We kunnen bijvoorbeeld een commentaar met kwaadaardige code naar een blogpost sturen die naar de server wordt geüpload. De taak is om bijvoorbeeld te wachten op de moderatie van de beheerder en dan zijn sessiegegevens te stelen, enz.
Injectiemethoden
1. In de tag-inhoud
`onerror=waarschuwing('XSS')`in
<img src onerror="alert('XSS')" />
2. In de inhoud van het attribuut
`" onmouseover=waarschuwing('XSS')` in
<div class="" onmouseover="alert('XSS')""></div>
In de inhoud van het attribuut zonder de aanhalingstekens
x onclick=waarschuwing('XSS')in
<div class="x" onclick="alert('XSS')"></div>
In de hrefef eigenschap
javascript:waarschuwing('XSS') in
<a href="javascript:alert('XSS')"></a>
In de string binnen JavaScript code
";Waarschuwing('XSS')// in
In het kenmerk met de JavaScript-gebeurtenis
');waarschuwing('XSS')// waarbij ' een enkel aanhalingsteken is, in
Gegevenscodering met behulp van ingebouwde functies die in veel programmeertalen.
Sjabloonsystemen met automatische codering gebruiken. De meeste populaire frameworks die dergelijke systemen gebruiken, beschermen ons tegen XSS-injectie (Django, Templates, Vue, React enz.).
Gebruik geen functies zoals eval of Functie met niet-vertrouwde gebruikersgegevens.
Gebruik geen functies en eigenschappen die HTML-code rechtstreeks aan de DOM-boomelementen toewijzen, bijv, innerHTML, outerHTML, insertAdjacentHTML, ocument.write. In plaats daarvan kun je functies gebruiken die tekst direct aan deze elementen toewijzen, zoals tekstinhoud of innerText.
Wees voorzichtig wanneer je de gebruiker doorverwijst naar een URL die onder zijn controle staat. Risico van injectie locatie = 'javascript('XSS')'.
HTML filteren met bibliotheken zoals DOMPurify.
Wees voorzichtig met uploaden .html of .svg bestanden. Je kunt een apart domein aanmaken van waaruit de geüploade bestanden worden geserveerd.
Gebruik de Inhoud-beveiligingsbeleid mechanisme.
Kijk eens naar de anti-XSS filters die in de meeste populaire browsers zijn ingebouwd.
Als je dit artikel interessant vindt, volg Lukasz dan op Github: https://github.com/twistezo