Cookies en Veiligheid – deel 2

Nu we in de vorige post (deel 1) hebben geleerd wat cookies zijn en hoe ze te werk gaan kunnen we eindelijk wat dieper op de gevaren en mogelijke oplossingen ingaan.

De gevaren van Cookies:

Nu we in de vorige post hebben geleerd wat cookies zijn en hoe ze te werk gaan kunnen we eindelijk wat dieper op de gevaren en mogelijke oplossingen ingaan.

Session Hijacking:

Sessie Hijacking is het ongeautoriseerd overnemen van een sessie. Op het moment dat de gebruiker inlogt op een webpagina wordt er een cookie weggeschreven die de server laat zien dat de gebruiker succesvol geautoriseerd is. Bij elke volgende pagina die bezocht wordt zal de webserver naar deze cookie kijken en weten dat dit de geautoriseerde gebruiker is. Hierdoor zal ze webpagina de beveiligde content laten zien. De authentication cookie wordt meestal weggeschreven in het tijdelijke geheugen van de browser. Als er echter gekozen wordt voor “onthoud mij” dan zal de cookie permanent worden weggeschreven op de HD van de gebruiker. De persistent cookie heeft waarschijnlijk een Max-Age flag van 2 weken maar dan kan ook anders zijn.

Deze cookie bevat nu alles wat nodig is om aan de webserver van de webpagina te laten zien dat deze gebruiker geautoriseerd is. Omdat deze cookie bestaat zal de gebruiker niet steeds opnieuw gevraagd worden om zich te autoriseren. Dat is mooie maar ook gevaarlijk. Als deze cookie gestolen wordt (van de computer of via een sniffer die op het netwerk cookies afluistert) dan kan een kwaadwillende gebruiker de cookie handmatig instellen om de beveiligde sessie na te bootsen. De kwaadwillende gebruiker kan nu met jou beveiligde cookie inloggen.

Het na-apen van een sessie met een “gestolen” cookie noemen we “Session Hijacking”.

Het afluisteren met een netwerk sniffer is makkelijk omdat http requests over het netwerk verzonden worden zonder enige encryptie. Het verzenden over een veilige verbinding (SSL) zal dit probleem oplossen. Een sniffer kan de namen en waardes van een cookie niet achterhalen van een versleutelde cookie.

Een andere beveiligingsoptie is om een unieke sessiesleutel aan de cookie mee te geven. Deze sessiesleutel wordt gebaseerd op fysieke eigenschappen van de originele gebruiker. Denk hierbij aan een random sleutel op basis van bijvoorbeeld IP adres, datum, tijd, gebruikersnaam etc. Een cookie met een sessiesleutel is een stuk lastiger om te dupliceren en opnieuw af te spelen maar niet onmogelijk.

Het stelen van een cookie (op welke manier van ook) noemen we “cookie stealing”.

Cross Site Scripting (XSS):

Cross Site Scripting is een aanval waarbij gebruik cookies gestolen kunnen worden d.m.v. javascripts van een derde partij.

Scrips (zoals javascript) kunnen op vele manieren opgenomen zijn op je pagina. Je kunt gebruik maken van een iFrame (oud maar soms nog onmisbaar), script inclusion buiten je eigen host, css inclusion buiten je eigen host etc.

Met het javascript command “document.cookie” kunnen cookies verkregen worden. Zo kan een klein script ervoor zorgen dat alle cookies die je server verzend ook naar een malafide partij doorgestuurd worden. De malafide partij kan met deze hoeveelheid cookies vele soorten aanvallen inplannen. Een belangrijke tip is om heel voorzichtig te zijn met het includen van javascripts van derde. Beter is om dit gewoon niet toe te staan.

Verkeerde input sanitizing (controle en filtering van gebruikers input) kan ook een XSS aanval tot gevolg hebben. Stel voor dat je een contactformulier hebt met een tekstveld. De server zal de content van het formulier verzenden middels een POST command. Als de content niet gefilterd wordt dan kan een compleet script worden uitgevoerd. Het is dus zaak om gebruikersinput altijd te filteren van ongewenste karakters en HTML tags.

Cross-Site Request Forgery:

CSRF is een aanval gebaseerd op het XSS principe. Ook hier wordt weer gebruik gemaakt van verkeerde input sanitizing.

