Bekijk Volledige Versie : [php] Session hijacking detection
Tjerk Wolterink
29/03/05, 14:05
In mijn script wil ik session hijacking voorkomen, dit doe
ik in php als volgt:
if (!isset($_SESSION['ip']))
$_SESSION['ip']=$_SERVER['REMOTE_ADDR'];
if($_SESSION['ip']!=$_SERVER['REMOTE_ADDR']) {
trigger_error("Session Hijacking detected!", E_USER_WARNING);
}
Maar nu kreeg iemand deze melding terwijl hij gewoon de site aan het bezoeken
was, wat bleek:
"Wellicht omdat ik om duistere redenen via de XS4ALL-proxy-server surfte;
die geeft me soms per request een ander IP-nummer."
Dus deze manier van session-hijacking is geen goed idee dus?!?!?
Hoe voorkom je session hijacking zonder dat iemand ongewenst deze melding krijgt?
On Tue, 29 Mar 2005 13:59:11 +0200,
Tjerk Wolterink <tjerk@wolterinkwebdesign.com> wrote:
> $_SESSION['ip']=$_SERVER['REMOTE_ADDR'];
>
> Maar nu kreeg iemand deze melding terwijl hij gewoon de site aan het
> bezoeken was, wat bleek:
>
> "Wellicht omdat ik om duistere redenen via de XS4ALL-proxy-server surfte;
> die geeft me soms per request een ander IP-nummer."
Kijk of er een HTTP_X_FORWARDED_FOR aanwezig is.
> Hoe voorkom je session hijacking zonder dat iemand ongewenst
> deze melding krijgt?
Er zijn een aantal zaken die het moeilijk maken om een session te
hijacken. 1 ervan gebruik je maar er zijn nog andere dingen die wellicht
veel belangrijker zijn. Zorg er bijvoorbeeld voor dat je op de server
geen transparante session id's doorgeeft in de url en check naast het
ipnummer iets als bijvoorbeeld de gebruikte browser versie.
Groet,
Hans
--
http://blacklist.kernelnewbies.nl
Daniel Tryba
29/03/05, 22:35
Hans <spamikaze@gmail.com> wrote:
>> $_SESSION['ip']=$_SERVER['REMOTE_ADDR'];
>>
>> Maar nu kreeg iemand deze melding terwijl hij gewoon de site aan het
>> bezoeken was, wat bleek:
>>
>> "Wellicht omdat ik om duistere redenen via de XS4ALL-proxy-server surfte;
>> die geeft me soms per request een ander IP-nummer."
>
> Kijk of er een HTTP_X_FORWARDED_FOR aanwezig is.
En dan? Die header is heeeeel makkelijk te faken.
>> Hoe voorkom je session hijacking zonder dat iemand ongewenst
>> deze melding krijgt?
>
> Er zijn een aantal zaken die het moeilijk maken om een session te
> hijacken. 1 ervan gebruik je maar er zijn nog andere dingen die wellicht
> veel belangrijker zijn.
Maar het checken op IP addr levert _juist_ problemen op. Je sluit er ten
onrechte mensen mee uit, bv mensen die achter een loadbalanced proxy
zitten of die gewoon meerdere uplinks hebben. Verder helpt het niet
tegen transparante proxies/NAT waar meerdere gebruikers achter 1 ip
zitten. Of mensen die door een draadloos netwerk roamen (mobile ipv6
heeft daarvoor wel een oplossing maar het zal nog jaren duren voordat
dat tot de wereld doordringt).
> Zorg er bijvoorbeeld voor dat je op de server geen transparante
> session id's doorgeeft in de url en check naast het ipnummer iets als
> bijvoorbeeld de gebruikte browser versie.
Als de proxy de UA string mishandeld geeft dat gegarandeerd problemen.
De problemen met proxies kom je waarschijnlijk relatief vaak tegen bij
grote bedrijven (dat is tenminste mijn persoonlijke ervaring).
Het enige wat je AFAIK kunt doen tegen hijacking is assymetrische
encryptie (er zijn bv RSA implementaties in javascript), het enige
probleem wat je dan hebt is dat http stateless is. Je moet je dus in
allerlei bochten wringen met frames en javascript om de sleutels bij de
client te onthouden (of denk aan applets/activex meuk (bv girotel)).
Of een zinnige manier hebben om client certificaten te genereren en
verspreiden, zodat je gebruik kan maken van de standaard aanwezige SSL
functionatiteit in de browser. Of gebruik maken.
On 29 Mar 2005 20:26:37 GMT, Daniel Tryba <partmapsswen@invalid.tryba.nl> wrote:
> Hans <spamikaze@gmail.com> wrote:
>>> $_SESSION['ip']=$_SERVER['REMOTE_ADDR'];
>>>
>> Kijk of er een HTTP_X_FORWARDED_FOR aanwezig is.
>
> En dan? Die header is heeeeel makkelijk te faken.
Klopt, er is veel te faken.
>>> Hoe voorkom je session hijacking zonder dat iemand ongewenst
>>> deze melding krijgt?
>>
>> Er zijn een aantal zaken die het moeilijk maken om een session te
>> hijacken. 1 ervan gebruik je maar er zijn nog andere dingen die wellicht
>> veel belangrijker zijn.
> Maar het checken op IP addr levert _juist_ problemen op. Je sluit er ten
> onrechte mensen mee uit, bv mensen die achter een loadbalanced proxy
> zitten of die gewoon meerdere uplinks hebben.
Kun je dit toelichten? Ik ga er vanuit dat als iemand met een
browser een 'site' bezoekt dat dit niet via meerdere uplinks
gaat. Wellicht mis ik nog info?
>> Zorg er bijvoorbeeld voor dat je op de server geen transparante
>> session id's doorgeeft in de url en check naast het ipnummer iets als
>> bijvoorbeeld de gebruikte browser versie.
>
> Als de proxy de UA string mishandeld geeft dat gegarandeerd problemen.
> De problemen met proxies kom je waarschijnlijk relatief vaak tegen bij
> grote bedrijven (dat is tenminste mijn persoonlijke ervaring).
Heb dat zelf nog niet meegemaakt.
>
> Het enige wat je AFAIK kunt doen tegen hijacking is assymetrische
> encryptie (er zijn bv RSA implementaties in javascript), het enige
> probleem wat je dan hebt is dat http stateless is. Je moet je dus in
> allerlei bochten wringen met frames en javascript om de sleutels bij de
> client te onthouden (of denk aan applets/activex meuk (bv girotel)).
Je bent op dat moment dan dus ook verplicht om je bezoeker js te laten
gebruiken. Voor een intranet waar werknemers op inloggen zal dat
minder snel een probleem zijn maar er zijn steeds meer mensen die
js uitzetten.
Hans
--
http://blacklist.kernelnewbies.nl
Daniel Tryba
30/03/05, 00:15
Hans <spamikaze@gmail.com> wrote:
>>> Kijk of er een HTTP_X_FORWARDED_FOR aanwezig is.
>>
>> En dan? Die header is heeeeel makkelijk te faken.
>
> Klopt, er is veel te faken.
Maar die header is heeeeeel makkelijk, het enige wat je hoeft te doen is
je locale ipaddr te veranderen (en dat kan je vrijelijk kiezen achter
een NAT gw).
>> Maar het checken op IP addr levert _juist_ problemen op. Je sluit er ten
>> onrechte mensen mee uit, bv mensen die achter een loadbalanced proxy
>> zitten of die gewoon meerdere uplinks hebben.
> Kun je dit toelichten? Ik ga er vanuit dat als iemand met een
> browser een 'site' bezoekt dat dit niet via meerdere uplinks
> gaat. Wellicht mis ik nog info?
Wellicht, maar voor http is het niet van belang welke uplink wordt
gekozen er kan dus zonder probleem een random uplink worden gekozen.
Afhankelijk van de instellingen op de gateway (mijn eigen instellingen
zouden de zelfde uplink tussen request prefereren (niet garanderen))
>> Het enige wat je AFAIK kunt doen tegen hijacking is assymetrische
>> encryptie (er zijn bv RSA implementaties in javascript), het enige
>> probleem wat je dan hebt is dat http stateless is. Je moet je dus in
>> allerlei bochten wringen met frames en javascript om de sleutels bij de
>> client te onthouden (of denk aan applets/activex meuk (bv girotel)).
>
> Je bent op dat moment dan dus ook verplicht om je bezoeker js te laten
> gebruiken. Voor een intranet waar werknemers op inloggen zal dat
> minder snel een probleem zijn
Maar die lopen vaak tegen de proxy/netwerk instellingen aan (waar ze
niet omheen kunnen).
> maar er zijn steeds meer mensen die js uitzetten.
Vette pech dus voor die gebruikers. Maar moderne browsers laten zoiets
toch wel moeten kunnen instellen per domein (in navolging van
popup/cookie en image instellingen).
Tjerk Wolterink
30/03/05, 00:25
Daniel Tryba wrote:
> Hans <spamikaze@gmail.com> wrote:
>
> [knip]
>
Ik hou het toch even bij het hard checken van ip-adres,
de mensen die een dynamisch ip adres hebben heb dan gewoon pech,
en het komt overigens toch niet veel voor dat men
om de 5 minuten een ander ip-adres heeft?
On 29 Mar 2005 22:07:33 GMT,
Daniel Tryba <partmapsswen@invalid.tryba.nl> wrote:
> Hans <spamikaze@gmail.com> wrote:
[Faken ipforwarders]
>> Je bent op dat moment dan dus ook verplicht om je bezoeker js te laten
>> gebruiken. Voor een intranet waar werknemers op inloggen zal dat
>> minder snel een probleem zijn
> Maar die lopen vaak tegen de proxy/netwerk instellingen aan (waar ze
> niet omheen kunnen).
Zit me af te vragen of die over het algemeen je eerder genoemde verhaal
wel mogelijk maken, niet dat dat uitmaakt op het hele vraagstuk want dat
kan ook via andere adressen die daar geen last van hebben natuurlijk.
>> maar er zijn steeds meer mensen die js uitzetten.
>
> Vette pech dus voor die gebruikers. Maar moderne browsers laten zoiets
> toch wel moeten kunnen instellen per domein (in navolging van
> popup/cookie en image instellingen).
En dan nog wachten op browsers die niet lek zijn.
Hans
--
http://blacklist.kernelnewbies.nl
On Wed, 30 Mar 2005 00:17:44 +0200,
Tjerk Wolterink <tjerk@wolterinkwebdesign.com> wrote:
> Daniel Tryba wrote:
>> Hans <spamikaze@gmail.com> wrote:
> Ik hou het toch even bij het hard checken van ip-adres,
> de mensen die een dynamisch ip adres hebben heb dan gewoon pech,
> en het komt overigens toch niet veel voor dat men
> om de 5 minuten een ander ip-adres heeft?
Bij alleen een check op het ipnummer gaat het zeer zeker mis.
Hans
--
http://blacklist.kernelnewbies.nl
Daniel Tryba
30/03/05, 01:45
Hans <spamikaze@gmail.com> wrote:
>>> Je bent op dat moment dan dus ook verplicht om je bezoeker js te laten
>>> gebruiken. Voor een intranet waar werknemers op inloggen zal dat
>>> minder snel een probleem zijn
>
>> Maar die lopen vaak tegen de proxy/netwerk instellingen aan (waar ze
>> niet omheen kunnen).
>
> Zit me af te vragen of die over het algemeen je eerder genoemde verhaal
> wel mogelijk maken, niet dat dat uitmaakt op het hele vraagstuk want dat
> kan ook via andere adressen die daar geen last van hebben natuurlijk.
Ik volg het even niet. Vraag je je af of het mogelijk is om een
willekeurig ipaddress te stoppen in de x_forwarded_for header?
Ronald Klip
30/03/05, 03:05
Daniel Tryba schreef:
> Tjerk Wolterink <tjerk@wolterinkwebdesign.com> wrote:
> > Ik hou het toch even bij het hard checken van ip-adres,
> > de mensen die een dynamisch ip adres hebben heb dan gewoon pech,
> > en het komt overigens toch niet veel voor dat men
> > om de 5 minuten een ander ip-adres heeft?
Bij die proxy dus wel. Geen idee of dial-uppers daar nog veel gebruik van
maken.
[snip IPv6]
> Maar ipv een foutmelding zou je natuurlijk wel zo vriendelijk kunnen
> zijn om een authentificatie pagina te tonen ipv botweg te stoppen.
De opgevraagde pagina werd gewoon getoond, met toevoeging van de warning
(error-reporting niveau E_USER_WARNING).
--
http://www.europese-grondwet.nl/ - opinie en informatie
Tjerk Wolterink <tjerk@wolterinkwebdesign.com> wrote:
>Daniel Tryba wrote:
>> Hans <spamikaze@gmail.com> wrote:
>>
>> [knip]
>>
>
>Ik hou het toch even bij het hard checken van ip-adres,
>de mensen die een dynamisch ip adres hebben heb dan gewoon pech,
>en het komt overigens toch niet veel voor dat men
>om de 5 minuten een ander ip-adres heeft?
Zeer veel (alle?) AOL-users hebben wisselende IP-adressen.
Met vriendelijke groeten
John
--
<http://webcel.nl/> webshopsoftware
<http://oswebshop.nl/>
"Time is what prevents everything from happening at once"
- John Archibald Wheeler -