Cross-Site-Scripting - hoe hackers je site kapen

Tobias Schüring Laatst bijgewerkt op 15.01.2020
6 Min.
Cross-Site Scripting_XSS

XSS, SQL injectie, XMLrpc - wanneer een WordPress beveiligingsupdate wordt vrijgegeven, bevatten de updatemeldingen meestal cryptische acroniemen. Ook al is het duidelijk dat deze updates noodzakelijk zijn en is de plus in beveiliging zeer verheugend, toch is het belangrijk te begrijpen wat er achter deze beveiligingslekken schuilgaat. Want alleen als u begrijpt welke gaten de updates dichten, kunt u ook een weloverwogen beslissing nemen. Daarom gaan we vandaag kijken naar cross-site scripting, of XSS, wat veruit de meest voorkomende complexe aanval is op WordPress pagina's.

Aanvallen van hackers kunnen worden vergeleken met inbrekers. Brute Force Aanvallen zijn meer vergelijkbaar met de koevoet methode. De crimineel verzet zich tegen het gereedschap totdat de deur of het raam openbreekt. Aanvallen op XSS-kwetsbaarheden, daarentegen, zijn gesofisticeerd: De inbreker weet precies waar hij moet beginnen en krijgt gericht toegang tot een pagina.

Bij cross-site scripting worden beveiligingslekken in websites opzettelijk uitgebuit. Hackers injecteren kwaadaardige scripts in een vertrouwde context (uw pagina's!). Net als een verstekeling op een schip, gebruikt deze kwaadaardige code uw site als een voertuig om zijn eigen doelen na te streven.

In het ergste geval krijgen aanvallers op die manier vertrouwelijke informatie of toegang tot de computer van de gedupeerde gebruiker. Zulke aanvallen zijn niet bepaald zeldzaam: Ruim de helft van de kwetsbaarheden die in 2015 en 2016 door de beveiligingsprovider Wordfence werden gevonden, waren cross-site scripting kwetsbaarheden in Plugins .. Vaak vormt een XSS-aanval dan de "basis" voor verdere aanvallen, zoals spam, phishing of DDoS-aanvallen. Daarom zal ik je vandaag laten zien hoe cross-site scripting precies werkt, welke soorten aanvallen er zijn en hoe gevaarlijk de aanvallen zijn.

Cross-site scripting werkt altijd op dezelfde manier: kwaadaardige code komt op uw site via een gat.

Cross-site scripting is een gevaar wanneer een webapplicatie ingevoerde gebruikersgegevens doorstuurt naar de webbrowser zonder te controleren of er scriptcode aanwezig is. Een goed voorbeeld van een dergelijke webtoepassing is een ondersteuningschat.

Via de webapplicatie zelf kunnen de kwaadaardige scripts de server bereiken. Van daaruit komt de kwaadaardige code vroeg of laat terecht op de getroffen clients. Een goed voorbeeld van zo'n XSS-kwetsbaarheid is de bug die in juli 2016 werd ontdekt in de image meta-infos in WooCommerce 2.6.2. Een bug maakte het voor aanvallers mogelijk om van buitenaf HTML-code in de metabeschrijving van afbeeldingen te injecteren. Elke klant die de afbeelding in kwestie nader zou hebben bekeken (bijvoorbeeld door op de afbeelding te klikken) zou het risico lopen te worden aangevallen. Een hacker kan bijvoorbeeld de computers van uw klanten met een virus hebben besmet.

Populaire truc voor cross-site scripting: gemanipuleerde formulieren

XSS kan hackers ook in staat stellen onschadelijke formulieren te vervangen door gemanipuleerde formulieren. Deze formulieren verzamelen dan de gegevens van de slachtoffers (de bezoekers van uw site!). DTrouwens, zelfs SSL-encryptie kan je hier niet tegen beschermen. HTTPS "alleen" betekent dat de verbinding tussen server en client versleuteld is. Maar als het formulier zelf is gemanipuleerd, is zelfs een gecodeerde verbinding nutteloos.

Net als bij andere soorten aanvallen is het doel van hackers meestal geld te verdienen aan hun machinaties. Concreet betekent dit dat aanvallers ofwel gegevens stelen die zij later verkopen, ofwel sites willen infecteren om deze op te nemen in een zogenaamd botnet dat vervolgens wordt verhuurd.

3 soorten XSS: gereflecteerde, persistente en lokale XSS

Cross-site scripting aanvallen kunnen grofweg in drie soorten worden onderverdeeld:

Grofweg werken XSS-aanvallen als volgt: Kwaadaardige code wordt geïnjecteerd op plaatsen waar gebruikersinvoer wordt verwacht (bv. bij een interne zoekopdracht op een pagina). Als onderdeel van het antwoord van de server wordt de kwaadaardige code vervolgens uitgevoerd op de client, d.w.z. in de browser van de gebruiker. En dit is precies waar de schade wordt aangericht, b.v. gebruikersgegevens worden gestolen.

Reflectieve cross-site scripting

Sommige input, zoals zoekopdrachten, wordt door de server gereflecteerd. Dit betekent dat, bijvoorbeeld, na het invoeren van "test" in het zoekvak, de pagina zal teruggeven "u hebt gezocht naar test". Dus wat de gebruiker invoert wordt deel van het antwoord van de server.

Dit is precies waar aanvallers handig gebruik van maken: Als een kwaadaardig script naar de webserver wordt gestuurd in plaats van een zoekterm, kan de pagina worden gemanipuleerd om het uiteindelijk uit te voeren. Dit type aanval is ook bekend als niet-persistent aangeduid als niet-persistent. De kwaadaardige code wordt dus slechts tijdelijk in de betreffende pagina geïnjecteerd, maar niet opgeslagen.

In juli werd een dergelijke kwetsbaarheid gevonden in Plugin WP Statistics (en op dezelfde dag verholpen!). Een invoerwaarde op de pagina 'wps_visitors_page' werd ongecontroleerd doorgestuurd, wat leidde tot een kwetsbaarheid via gereflecteerde XSS. Op deze manier kan een pagina gehackt worden als een admin eerder op een gemanipuleerde link had geklikt

Bijvoorbeeld, een gereflecteerde cross-site scripting aanval zou er zo uit kunnen zien.
Bijvoorbeeld, een gereflecteerde cross-site scripting aanval zou er zo uit kunnen zien.

Het werkt als volgtDe aanvaller verspreidt links met gemanipuleerde parameters onder zijn potentiële slachtoffers. Zonder het te weten stuurt de gebruiker een "gemanipuleerd" verzoek naar de server door op de link te klikken, en de kwaadaardige code wordt samen met het antwoord van de server uitgevoerd. Aangezien de code - in tegenstelling tot persistente XSS - nergens is opgeslagen, moet de hacker deze massaal verspreiden onder potentiële slachtoffers. Dit kan bijvoorbeeld gebeuren via mails of sociale netwerken.

aanhoudende cross-site scripting

Bij persistente XSS worden de kwaadaardige scripts op de webserver opgeslagen en afgeleverd telkens wanneer ze door een client worden aangeroepen. Voorbestemd hiervoor zijn webtoepassingen die gebruikersgegevens op de server opslaan en deze vervolgens zonder verificatie of codering uitvoeren (bijv. forums). Dit soort scripting kan vooral gevaarlijk zijn voor drukbezochte blogs en forums, omdat de malware zich hier snel kan verspreiden door het grote aantal gebruikers.

Deze grafiek toont een mogelijk verloop van een aanhoudende cross-site scripting aanval.
Stroom van een aanhoudende cross-site scripting aanval. Bron: Blog SAP

Voorbeeld: In een forum worden geposte bijdragen opgeslagen in een database. Het is niet ongewoon dat deze ongecontroleerd en onversleuteld worden opgeslagen. Aanvallers maken van deze gelegenheid gebruik en voegen een kwaadaardig script (bijv. met behulp van een commentaar) toe aan een normaal forumbericht. een normaal forumbericht met een kwaadaardig script (bijv. met behulp van een commentaar). Gebruikers ontvangen de link naar het bericht per e-mail of komen per toeval bij het overeenkomstige bericht terecht en voeren het script uit wanneer zij het bericht oproepen. Het voordeel voor de hacker is dat hij de getroffen klanten nu kan "bespioneren" of ze aan zijn botnet kan toevoegen voor verdere aanvallen.

DOM-gebaseerde of lokale cross-site scripting

In tegenstelling tot persistente en gereflecteerde XSS, werkt DOM (Document Object Model) gebaseerde cross-site scripting door het uitvoeren van client-side scripts. Dit betekent dat de server niet op de hoogte is van een dergelijke aanval en dat beveiligingsmaatregelen aan de serverzijde ook niet helpen.

Een bekend voorbeeld van zo'n kwetsbaarheid is het geval van het genericon pakket. Het genericon pakket is een iconenset die gebruikt wordt door vele Plugins, waaronder Jetpack. Het was mogelijk om kwaadaardige code te injecteren via een HTML-bestand in deze iconenset.

Na het invoeren van deze URL, verscheen er een javascript waarschuwing. Dit is het bewijs dat de ingevoerde javascript-code kan worden gebruikt om de pagina in kwestie te manipuleren.
Na het invoeren van deze URL, verscheen er een JavaScript waarschuwing. Dit is het bewijs dat ingevoerde JavaScript-code kan worden gebruikt om de pagina in kwestie te manipuleren. Bron: securityaffairs.co

Een voorwaarde voor een DOM-gebaseerde XSS-aanval is echter dat de gebruiker op een gemanipuleerde URL klikt. Door deze URL aan te roepen, kan de kwaadaardige code worden uitgevoerd via een gat in een client-side script. Onder andere het feit dat eerst op een link moet worden geklikt, maakt op DOM gebaseerde XSS een iets moeilijker en dus minder waarschijnlijk type aanval.

De grafiek toont een mogelijk verloop van een lokale cross-site scripting aanval.
Voorbeeld van een lokale cross-site scripting aanval. Bron: heise.de

Voorbeeld: De gebruiker klikt op de gemanipuleerde URL en stuurt een verzoek naar de webapplicatie. De webapplicatie reageert door de scriptcode (die onjuist is maar niet gemanipuleerd) aan de browser door te geven om de uitvoering van het script te starten. De gemanipuleerde parameters uit de URL worden nu geïnterpreteerd en uitgevoerd in de browser van de gebruiker als onderdeel van het script. De in de browser getoonde webpagina wordt dus gewijzigd en de gebruiker ziet nu - zonder het te merken - de gemanipuleerde pagina.

Conclusie: Vrij frequent en niet zonder gevaar, dus passende bescherming is belangrijk.

XSS-kwetsbaarheden behoren tot de meest voorkomende toegangspoorten voor kwaadaardige code. En vaak vormt een overeenkomstige aanval de basis voor verdere aanvallen, zoals spam, phishing of DDoS-aanvallen. Aanvallers kapen uw site en misbruiken die om hun eigen doelen te bereiken.

Reflected en persistent XSS komen bijzonder vaak voor, aangezien lokale cross-site scripting uitgebreider en moeilijker te implementeren is. Pagina's die gebruikersgegevens doorsturen naar de webbrowser zonder deze te controleren op mogelijke kwaadaardige code, lopen een bijzonder risico. Het vinden van dergelijke leemten is echter niet zo gemakkelijk. In principe is dit precies de taak van beveiligingsbedrijven zoals sucuri en Co, die hun beveiligingsmaatregelen voortdurend verder ontwikkelen.

Maar er is natuurlijk ook een manier voor normale WordPress gebruikers om zich tegen deze aanvallen te beschermen. Updates van alle WordPress -componenten zijn bijvoorbeeld een eenvoudige maar zeer doeltreffende maatregel. Hoe u als beheerder van een site, maar ook als internetgebruiker, cross-site scripting kunt voorkomen, leggen we uit in ons volgende artikel over dit onderwerp.

Heb je nog opmerkingen of vragen? Laat dan gewoon een reactie achter!

Als systeembeheerder waakt Tobias over onze infrastructuur en vindt hij alle mogelijke manieren om de prestaties van onze servers te optimaliseren. Door zijn onvermoeibare inzet is hij vaak 's nachts bij Slack te vinden.

Gerelateerde artikelen

Reacties op dit artikel

Laat een opmerking achter

Jouw e-mailadres zal niet worden gepubliceerd. Verplichte velden zijn met een * gemarkeerd.