Cross Site Scripting

Cross Site Scripting – hoe je website wordt gekaapt

XSS, SQL Injection, XMLrpc – als er een WordPress beveiligingsupdate wordt uitgebracht, bevatten de updatemeldingen meestal cryptische acroniemen. Zelfs als het duidelijk is dat deze updates noodzakelijk zijn en de plus aan veiligheid erg prettig is, is het belangrijk om te begrijpen wat er achter deze beveiligingslekken zit. Want alleen als je begrijpt welke gaten de updates dichten, kun je ook een weloverwogen beslissing nemen. Daarom kijken we vandaag naar Cross Site Scripting, oftewel XSS, verreweg de meest voorkomende complexe aanval op WordPress websites.

Hackersaanvallen zijn te vergelijken met een inbraak. Brute force aanvallen lijken meer op de koevoetmethode. Criminelen verzetten zich tegen het gereedschap totdat de deur of het raam openbreekt. Aanvallen op XSS-kwetsbaarheden daarentegen zijn geraffineerd: de criminelen weten precies waar ze moeten beginnen en krijgen heel gericht toegang tot een website.

Bij cross site scripting worden opzettelijk gaten in de beveiliging van websites uitgebuit. Kwaadaardige scripts worden geïnjecteerd in een betrouwbare context (jouw website!). Net als een verstekeling op een schip gebruikt deze kwaadaardige code jouw website als voertuig om zijn eigen doelen na te streven.

In het ergste geval wordt zo vertrouwelijke informatie verkregen, of zelfs toegang tot de computer van de gedupeerde gebruiker. Dergelijke aanvallen zijn niet bepaald zeldzaam: Een goede helft van de kwetsbaarheden in plugins die de beveiligingsleverancier Wordfence in 2015 en 2016 vond, waren cross-site scripting kwetsbaarheden. Een XSS-aanval vormt vaak de "basis" voor verdere aanvallen, zoals spam, phishing of DDoS-aanvallen. Daarom laat ik je vandaag zien hoe Cross Site Scripting precies werkt, welke soorten aanvallen er zijn en hoe gevaarlijk de aanvallen zijn.

Cross Site Scripting heeft een basisprincipe

Cross site scripting werkt volgens het basisprincipe van het uitbuiten van een lek en het injecteren van kwaadaardige code in je website. Het is altijd een gevaar wanneer een webapplicatie ingevoerde gegevens doorstuurt naar de webbrowser zonder te controleren op mogelijke scriptcode. Een goed voorbeeld van zo'n webapplicatie is een support chat.

De kwaadaardige scripts kunnen de server bereiken via de webapplicatie zelf. 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 meta-beschrijvingen van afbeeldingen in WooCommerce 2.6.2. Door een fout was het mogelijk om van buitenaf HTML-code in de meta-beschrijvingen van afbeeldingen te smokkelen. Elk apparaat waarop de getroffen afbeelding nu nader werd bekeken (bijv. door op de afbeelding te klikken) liep het risico te worden aangevallen. Zo konden onder andere de computers waarop deze afbeelding werd bekeken met een virus worden besmet.

"*" geeft verplichte velden aan

Ik wil me abonneren op de nieuwsbrief om op de hoogte te blijven van nieuwe blogartikelen, ebooks, features en nieuws over WordPress. Ik kan mijn toestemming te allen tijde intrekken. Bekijk ons Privacybeleid.
Dit veld dient ter validatie en mag niet worden gewijzigd.

Populaire truc voor Cross Site Scripting: gemanipuleerde formulieren

XSS kan het ook mogelijk maken om onschadelijke formulieren te vervangen door gemanipuleerde formulieren. Deze formulieren verzamelen dan de gegevens van de slachtoffers (op jouw website!). Overigens kan zelfs SSL-versleuteling hiertegen niet beschermen. HTTPS betekent "alleen" dat de verbinding tussen server en client versleuteld is. Maar als het formulier zelf gemanipuleerd is, is zelfs een versleutelde verbinding nutteloos.

Net als bij andere soorten aanvallen is het doel in de meeste gevallen monetariseren. Concreet betekent dit dat ofwel gegevens worden gestolen en later verkocht, ofwel geïnfecteerde websites worden geïntegreerd in een zogenaamd botnet, dat vervolgens wordt verhuurd.

