session timeout

Maak je de sessie timeout-duur te lang, bijv. 2 uur, dan vergroot je (theoretisch gezien) de kans dat een sessie wordt gekaapt.

Toch alleen als je beveiliging ontoereikend is.

Zoals ik al eerder heb aangegeven, in plaats van het krampachtig proberen je sessies in leven te houden kun je beter inzetten op een strategie waarbij het niet uitmaakt dat deze (veelvuldig) verlopen en weer (veelvuldig) naadloos vervolg worden (onder water geherstart worden) zonder dat dit je applicatie/workflow/whatever breekt.

Gebruikelijke time-outs zijn 15 tot 30 minuten voor applicaties met een laag risico en 2 tot 5 minuten voor applicaties met een hoog risico.

@Thomas

Ik snap niet helemaal wat je bedoelt. Eenmaal verlopen is verlopen, dus dan kun je niet onderwater herstarten. Er zal op dat moment een nieuwe sessie worden gestart en alle sessie-data is dus foetsie. Wat ik bedoel te zeggen is ... soms wil je niet dat een sessie (te) snel verloopt. Stel iemand heeft spullen in z'n winkelmand gegooid en gaat even een blokje om lopen. Komt een half uur later terug. Klikt op z'n winkelmandje om af te rekenen, maar in de tussentijd is de sessie verlopen. Mogelijk gevolg, klant raakt gefrustreerd en sluit de browser af. Koop gaat niet door. Tegelijkertijd ... de back-end van een website wil je weer niet té lang hebben open staan. De vraag is dus of er een soort "balans" is. Ik lees ook websites waar ze pas na 24 uur een timeout doen. Zo'n sessie blijft dus een hele dag lang geldig. Als tegengeluid hoor je hier dan weer dat je moet oppassen voor session hijacking. Hoewel je daar het een en andere tegen kunt doen, is het wel een reëel risico. Hoe reëel? Geen idee ... daarom ben ik dus benieuwd naar ervaringen / best practices.

@Ward

>> Je opent de laatste tijd voortdurend vragen over het configureren van een VPS

Waar in de richtlijnen van dit forum staat dat dit niet mag? Iedereen is vrij om vragen te stellen en iedereen is vrij om die te beantwoorden (of niet). Volgens mij is dit forum bedoeld om elkaar te ondersteunen en helpen. Het inrichten van een server beslaat veel meer facetten dan enkele php.ini instellingen waar ik graag even over wil sparren.

Ik vind jouw reactie in deze een beetje vreemd en ook onverwachts. Liever had ik dan nog gehad dat je me een persoonlijk berichtje had gestuurd. Maar goed, als jij dit topic graag wil dichtgooien ... go ahead.

Ik moet het hierin met Ozzie eens zijn dat een forum bedoeld is om vragen te stellen. Nu is dit topic niet zo zinnig aanvoelt als sommige anderen, maar ook de PHP configuraties bestaat uit veel nuances en individuele situaties.

Daarbij snap ik waar Thomas op doelt, je kunt je sessies combineren met andere methoden, bijvoorbeeld een cookie met een token oid, op welke basis je sessies kunt opbouwen/hervatten mbv gegevens die je al hebt. Ik heb zelf eerder gespeeld met een database session handler die in plaats van data verwijderen de data als inactief meldde, en na X periode uiteindelijk de zaak schoonveegde. Als je hier een token aanhangt kun je blijven hervatten zo vaak als je wilt.

Ben, thanks voor je reactie. Er zit iets raars/dubbelzinnig in het sessie-systeem. Van de ene kant wil je het een gebruiker zo makkelijk mogelijk maken: je wilt in feite niet dat een gebruiker telkens opnieuw moet inloggen of z'n gegevens moet invullen. Als ie 's ochtends z'n winkelmandje vult, wil je bij wijze van dat ie 's avonds nog steeds op "afrekenen" kan drukken. In het geval het enkel om een winkelmandje gaat en er geen persoonlijke gegevens zijn ingevuld zou dit nog niet eens erg zijn ook. Sterker nog, als er wel persoonlijke gegevens zijn ingevuld zou het ook nog niet erg zijn ... pas als er sprake is van een "afgeschermde omgeving" waar je eerst moet inloggen, wordt het tricky.

In een back-end zou je bijv. kunnen kiezen dat een sessie 20 min. openstaat ... maar achter de schermen kun je ervoor zorgen dat de daadwerkelijk timeout langer duurt, bijv. een uur. Als de gebruiker 20 minuten lang niks doet, kun je bij de eerstvolgende request vragen om het wachtwoord. Als dat klopt, dan kun je de sessie weer vrijgeven, en als het niet klopt dan kun je de sessie-data vernietigen. Gevolg is dan wel dat als een gebruiker inlogt en een uur lang niks doet, het sessie-bestand op de achtergrond een uur lang "actief" is en pas na dat uur als inactief wordt bestempeld. Vergroot dit het risico op session-hijacking?

Daarnaast geldt dat je te maken hebt met de GC timings binnen PHP, de timeout is daarmee niet alles dat meetelt. Na de timeout gaat de collector aan de slag, en het kan gebeuren dat een sessie pas uren later werkelijk verwijderd wordt.

De manier die je schetst kan een uitkomst bieden, bij verloop van de sessie om een wachtwoord vragen. Dit vereist tegelijk wel dat je in een cookie bijhoudt om welke gebruiker het gaat. Als je een session cookie gebruikt (timeout 0) is dit geen enkel punt, bij het sluiten van de browser gaat dit cookie verloren.

Op het punt van hijacking: session hijacking kan voorkomen wanneer je onveilig met de data omgaat. Net als dat je niet wilt dat URLs van het backend bekend worden. Hier zijn uiteraard oplossingen voor, zoals een tussenliggende pagina op een neutrale locatie, die mbv bijvoorbeeld een Refresh header de uiteindelijke URL opvraagt, dan is de Referer header tenminste leeg. Verder is het zaak om gewoon te voorkomen dat men toegang krijgt tot de session id, en een eenvoudige oplossing is session.use_only_cookies aan te zetten, waardoor er geen session id's in urls gestopt worden. Uiteraard kun je per sessie de parameters instellen met o.a. [php]session_set_cookie_params[/php]

>> Daarnaast geldt dat je te maken hebt met de GC timings binnen PHP, de timeout is daarmee niet alles dat meetelt. Na de timeout gaat de collector aan de slag, en het kan gebeuren dat een sessie pas uren later werkelijk verwijderd wordt.

Ja inderdaad ... de sessie blijft nog even aanwezig totdat de GC in actie komt. Ook weer zo'n leuke. Die kun je heel "strak" afstellen, zodat ie bij ieder request wordt getriggerd, maar dat is dan weer niet lekker voor de performance ... althans dat stelt men. De default session.gc_divisor in mijn php.ini stond maar liefst op 1000 en session.gc_probability op 0! Waarschijnlijk probeert mijn hostingboer op deze manier om zo min mogelijk processorkracht te verbruiken. Maar die GC komt dan dus nooit in actie :-s

>> Dit vereist tegelijk wel dat je in een cookie bijhoudt

Dat gaat toch als het goed is automatisch als je een sessie-start. In de sessie zelf moet ik dan een "last_active_time" of iets dergelijks opnemen, die ik dan vergelijk met de huidige tijd.

>> Hier zijn uiteraard oplossingen voor, zoals een tussenliggende pagina op een neutrale locatie ...

Ik volg niet helemaal wat je hiermee bedoelt. Wat voor pagina bedoel je, en waarom moet de referer leeg zijn? Wie kan daar iets mee?

>> Verder is het zaak om gewoon te voorkomen dat men toegang krijgt tot de session id, en een eenvoudige oplossing is session.use_only_cookies aan te zetten ...

Dat klopt. Dat heb ik gedaan, maar dan nog kan men toch een cookie spoofen met telkens een andere session-id? Wel een hoop werk en weinig kans van slagen .. maar de mogelijkheid is er wel lijkt me.

>> Dat klopt. Dat heb ik gedaan, maar dan nog kan men toch een cookie spoofen met telkens een andere session-id? Wel een hoop werk en weinig kans van slagen .. maar de mogelijkheid is er wel lijkt me.

De mogelijkheid is er wel, maar dat zal volgens hetzelfde stramien (en dus hetzelfde tempo) gaan als het raden van een wachtwoord. Hoe lang gaat het duren om de juiste string te raden uit 63^27 mogelijkheden?

>> De default session.gc_divisor in mijn php.ini stond maar liefst op 1000 en session.gc_probability op 0! Waarschijnlijk probeert mijn hostingboer op deze manier om zo min mogelijk processorkracht te verbruiken. Maar die GC komt dan dus nooit in actie :-s

Ik weet dat op Debian standaard de gc_probability op 0 staat, en met cronjob verouderde session bestanden worden weggegooid. Mogelijk speelt bij jou iets soortgelijks.

>> Dat gaat toch als het goed is automatisch als je een sessie-start. In de sessie zelf moet ik dan een "last_active_time" of iets dergelijks opnemen, die ik dan vergelijk met de huidige tijd.

Als je sessie vernietigd wordt door een timeout lijkt het me niet dat je nog bij de gegevens in de sessie kan, dus je zult dit apart moeten opslaan van je sessie.

>> Ik volg niet helemaal wat je hiermee bedoelt. Wat voor pagina bedoel je, en waarom moet de referer leeg zijn? Wie kan daar iets mee?

Het zou niet de eerste keer zijn dat ik zie dat een aanval getriggerd wordt door een ongelukkige link naar een externe partij, die bij het ontdekken van de URLs naar een backoffice vol aan de slag ging. Hoe beter je je backend verborgen kunt houden, hoe veiliger het blijft. Dit is uiteraard iets dat naast de beveiliging speelt, maar als niemand weet waar hij moet zijn om je backend te benaderen loopt het risico ook enorm terug.

>> Hoe lang gaat het duren om de juiste string te raden uit 63^27 mogelijkheden?

Eens, maar als je een sessie pas na 24 uur een time-out geeft, dan heeft men dus wel een dag de tijd om te 'raden'.

>> Ik weet dat op Debian standaard de gc_probability op 0 staat, en met cronjob verouderde session bestanden worden weggegooid. Mogelijk speelt bij jou iets soortgelijks.

Oké, dat wist ik niet. Ik lees het hier nu inderdaad. Oplossing is inderdaad gewoon om de waarde te wijzigen.

>> Als je sessie vernietigd wordt door een timeout lijkt het me niet dat je nog bij de gegevens in de sessie kan, dus je zult dit apart moeten opslaan van je sessie.

Haha, ja da's inderdaad een goede ... dat gebeurt op het moment dat de sessie dus écht z'n limiet heeft bereikt. Bijv. de sessie timeout vindt na een uur plaats, maar na 20 min. inactiviteit maak je deze onbereikbaar voor de gebruiker (bijv. omdat die in de back-end aan het werk is). Voordat hij verder kan moet hij dan eerst z'n wachtwoord invoeren. Echter, doet hij een uur helemaal niks, dan is de sessie compleet verlopen en zal er een nieuwe sessie worden aangemaakt. Anders gezegd 'achter de schermen' bestaat de sessie een uur, maar na 20 min. inactiviteit moet een gebruiker eerst een wachtwoord invoeren om verder te kunnen. Gaat dat mis, dan kun je de sessie verwijderen/leegmaken.

En hier raken we dus de kern van mijn vraag ... wat is een goede duur voor de sessie timeout? Na hoeveel minuten COMPLETE inactiviteit moet je zeggen: oké, vanaf nu is deze sessie echt niet geldig meer. Daarbij spelen in principe 2 factoren van belang. 1. Je wil een gebruiker voldoende tijd geven om iets te kunnen doen. 2. Je wil een actieve sessie niet te lang 'in leven houden' om sessie-hijacking te voorkomen. Wat gebruik jij zelf meestal als session timeout?

>> ... maar als niemand weet waar hij moet zijn om je backend te benaderen loopt het risico ook enorm terug.

Dat is zeker waar. Goed punt inderdaad.

PS Weet jij trouwens of een verlopen sessiebestand nog benaderd kan worden? Stel een sessie krijgt na een half uur een timeout, maar wordt pas een paar uur later door de gc verwijderd. Kan in de tussentijd dan iemand die sessie nog benaderen door de session id te 'raden', of zegt het sessiebestand dan 'ik ben o niet meer geldig' en gebeurt er verder niks?

Wederom lijk je één antwoord te willen op een (hypotethische) vraag die meerdere antwoorden heeft.

Mijn antwoord zou zijn: zou afhangen van de applicatie.

Maar ook: er zijn meerdere manieren om een probleem op te lossen, bijvoorbeeld door het wegnemen van het probleem zelf. In een oplossing waarbij het niet uitmaakt dat een sessie verloopt is het verlopen van een sessie geen probleem...

Het is maar net hoe ver je je catering voor (de domheid?) van een gebruiker wilt laten gaan. Ik ken weinig mensen die in een shopping-spree voor de aankoop nog even een wandeling gaan maken eigenlijk.

It is impossible to make anything idiot proof, because idiots tend to be ingenious.

Net als dat je niet wilt dat URLs van het backend bekend worden.

Security through obscurity is zelden een goed ontwerpprincipe.

Het zou niet de eerste keer zijn dat ik zie dat een aanval getriggerd wordt door een ongelukkige link naar een externe partij, die bij het ontdekken van de URLs naar een backoffice vol aan de slag ging.

Als ik het bovenstaande zo lees dan was de veiligheid van die applicatie(s) lang niet robuust genoeg. En wederom is dan een menselijke f*ckup de bron van alle ellende (maar je zou dus ook vraagtekens kunnen plaatsen bij de sterkte van security als je dmv een link een backend in kan duiken). Een systeem beveiligen met state-of-the-art shizzle heeft weinig zin als iemand het moeilijk te onthouden wachtwoord als post-it aan zijn/haar monitor plakt eh.

Om ten langen leste antwoord te geven op je generieke vraag, een generiek antwoord:
De default sessie-timeout is een goede sessie-timeout. Te meer omdat deze al naar gelang de situatie on-the-fly aangepast kan worden.