XSS-aanvallen: hoe bescherm je jezelf, je klanten en je bedrijf.

Tobias Schüring Bijgewerkt op 23.01.2020
5 Min.
Op deze manier kunnen website-exploitanten en gebruikers zich beschermen tegen cross-site scripting-aanvallen.
Laatst bijgewerkt op 23.01.2020

XSS-aanvallen zijn bijzonder sluw. En vooral populair bij hackers. We laten zien hoe u zich kunt beschermen tegen het kapen van uw site - als websitebeheerder en als gebruiker.

1599 WordPress - de beveiligingsverstrekkerPlugins Wordfence heeft meer dan 14 maanden analyses en de meest voorkomende zwakte van allemaal waren de zogenaamde XSS-kwetsbaarheden. Bijna 47 procent van de gevonden hiaten had te maken met cross-site scripting - kortweg XSS. Reden genoeg om eens goed te kijken naar het type aanval waarbij hackers uw site infiltreren met kwaadaardige code en deze virtueel kapen. De aanvallers gebruiken uw blog, uw winkel of uw bedrijfswebsite als een voertuig voor hun illegale activiteiten.

Deze grafiek laat zien dat XSS wordfence de meest voorkomende kwetsbaarheid in Plugins de XSS is.
XSS is luidruchtig wordfence de meest voorkomende kwetsbaarheid in Plugins XSS.

XSS-kwetsbaarheden worden altijd gevaarlijk als gebruikersinvoer ongecontroleerd aan de webserver wordt doorgegeven, bijvoorbeeld in contactformulieren of commentaarvelden. Eenmaal succesvol kunnen hackers gegevens stelen, uw site integreren in een botnet of de computers van uw bezoekers besmetten. Gelukkig zijn er enkele zeer eenvoudige beschermingsmaatregelen tegen XSS-aanvallen.

XSS is even relevant voor bezoekers als voor beheerders van de site

Het is belangrijk om te begrijpen dat de kwetsbaarheden van XSS op pagina'WordPress s even relevant zijn voor de beheerders van de pagina's als voor de bezoekers. Exploitanten van sites worden uitgebuit om de lage doelen van hackers te bereiken en bezoekers van sites zijn vaak het slachtoffer, bijvoorbeeld door het stelen van gegevens of het verspreiden van kwaadaardige code.

In principe beginnen XSS-aanvallen waarbij gebruikers gegevens naar de webserver van de site-exploitant sturen. Code wordt geïnfiltreerd op deze neuralgische punten, die - als de gebruikersinvoer niet kritisch wordt gecontroleerd, bijvoorbeeld door een firewall - de site kunnen besmetten. De verschillende soorten XSS-aanvallen worden beschreven in onze achtergrondartikel over het onderwerp.

Belangrijkste: Regelmatig WordPress -Updates

De kwetsbaarheden die hackers gebruiken om de kwaadaardige code te introduceren bevinden zich in de WordPress kern, in Plugins of in Themes. Dit is precies de reden waarom regelmatige bijstelling van al deze componenten zijn ook zo belangrijk. Want in deze updates worden de zwakke punten die tot nu toe zijn gevonden, verholpen.

Het is ook zinvol om regelmatig de update details van de respectievelijke fabrikanten te lezen om een gevoel te krijgen voor de veiligheidslekken die regelmatig worden gedicht door de updates. Voor het onderhoud en de beveiligingsupdates van de WordPress -Core is deze informatie bijvoorbeeld gedocumenteerd in de WordPress -Blog. Het beste voorbeeld is de laatste beveiligingsupdate, WordPress 4.7.5.

Firewalls en whitelists tegen eenvoudige XSS-aanvallen

Een andere eenvoudige beschermingsmaatregel tegen XSS-aanvallen zijn de zogenaamde Webapplicatie firewallsof WAF. Deze firewalls vormen het hart van grote veiligheidPlugins en worden door het respectievelijke onderzoeksteam van de fabrikant gevoed met de nieuwste kwetsbaarheden. A WAF is over het algemeen een procedure die webapplicaties van aanvallen via de Hypertekst overdracht Protocol (HTTP) beschermt.

Maar zelfs deze beschermingsmechanismen hebben hun grenzen. 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. Bijvoorbeeld, de inhoud van commentaren op verdachte tekenreeksen gescand en zo nodig gesorteerd.

De data-uitvoer moet ook worden beveiligd