3 soorten XSS

Cross site scripting aanvallen kunnen grofweg in drie typen worden verdeeld:

  • Reflected Cross Site Scripting
  • Persistant Cross Site Scripting
  • DOM-gebaseerde of lokale cross site scripting

Grofweg werken XSS-aanvallen als volgt: Kwaadaardige code wordt geïnjecteerd waar invoer van de client wordt verwacht (bijvoorbeeld tijdens een pagina-interne zoekopdracht). Als onderdeel van het antwoord van de server wordt de kwaadaardige code vervolgens uitgevoerd op de client, d.w.z. in de browser. En precies daar wordt de betreffende schade aangericht, bijvoorbeeld het stelen van gegevens.

Reflected Cross Site Scripting

Sommige invoer, zoals zoekopdrachten, wordt door de server weergegeven. Dit betekent dat bijvoorbeeld na het invoeren van "test" in het zoekveld, de website weergeeft "Je hebt gezocht naar test". De ingevoerde tekst wordt zo onderdeel van het antwoord van de server.

Dit is precies waar handig misbruik van wordt gemaakt: Als in plaats van een zoekterm een kwaadaardig script naar de webserver wordt gestuurd, kan de website zo gemanipuleerd worden dat hij het uiteindelijk uitvoert. Dit type aanval wordt ook wel non-persistent genoemd. Dit betekent dat de kwaadaardige code slechts tijdelijk in de betreffende website wordt geïnjecteerd, maar niet wordt opgeslagen.

In juli 2017 werd zo'n kwetsbaarheid gevonden in de WP Statistics plugin (en al op dezelfde dag verholpen!). Een invoerwaarde op de pagina 'wps_visitors_page' werd ongecontroleerd doorgestuurd, wat leidde tot een kwetsbaarheid via gereflecteerde XSS. Als een admin eerder op een overeenkomstig gemanipuleerde link had geklikt, kon een website dus gehackt worden.

Cross Site Scripting Reflected XSS
Zo kan een reflected cross site scripting aanval eruit zien.

Het werkt als volgt: links met gemanipuleerde parameters worden verspreid onder potentiële slachtoffers. Zonder het te weten stuurt het slachtoffer een "gemanipuleerd" verzoek naar de server door op de link te klikken, en de kwaadaardige code wordt uitgevoerd samen met het antwoord van de server. Omdat de code – in tegenstelling tot persistente XSS – nergens wordt opgeslagen, moet hij massaal worden verspreid onder potentiële slachtoffers. Dit kan bijvoorbeeld gebeuren via e-mails of sociale netwerken.

Persistent Cross Site Scripting

Bij persistente XSS worden de kwaadaardige scripts op de webserver opgeslagen en telkens geleverd als ze door een client worden aangeroepen. Voorbestemd hiervoor zijn webapplicaties die gebruikersgegevens op de server opslaan en die vervolgens zonder controle of codering uitvoeren (inclusief forums). Dit type scripting kan vooral gevaarlijk zijn voor drukbezochte blogs en forums, omdat de malware zich hier snel kan verspreiden vanwege het grote aantal gebruikers.

Deze afbeelding toont een mogelijke volgorde van een persistente cross-site scripting aanval.
Volgorde van een persistente cross site scripting aanval. Bron: Blog SAP

Voorbeeld: In een forum worden geplaatste bijdragen opgeslagen in een database. Het is niet ongebruikelijk dat deze ongecontroleerd en ongecodeerd worden opgeslagen. Deze mogelijkheid wordt gemakkelijk uitgebuit en maakt het mogelijk een kwaadaardig script toe te voegen aan een volkomen normaal forumbericht (op een eenvoudige manier met behulp van een commentaar). De gebruikers ontvangen de betreffende link naar het bericht per e-mail of komen bij toeval bij het betreffende bericht terecht en voeren het script uit als ze het bericht openen. Nu zouden getroffen clients bijvoorbeeld kunnen worden "bespioneerd" of toegevoegd aan een botnet voor verdere aanvallen.

DOM-gebaseerde ofwel lokale Cross Site Scripting

