Cross-site scripting (XSS)

Cross-site scripting (XSS) is een aanvalstechniek waarbij iemand met kwade bedoelingen scriptcode laat uitvoeren in de browser van bezoekers van een website. De browser ziet die code als onderdeel van de site en voert hem gewoon uit.

Dat is gevaarlijk, want een script kan doen wat de bezoeker zelf op de site kan doen. Het kan een ingelogde sessie overnemen, formulieren stiekem aanpassen, gegevens van het scherm doorsturen of de bezoeker doorverwijzen naar een nepsite. De bezoeker merkt er vaak niets van. Ook jij als eigenaar ziet de aanval zelden direct, omdat hij zich afspeelt in de browser van de bezoeker.

XSS is al jaren een van de bekendste webkwetsbaarheden. Het ontstaat niet door een fout van de bezoeker, maar door de manier waarop een website met invoer omgaat.

Een XSS-lek ontstaat wanneer een website invoer van gebruikers, of gegevens uit een link, op een pagina terugtoont zonder die goed te controleren. Denk aan een zoekveld dat je zoekterm herhaalt, of een reactie onder een artikel. Bevat die invoer HTML of scriptcode en wordt die ongefilterd getoond, dan krijgt iedereen die de pagina bekijkt die code te zien en uit te voeren.

Er zijn twee hoofdvarianten:

• Reflected XSS: de kwaadaardige code zit in een link. De aanval werkt pas als iemand op die link klikt. Aanvallers verspreiden zulke links via e-mail, berichten of advertenties.
• Stored XSS: de code wordt blijvend opgeslagen, bijvoorbeeld in een reactie, een profielveld of de database. Elke bezoeker die de pagina opent, wordt geraakt. Deze variant is meestal het gevaarlijkst, omdat het slachtoffer niets hoeft te doen.

Verwant maar anders is SQL-injectie. Die aanval richt zich op de database in plaats van op de bezoeker.

De belangrijkste verdediging zit in de software zelf. Een goed gebouwde website behandelt invoer als tekst en zet die om voordat hij op een pagina verschijnt, zodat de browser tekst toont en geen code uitvoert. Die bescherming zit vaak al ingebouwd in een modern CMS of framework. Plugins, thema's en code van derden zijn vaker de bron van een lek, daarom zijn updates en een kritische keuze van extensies belangrijk.

Daarnaast kunnen er extra lagen bij komen:

• een Content-Security-Policy, die vastlegt van welke bronnen een browser scripts mag laden. Meer over die en andere headers lees je bij security headers.
• een web application firewall, die bekende XSS-patronen in het verkeer herkent en blokkeert.

Let op de grenzen. Een extra laag vervangt het veilig programmeren niet. Een strenge Content-Security-Policy kan een site ook laten breken, en een firewall herkent alleen patronen die hij kent. Vraag je ontwikkelaar of hoster welke maatregelen zij nemen en hoe ze lekken opsporen.