Door pikah
Dit is een hele goede vraag, waarvan het antwoord niet al te
eenvoudig
is. Je kan namelijk op meerdere manieren het risico verminderen.
1. Sessie time-out, probeer deze zo laag mogelijk te houden,
maar
zorg wel dat het acceptabel blijft voor de gebruikers, elke
minuut je
password opnieuw intypen is dus niet acceptabel
:)
Bedoel je hiermee de sessie expire time, of iets
van een idle timeout? Lijkt me dan gewenster een idle
timeout. Maar zeker een goed idee om te implementeren.
Bedankt. :)
2. Encryption, je zou je SID kunnen encrypten voordat hij in
de cookie
terecht komt. (Is wel een stuk moeilijker om het goed te
implementeren)
Hoe had je in gedachte om dit zo te encrypten dat de cookie
niet gejat kan worden. De encryptie key moet dan per
browser/client anders zijn, wil dit werken tegen cookie
hijacken. Als de key overal hetzelfde blijft om te
encrypten, heb je eigenlijk gewoon een andere representatie
van het sessie id te pakken. Hier schiet je dan niet zoveel
mee op, want als de hijacker gewoon de cookie precies
hetzelfde houd, dus niks met die encryptie doet, dan herkend
de server de cookie nog steeds als geldig.
3. Er zijn twee verschillende soorten cookies,
persistent cookies en per-
session cookies, de per-session cookies bestaan alleen
tijdens de
sessie zelf en zullen dus niet op de harde schijf worden
opgeslagen,
maar in het geheugen (Dit kan ook uitgelezen worden, maar is
een
heel stuk ingewikkelder).
Bij beveiliging is het eigenlijk ook de bedoeling om de boel
zoveel mogelijk te beveiligen, terwijl het toch acceptabel
blijft voor de gebruiker. Aangezien het een ticket
gebasseerde SSO implementatie wordt, moet minimaal het login
ticket, of in Kerberos bekende Ticket Granting Ticket (of
TGT), als persistant cookie worden opgeslagen, aangezien die
gewoon moet onthouden blijven worden. De verschillende
service tickets kunnen wel als per-session cookie worden
opgeslagen, aangezien dat toch gewoon software sessies zijn.
4. Client-side authenticatie via certificaten en SSL,
hierdoor moet de hacker niet alleen de cookie hebben maar
ook de private key van de client en de sleutel van de SSL
sessie.
Hier zat ik ook al te denken. Het probleem is hier echter
wel, dat we geen controle hebben over alle systemen waarop
de gebruiker inlogd binnen het systeem. Daarom zal dit een
optionele systeem moeten worden.
Een combinatie van deze oplossingen is dus een reele
beveiliging. Let
wel op dat je nooit 100% zeker bent dat je cookie niet
gevonden wordt,
gedecrypt wordt en dit ook nog eens binnen de sessie tijd,
maar je
verminderd het risico aanzienlijk.
EDIT: Iets wat nog in me op kwam, op het moment dat de
gebruiker de browser sluit zorgen dat automatisch de sessie
word be-eindigd en de cookie verwijderen. (Dit is niet
altijd te realiseren, maar in sommige gevallen wel)
Hiervoor zou ik eerder die idle timeout gebruiken lijkt me.
Dit vergt wel heel veel werk, wat ook vrij fout gevoelig is.
Daarom wil ik dit liever niet implementeren.
Hier ga ik nog even naar kijken.
Uiteraard is een zowat verplichte beveiliging, anti- Session
Fixation
(
http://en.wikipedia.org/wiki/Session_fixation).
Dit had ik geloof ik nog niet genoemd. Hier heb ik al wel
aan gedacht.
XSS (Cross Site Scripting) moet natuurlijk ook gewoon
beveiligd worden, maar dit valt onder input validation. Die
wil ik zowieso erg streng maken.