In tegenstelling tot persistente en gereflecteerde XSS, werkt DOM (Document Object Model) gebaseerde cross site scripting door het uitvoeren van scripts aan de kant van de client. Dit betekent dat de server zich niet bewust is van zo'n aanval en serverzijdige beveiligingsmaatregelen ook niet helpen.

Een bekend voorbeeld van zo'n lek was het geval van het genericon package. Het genericon pakket is een pictogrammenset die door veel plugins wordt gebruikt. Het was mogelijk om kwaadaardige code te injecteren via een HTML bestand in deze iconset.

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

De voorwaarde voor een DOM-gebaseerde XSS aanval is echter dat gebruikers op een gemanipuleerde URL klikken. Door deze URL op te roepen kan de kwaadaardige code worden uitgevoerd via een lek in een client-side script. Onder andere het feit dat er eerst op een link moet worden geklikt, maakt DOM-gebaseerde XSS een wat moeilijker en dus minder waarschijnlijk type aanval.

Cross Site Scripting Local XSS
Voorbeeld van een lokale cross site scripting aanval.

Voorbeeld: De gemanipuleerde URL wordt aangeklikt en stuurt een verzoek naar de webapplicatie. De webapplicatie antwoordt door de scriptcode (die fout is maar niet gemanipuleerd) door te geven aan de browser om de uitvoering van het script te starten. De gemanipuleerde parameters uit de URL worden nu in de browser van de cliënt geïnterpreteerd als onderdeel van het script en uitgevoerd. De website die in de browser wordt weergegeven is dus veranderd en gebruikers zien nu ongemerkt de gemanipuleerde website.

Maatregelen tegen Cross Site Scripting

De beste maatregelen tegen cross-site scripting aanvallen zijn eenvoudig uit te voeren. Je kunt het beste vertrouwen op regelmatige updates, firewalls en whitelists. Ten tweede kan ook de uitvoer van de server worden beveiligd.

Regelmatige updates

De kwetsbaarheden waardoor de kwaadaardige code wordt geïnfiltreerd zitten ofwel in de WordPress kern, in plugins of in thema's. Dit is precies waarom regelmatige updates van al deze onderdelen zo belangrijk zijn. Want de kwetsbaarheden die tot nu toe gevonden zijn, worden in deze updates verholpen.

Het is ook zinvol om regelmatig de details van updates te lezen om een gevoel te krijgen voor welke beveiligingslekken regelmatig via de updates worden gedicht. Voor de onderhouds- en beveiligingsupdates van de WordPress core is deze informatie bijvoorbeeld gedocumenteerd in de WordPress blog.

Firewalls en whitelists tegen eenvoudige XSS-aanvallen

Een andere eenvoudige beschermingsmaatregel tegen XSS-aanvallen zijn zogenaamde web application firewalls, of WAF. Deze firewalls vormen het hart van grote beveiligingsplug-ins en worden gevoed met de nieuwste kwetsbaarheden door het betreffende onderzoeksteam van de fabrikant. Een WAF is over het algemeen een procedure die webapplicaties beschermt tegen aanvallen via het Hypertext Transfer Protocol (HTTP).

Maar zelfs deze beschermingsmechanismen hebben hun beperkingen. Bij sommige XSS aanvallen vindt de aanval plaats via de database. Daarom is het controleren van gebruikersinvoer op kwaadaardige code een van de centrale beveiligingsmechanismen in de strijd tegen XSS aanvallen. De inhoud van commentaren wordt bijvoorbeeld gescand op verdachte tekenreeksen en zo nodig uitgesorteerd.

De gegevensuitvoer moet ook worden beveiligd

Regelmäßige Updates schließen vorhandene XSS Sicherheitslücken und Firewalls sowie Whitelists versuchen Schadcode auszufiltern, bevor dieser den Webserver erreicht und die Website infizieren kann. Doch sollte auch die Datenausgabe entsprechend gesichert werden. Die meisten Programmier- und Skriptsprachen, wie PHP, Perl oder JavaScript, besitzen hierfür bereits vordefinierte Funktionen zur Zeichenersetzung bzw. -maskierung. Diese sorgen dafür, dass „problematische“ HTML Metazeichen wie <> und & durch harmlose Zeichenreferenzen ersetzt werden. So wird verhindert, dass der Schadcode aktiv werden kann. Auch sollte der Code mithilfe von sogenannten sanitization libraries bereinigt werden. Hierfür wird ein Plugin auf dem Server installiert und zusätzlicher Code in den Quellcode deiner Website eingebunden. Der folgende Codeschnipsel sorgt dann zum Beispiel dafür, dass <class> zu den erlaubten Attributen hinzugefügt wird:

var sanitizer = new HtmlSanitizer();
sanitizer.AllowedAttributes.Add("class");
var sanitized = sanitizer.Sanitize(html);

Om dit te implementeren zijn programmeervaardigheden nodig. Deze gegevensuitvoerbeveiliging is eenvoudig uit te voeren voor iemand met deze kennis.

Een gezonde dosis scepsis: hoe gebruikers zichzelf beschermen

Maar niet alleen de website zelf, ook de clients (d.w.z. je webbrowser) worden getroffen door XSS aanvallen. Veel XSS aanvallen kunnen worden voorkomen door een kritische en zorgvuldige omgang met "vreemde" links. Er is onder andere de mogelijkheid om NoScript addons te gebruiken. Deze voorkomen de uitvoering van scripts, d.w.z. de schadelijke regels code die onder andere gegevens stelen.

Wie het zekere voor het onzekere wil nemen, kan client-side cross-site scripting ook afwenden door simpelweg de JavaScript-ondersteuning in de browser uit te schakelen. Want als deze zogenaamde actieve scripting wordt uitgeschakeld, hebben bepaalde soorten XSS-aanvallen geen kans meer, omdat de schadelijke toepassingen niet eens worden opgestart. De meeste moderne websites "functioneren" dan echter niet meer goed - of in het ergste geval helemaal niet meer. Het is dus noodzakelijk om de aspecten veiligheid en bruikbaarheid tegen elkaar af te wegen. Als je geïnteresseerd bent in deze optie, kun je die vinden in de instellingen van je browser.

Conclusie

XSS kwetsbaarheden behoren tot de meest voorkomende toegangspoorten voor kwaadaardige code. En een overeenkomstige aanval vormt vaak de basis voor verdere aanvallen, zoals spam, phishing of DDoS-aanvallen. Je website wordt gekaapt en misbruikt voor andere doeleinden. XSS is dus niet zonder gevaar, en daarom is een passende bescherming belangrijk.

Vooral gereflecteerde en persistente XSS komen veel voor, omdat lokale cross-site scripting complexer en moeilijker te implementeren is. Websites die gebruikersgegevens doorsturen naar de webbrowser zonder te controleren op mogelijke kwaadaardige code lopen bijzonder veel risico. Het vinden van dergelijke veiligheidslekken is echter niet zo eenvoudig. In principe is dit precies de taak van beveiligingsproviders als sucuri en anderen, die hun beveiligingsmaatregelen voortdurend ontwikkelen.

Maar natuurlijk is er ook een manier voor gewone WordPress om zich tegen deze aanvallen te beschermen. Updates van alle WordPress componenten zijn onder andere een eenvoudige maar zeer effectieve maatregel. Als je je plugins en thema's up-to-date houdt en een WAF gebruikt, heb je al een grote stap in de goede richting gezet. Als je ook whitelists gebruikt voor inkomende en uitgaande code, heb je je website al uitstekend beveiligd. Vooral de laatste twee maatregelen zijn echter niet eenvoudig uit te voeren zonder programmeerkennis.

Vergeleken met de tamelijk primitieve brute force aanvallen zijn de meer complexe XSS aanvallen helaas nog relatief vaak succesvol. Er zijn echter veel minder van deze zogenaamde complexe aanvallen dan er brute force aanvallen zijn op WordPress websites. Toch moet je het deze aanvallen zo moeilijk mogelijk maken. Een geslaagde hack kost niet alleen tijd en geld voor het verwijderen van de scripts, maar kan ook je positie in zoekmachines in gevaar brengen.

Vond je het artikel leuk?

Met jouw beoordeling help je ons om onze inhoud nog verder te verbeteren.

Laat een reactie achter

Je e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *.