XSS: Focus weg van de echte problemen?
Ga naar een willekeurige site over hoe je veilige websites maakt en XSS krijgt weldra een boel aandacht. XSS is tegenwoordig het AJAX van de websites-beveiliging. En dat terwijl het uiteindelijk een van de minder schadelijke vormen van webhacken is. En ook nog eens vrij simpel te voorkomen.
De enige vorm van XSS die ik als daadwerkelijk schadelijk zou aanwijzen is het stelen van informatie, zoals cookies en anonieme statistieken van het surfgedrag. Voor de rest is het voornamelijk irritant.
Wat was XSS?
XSS staat voor cross-site scripting. Bij XSS wordt er geprobeerd externe code, zoals HTML en client-side scripts, in websites te injecteren. Eigenlijk is dit al een hele oude vorm van misbruik die bestaat sinds het moment dat Netscape voor het eerst JavaScript introduceerde.
Beveilig de koektrommel
Je wil natuurlijk niet dat mensen je cookies stelen. Gezien ze daarmee misschien wel de admininterface in zouden kunnen komen. Gelukkig kun je, zoals je de koektrommel op een hoge plank zou zetten, ook de cookies verstoppen voor javascript code. Dit gaat door een HttpOnly aanwijzing mee te geven aan de Set-Cookie header. Er zijn webscripting talen die hier geen standaard interface voor bieden, maar je kan natuurlijk altijd je eigen headers bakken. HttpOnly zorgt er voor dat cookies alleen mee worden gestuurd over http requests en dus niet te bereiken zijn via de al om bekende “document.cookie”.
Het probleem is echter dat niet alle browsers nog zo slim zijn om dit te ondersteunen. Toch is er al heel wat support voor. Internet Explorer kan dit bijvoorbeeld aan sinds SP1, Firefox zal dit doen vanaf Gran Paradiso (versie 3) die in oktober zal verschijnen en Opera vanaf versie 9.5. En ja, daar moet ik dan toegeven dat dit dus een van de dingen die momenteel alleen door Microsoft worden ondersteund. Voor firefox gebruikers is er gelukkig ook nog een extentie.
Het is jammer dat dit nog niet volledige support heeft, want het zou het grootste probleem van XSS volledig wegvagen.
Slimme cookies
Maar dat betekent niet dat je er zelf niets aan kan doen. Als je slim omgaat met je cookies zorg je namelijk dat deze in je database gekoppeld zijn aan een IP en het liefst ook een timestamp. Zo kun je altijd controleren of het koekje wel van de oorspronkelijke eigenaar komt en of het wel geldig is.
Hoe gaat het verder met XSS
Dat je de echte problemen van XSS kan uitschakelen is natuurlijk geen vrijkaart. Al was het maar om het feit dat je bezoekers het niet zullen waarderen als jij allemaal dubieuze popups op je site vertoont. Daarom moet je natuurlijk zorgen voor de nodige entities in de externe informatie die je laat zien. Maar het is ook belangrijk dat de extra beveiligingslaag voor je cookies er ligt, je kan in de webwereld niet te veel risico’s nemen.
Voorbeelden
1. Eigen cookies
Een Set-Cookie header dient te beginnen met de standaard manier binnen HTTP om een variabele door te geven, variabele=waarde, en dan wel urlgeëncodeerd. Daarna komen alle extra parameters, in HTTP zijn deze gescheiden doormiddel van een puntkomma. De parameters waar je rekening mee moet houden zijn Expires, Path, Domain, Secure en, natuurlijk, HttpOnly. De Expires parameter krijgt als waarde de datum in het formaat “Wdy, DD-Mon-YY HH:MM:SS” en dan wel in GMT-tijd. Path en Domain spreken voor zich. Secure geeft aan of de cookies alleen bij HTTPS of altijd moeten worden verzonden, in het geval dat je enkel bij SSL-verbindingen de cookies wil sturen moet je deze er bij zetten. Het zelfde geldt voor HttpOnly, als je deze er bij zet zullen cookies enkel geleverd worden als ze via een HTTP-request worden verstuurd.
Set-Cookie: var=waarde%20van%20var; Expires=Wed, 30-05-2007 22:14:12; Path=/cookiejar/; Domain=cookiejar.codelabs.nl; HttpOnly
2. Veilige cookies
Een veilig cookie is eigenlijk gewoon een random hash. Deze kun je dan in je database opzoeken, waar je de data hebt opgeslagen. In de database zet je dan ook de datum waarop de cookie vervalt en het ip-adres. Zo kun je altijd controleren of degene die het verstuurd ook daadwerkelijk de rechtmatige eigenaar is.