Stel je voor dat je op een forum bent waarbij input sanitizing niet netjes gebeurt. Een kwaadwillende gebruiker kan hier een afbeelding geplaatst hebben (niet zichtbaar en met kwaadwillende code). De afbeelding kan bijvoorbeeld code bevatten om geld te storten naar de bankrekening van de kwaadwillende gebruiker. De code zal het commando bevatten om geld te storen.

Als u op de bank bent ingelogd en vervolgens het forum opent dan zal de bank het comando ontvangen en goedkeuren omdat u netjes (geauthoriseerd) bent ingelogd op de webpagina van de bank.

CSRF misbruikt dus valide cookies die door u gemaakt zijn zonder ze te hoeven stelen.

Als u met belangrijke / gevoelige informatie omgaat is het aan te raden om alle andere internetbrowsers en tabbladen te sluiten.

Websites die belangrijke / gevoelige informatie afhandelen doen er goed aan om de gebruiker nogmaals om zijn inloggegevens te vragen wanneer deze een belangrijke actie onderneemt (overschrijven van geld, aanpassen account wachtwoord etc.).

Cookie beveiliging:

Zoals hierboven te lezen is moeten de meeste veiligheidsacties genomen worden door derde (SSL, Input Sanatizing, korte TTL etc).

Als u (als eindgebruiker / website bezoeker) zichzelf wilt beschermen is de meest logische beveiliging om alle cookies te blokkeren. Dit blokkeren kan ingesteld worden via de browser. Elke browser heeft een optie om cookies uit te schakelen. Een nadeel hieraan is dat u de controle krijt bent en dat veel websites niet naar behoren zullen functioneren. Cookies zijn immer belangrijk voor veel functionele onderdelen. U als eindgebruiker kunt een paar zaken doen zonder al te veel belemmering te ondervinden:

• Sluit browsers en browser tabs als u gevoelige informatie gaat verzenden of gebruiken
• Maak gebruik van een cookie manager en blokkeer alleen third-party cookies
• Verwijder cookies geregeld en maak geen gebruik van de “onthoud mij’ functie

Developers kunnen bovenstaande actiepunten in acht nemen. Ook is het goed om belangrijke cookies over SSL te verzenden en om de cookie zelf zo veilig mogelijk te maken. Een relatief veilige cookie maken kan door onderstaande zaken in acht te nemen:

• Zorg ervoor dat een cookie alleen maar verzonden wordt naar 1 applicatie of web gedeelte. Dit kan middels de “Path” flag. De path flag op / laten staan betekend dat de cookie iedere keer wordt verzonden.
• Zorg ervoor dat de cookie alleen van toepassing is op 1 domein of sub-domein en niet op alle domeinen en sub-domeinen. Dit kan geregeld worden met de “Domain” flag.
• Als er SSL gebruikt wordt stel dan de “Secure” flag. Op deze manier wordt de cookie niet verzonden over onveilige verbindingen.
• Zet de HttpOnly flag. Hiermee worden XSS aanvallen voorkomen omdat javascript de inhoud van de cookie dan niet kan lezen. HttpOnly wordt door de meeste nieuwe browsers ondersteund maar niet door oudere browsers.

Voorbeeld van een onveilige cookie (in PHP):

setcookie( name, value, expire, path, domain, secure, httponly);
setcookie( 'UserName', 'Q5', 0, '/', '.voorbeeld', false, false);

Voorbeeld van een “veilige” cookie (in PHP):

setcookie( name, value, expire, path, domain, secure, httponly);
setcookie( 'UserName', 'Q5', 0, '/ website-beveiliging', '//www.jarnobaselier.nl/', isset($_SERVER["HTTPS"]), true);

Conclusie:

De discussie of cookies gebruikt moeten blijven worden is nog steeds in volle gang. Cookies nemen zoveel risico met zich mee dat je ze eigenlijk uit zou willen zetten. Maar omdat dat weer zoveel ongemak met zich meeneemt zou er een alternatief voor cookies moeten komen (b.v. REST). Momenteel worden cookies nog veelvoudig gebruikt maar kan er veel aan gedaan worden om deze te beveiligen. Het is alleen voor de eindgebruiker niet goed inzichtelijk hoe veilig de cookies van de bezochte websites zijn. Een goede developer zal rekening houden met een stukje veiligheid (ook in de cookies). Maar als eindgebruiker kun je maar een paar dingen in acht nemen (zie boven). Maak hier dan ook gebruik van. En voor het overige deel is het vooral browsen op basis van “goed vertrouwen” en dat is op zich alweer gevaarlijk…