Regelmatige updates sluiten bestaande XSS-beveiligingsgaten en firewalls en whitelists proberen kwaadaardige code te filteren voordat deze de webserver bereikt en de site kan besmetten. De data-uitvoer moet echter ook dienovereenkomstig worden beveiligd. De meeste programmeer- en scripttalen, zoals PHP, Perl of JavaScript, hebben al voorgedefinieerde functies voor het vervangen van tekens of het maskeren. Deze zorgen ervoor dat "problematische" HTML meta-karakters (bijv. <, en >&) worden vervangen door onschadelijke karakterverwijzingen. Dit voorkomt dat de kwaadaardige code actief wordt. De code moet ook worden beschermd met behulp van zogenaamde saneringsbibliotheken moet worden aangepast. Dit gebeurt door het installeren van een Plugin code op de server en het integreren van extra code in de broncode van uw pagina. De volgende code snippet zal dan bijvoorbeeld aan de toegestane attributen worden toegevoegd:

Zo kan de configuratiecode die nodig is om een codereiniging uit te voeren er uitzien.
Zo kan de code die nodig is om een codereiniging uit te voeren er uitzien.

Om dit uit te voeren is programmeerkennis nodig. Een ontwikkelaar of CTO kan bijvoorbeeld eenvoudig deze data-uitvoerbeveiliging implementeren.

Een gezonde mate van scepsis: hoe gebruikers zichzelf beschermen

Maar niet alleen de beheerders van de site, ook de bezoekers van de site worden getroffen door XSS-aanvallen. Veel XSS-aanvallen kunnen al worden voorkomen door een kritische en zorgvuldige behandeling in verband met "vreemde" verbindingen. Gebruikers hebben bijvoorbeeld de mogelijkheid, NoScript-additieven om te gebruiken. Deze voorkomen de uitvoering van scripts, d.w.z. de kwaadaardige coderegels die bijvoorbeeld gegevens stelen.

Als u op veilig wilt zijn, kunt u ook de client-side cross-site scripting voorkomen door eenvoudigweg de JavaScript-ondersteuning in uw browser uit te schakelen. Want is dit zogenaamde actieve scripting is gedeactiveerd, bepaalde soorten XSS-aanvallen maken geen kans meer omdat de kwaadaardige toepassingen niet eens gestart worden. De meeste moderne websites "werken" dan echter niet meer goed - of in het ergste geval helemaal niet meer. Het is dus noodzakelijk om hier een afweging te maken tussen veiligheids- en bruikbaarheidsaspecten.

Zo deactiveert u JavaScript met één klik in de instellingen van de Chrome-browser.
Zo deactiveert u JavaScript met één klik in de instellingen van de Chrome-browser.

Conclusie: XSS-aanvallen zijn soms zeer complex, maar de bescherming is soms vrij eenvoudig.

XSS vormt een gevaar voor u als websitebeheerder, maar ook voor uw bezoekers en klanten. Steeds weer worden er zwakke punten in Plugins of Themes bekend. Bijvoorbeeld met de Plugin WP Statistiekenmet meer dan 400.000 actieve installaties, of met WooCommerce en jetpackmet elk meer dan drie miljoen actieve installaties.

Maar als je de jouwe Plugins en Themes up-to-date houdt en een WAF gebruikt, heb je al een grote stap in de goede richting gezet. Als u ook whitelists gebruikt voor inkomende en uitgaande code, hebt u uw site al perfect beveiligd. Met name de laatste twee maatregelen kunnen echter niet gemakkelijk en zonder programmeervaardigheden worden uitgevoerd.

Vergeleken met de nogal primitieve Brute Force Aanvallen de meer complexe XSS-aanvallen zijn helaas nog steeds relatief vaak succesvol. Er zijn echter beduidend minder van deze zogenaamde complexe aanvallen dan er zijn Brute Force Aanvallen op WordPress -Pagina's geeft. Toch moet je het zo moeilijk mogelijk maken voor aanvallers. Een succesvolle hack kost niet alleen tijd en geld om de scripts te verwijderen, maar kan ook uw positie in zoekmachines in gevaar brengen.

Misschien heb je al ervaring met XSS-aanvallen? Wat doe je om jezelf tegen hen te beschermen?

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 te Slack vinden.

Gerelateerde artikelen

Commentaar op dit artikel

Schrijf een opmerking

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