[Web] Session Hijacking achter NAT
04-10-2007,22:46 door
Ik ben bezig met beveiliging van een authenticatie systeem,
wat via PHP werkt. Nu is dit een SSO systeem. Omdat dit een
authenticatie systeem is, wil ik dit zo veilig mogelijk
hebben. Nu is er 1 probleem waar ik wat moeite mee heb en
dat is het voorkomen van session hijacking.
De meeste van jullie weten waarschijnlijk wel, dat een
standaard PHP sessie makkelijk te hijacken is. Je grijpt een
session cookie van iemand (eigenlijk alleen de session id)
en je bent binnen. De bekende if ($_SESSION["loggedin"])
werkt zelf niet daartegen.
Nu heb je in PHP de functie, session_regenerate_id(true).
Deze functie hergenereerd je sessie id. Dit verkleind enorm
de tijd op waarop iemand je sessie kan hijacken. Dit komt
omdat hij bij elke keer bij het laden een nieuwe sessie id
krijgt, waardoor de oude ongeldig wordt. Nu is dat een
redelijk goede beveiliging. Maar stel nu dat bij de laatste
handeling die de gebruiker doet op de site, de cookie wordt
gejat, dan krijgt de aanvaller alsnog een geldige id.
Nu kun je de sessie ook nog aan een IP koppelen. Ik neem
meteen ook maar even mee dat je de sessie ook aan useragent,
accept language, accept charset, etc zou koppelen. Dus dan
heb je een identiteit te pakken die bijna zeker aan
jouw browser is gekoppeld. Maar nu komt het probleem:
Stel je zit in een groot bedrijf. Dit bedrijf zit achter een
NAT router. Bedrijf heeft allemaal gestandariseerde
software. Dit betekend dat bij dit bedrijf, bij elke PC de
volgende gegevens gelijk zijn: extern ip, useragent, accept
language, accept charset, nog wat browser specifieke dingen.
Stel ze gebruiken geen proxy die X-forwarded-for meegeeft,
dus aan intern IP kun je ze ook niet aan herkennen. Als
conclusie uit dit laatste stukje kun je trekken, dat elke
PC, binnen het bedrijfs netwerk, gelijk is voor de
webserver. Ze hebben allemaal dezelfde identiteit. Dus de IP
koppeling en andere browser checks die gekoppeld zijn aan de
sessie komen ze door.
Als ze nu in dit geval, de laatste cookie van de gebruiker
jatten, vanuit het bedrijfsnetwerk, dan kunnen ze gewoon
verder met de sessie. Dit omdat ze alle checks gewoon doorkomen.
Nu zeg ik er even bij dat dit SSO systeem WEB only is, dus
niet iets als kerberos ofzo, wat ook systemen in het netwerk
identificeerd. Ga er ook maar even van uit dat we niet
altijd controlle hebben over het netwerk.
Hoe kun je toch voorkomen, dat mensen binnen het netwerk
(achter NAT), toch niet de sessie kunnen overnemen van de
collega?
Het probleem wat er namelijk is, je hebt namelijk geen
100% zekere identiteit van de specifieke PC. Dit is
ook wel logisch, vanwege privacy redenen. Anders kon Google
wel heel makkelijk een profiel van je schetsen, wat ze nu
overigens ook heel goed kunnen.
Hoe gaan jullie met dit probleem om?
Houd er wel even rekening mee dat het SSO is, dus ook niet
bedoeld is om voor elke pagina opnieuw te authenticeren.
Uiteraard gaan erg belangrijke pagina's, zoals wachtwoord
wijziging, wel met de vraag om nog een keer je wachtwoord in
te voeren.
wat via PHP werkt. Nu is dit een SSO systeem. Omdat dit een
authenticatie systeem is, wil ik dit zo veilig mogelijk
hebben. Nu is er 1 probleem waar ik wat moeite mee heb en
dat is het voorkomen van session hijacking.
De meeste van jullie weten waarschijnlijk wel, dat een
standaard PHP sessie makkelijk te hijacken is. Je grijpt een
session cookie van iemand (eigenlijk alleen de session id)
en je bent binnen. De bekende if ($_SESSION["loggedin"])
werkt zelf niet daartegen.
Nu heb je in PHP de functie, session_regenerate_id(true).
Deze functie hergenereerd je sessie id. Dit verkleind enorm
de tijd op waarop iemand je sessie kan hijacken. Dit komt
omdat hij bij elke keer bij het laden een nieuwe sessie id
krijgt, waardoor de oude ongeldig wordt. Nu is dat een
redelijk goede beveiliging. Maar stel nu dat bij de laatste
handeling die de gebruiker doet op de site, de cookie wordt
gejat, dan krijgt de aanvaller alsnog een geldige id.
Nu kun je de sessie ook nog aan een IP koppelen. Ik neem
meteen ook maar even mee dat je de sessie ook aan useragent,
accept language, accept charset, etc zou koppelen. Dus dan
heb je een identiteit te pakken die bijna zeker aan
jouw browser is gekoppeld. Maar nu komt het probleem:
Stel je zit in een groot bedrijf. Dit bedrijf zit achter een
NAT router. Bedrijf heeft allemaal gestandariseerde
software. Dit betekend dat bij dit bedrijf, bij elke PC de
volgende gegevens gelijk zijn: extern ip, useragent, accept
language, accept charset, nog wat browser specifieke dingen.
Stel ze gebruiken geen proxy die X-forwarded-for meegeeft,
dus aan intern IP kun je ze ook niet aan herkennen. Als
conclusie uit dit laatste stukje kun je trekken, dat elke
PC, binnen het bedrijfs netwerk, gelijk is voor de
webserver. Ze hebben allemaal dezelfde identiteit. Dus de IP
koppeling en andere browser checks die gekoppeld zijn aan de
sessie komen ze door.
Als ze nu in dit geval, de laatste cookie van de gebruiker
jatten, vanuit het bedrijfsnetwerk, dan kunnen ze gewoon
verder met de sessie. Dit omdat ze alle checks gewoon doorkomen.
Nu zeg ik er even bij dat dit SSO systeem WEB only is, dus
niet iets als kerberos ofzo, wat ook systemen in het netwerk
identificeerd. Ga er ook maar even van uit dat we niet
altijd controlle hebben over het netwerk.
Hoe kun je toch voorkomen, dat mensen binnen het netwerk
(achter NAT), toch niet de sessie kunnen overnemen van de
collega?
Het probleem wat er namelijk is, je hebt namelijk geen
100% zekere identiteit van de specifieke PC. Dit is
ook wel logisch, vanwege privacy redenen. Anders kon Google
wel heel makkelijk een profiel van je schetsen, wat ze nu
overigens ook heel goed kunnen.
Hoe gaan jullie met dit probleem om?
Houd er wel even rekening mee dat het SSO is, dus ook niet
bedoeld is om voor elke pagina opnieuw te authenticeren.
Uiteraard gaan erg belangrijke pagina's, zoals wachtwoord
wijziging, wel met de vraag om nog een keer je wachtwoord in
te voeren.
