[Alg] Hoe omgaan met tijdelijke sessions

[robertpNL]

Al een tijdje loop ik met een vervelend gevoel over tijdelijke sessies. Hoe zou ik als programmeur daar mee om moeten gaan. Ik heb het dan over sessies die aktief zijn tijdens het browsen. En zodra de browser wordt afgesloten, of men logt uit, dan zullen de sessies moeten verdwijnen.

Nu heb ik dit aan de server kant geregeld, maar is dat slim? Handig? Moet ik dan misschien aan de client kant regelen (cookies?).

Wie kan mij goede documentatie verschaffen omtrent tijdelijke sessies? Jaaa, google weet ik, maar ik ben niet echt documentatie tegengekomen die mij heel duidelijk kan vertellen wat de voor- en nadelen zijn van tijdelijke sessies, zowel aan de server als aan de client kant.

Bedankt.

[Verwijderd]

Ik zou serverside sessies nemen, die zijn moeilijker te omzeilen denk ik, één van de grote beveiligingsproblemen van cookies is dat je het wachtwoord moet opslaan, al is het gecodeerd

[faabman]

je kunt je sessies clientside regelen via javascript, dit heeft echter als nadeel dat de gebruiker javascript aan moet hebben staan

je kunt sessies serverside regelen via sessievariabelen, in sommige gevallen betekent dat dat gebruikers cookies aan moeten hebben staan en dat is niet altijd het geval...

wat je imho het beste kunt gebruiken voor internetsites met een maximale reach zijn database-gebaseerde sessies... je geeft dan in de URL de sessieID mee, alles gebeurt dan serverside... je hebt overigens wel een behoorlijke db nodig...

[RedRose]

Een sessie is bijna per definitie tijdelijk. Google vind trouwens voor elke taal wel een tutorial dat over dit onderwerp gaat.

In principe moet je sessie-management nooit laten verlopen via de client. De client opent en sluit namelijk een sessie met een server, dus die server moet bijhouden wanneer de client inlogt, acties doet en weer uitlogt.

Verwijderd schreef op 15 juli 2004 @ 10:22:
Ik zou serverside sessies nemen, die zijn moeilijker te omzeilen denk ik, één van de grote beveiligingsproblemen van cookies is dat je het wachtwoord moet opslaan, al is het gecodeerd

Over het opslaan van wachtwoorden zijn op GoT een paar mooie topics geweest. Sla in ieder geval nooit je wachtwoord op in je cookie.

[Verwijderd]

faabman schreef op 15 juli 2004 @ 10:32:
je geeft dan in de URL de sessieID mee

Dat is echt het allerslechtste wat je kan doen. Waarom? Aan de ene kant kan je dan een pagina niet goed meer bookmarken omdat je sessionID (hoop ik voor je) na enige tijd opgeruimd wordt uit de database en dus niet meer geldig is. Ten tweede is dat makkelijk leesbare informatie en elke kneus met een netwerk sniffer kan URL's sniffen. Met de URL heeft die persoon dan tevens je sessie ID en dus ook je account... Kwalijke zaak.

[gorgi_19]

Verwijderd schreef op 15 juli 2004 @ 11:09:
[...]

Dat is echt het allerslechtste wat je kan doen. Waarom? Aan de ene kant kan je dan een pagina niet goed meer bookmarken omdat je sessionID (hoop ik voor je) na enige tijd opgeruimd wordt uit de database en dus niet meer geldig is. Ten tweede is dat makkelijk leesbare informatie en elke kneus met een netwerk sniffer kan URL's sniffen. Met de URL heeft die persoon dan tevens je sessie ID en dus ook je account... Kwalijke zaak.

Het blijft de enige methodiek als cookies uit staan. Optie blijft dan om maar cookies verplicht te stellen, iets waar je naar mijn idee wel van uit mag gaan dat deze aan staan

Serverside sessies hebben trouwens wel meer nadelen; ze zijn server gebonden. waardoor het een probleem kan opleveren met webfarms. Een stateserver of opslaan in een database kan dan een optie zijn, mits je geen niet-serializable objects gebruikt.

[ Voor 17% gewijzigd door gorgi_19 op 15-07-2004 11:15 ]

[Creepy]

Verwijderd schreef op 15 juli 2004 @ 11:09:
[...]
......

* Creepy mompelt iets over een IP check i.c.m. met een sessieID.
Er zijn ook mensen die geen cookies hebben aanstaan, en dus zul je dan wel je sessieID in de URL moeten opnemen. In bijv. PHP vrij makkelijk te realiseren. Uiteraard kan je ook gewoon roepen "cookies aan of opzouten".

Edit: wat gorgi ook zegt dus

[ Voor 12% gewijzigd door Creepy op 15-07-2004 11:14 ]

[faabman]

Verwijderd schreef op 15 juli 2004 @ 11:09:
[...]

Dat is echt het allerslechtste wat je kan doen. Waarom? Aan de ene kant kan je dan een pagina niet goed meer bookmarken omdat je sessionID (hoop ik voor je) na enige tijd opgeruimd wordt uit de database en dus niet meer geldig is. Ten tweede is dat makkelijk leesbare informatie en elke kneus met een netwerk sniffer kan URL's sniffen. Met de URL heeft die persoon dan tevens je sessie ID en dus ook je account... Kwalijke zaak.

bookmarken: klopt, zijn idd niet te bookmarken...

elke kneus: dat lijkt me niet hè, je koppelt je sessieID aan een IP-adres en enkele andere beschikbare eigenschappen van de bezoeker... Daarnaast zorg je ervoor dat een sessie maximaal 60 minuten inactief mag zijn waarna je hem trashed...

edit:
spuit elf

[ Voor 3% gewijzigd door faabman op 15-07-2004 11:16 ]

[Verwijderd]

Wanneer je de keuze hebt bij de client neerleggen, en zo voorkomen dat er bij elke request database roundtrips gemaakt moeten worden. Je kunt daar simpel op checken.

Dus indien de client cookies ondersteund, sessionsid bijhouden in een cookie, en anders via de url meegeven, en de sessionid opslaan in een session table.

Om een sessie te beeindigen die in cookies is opgeslagen kun je de cookie overschrijven met een expiration. Zodra je de browser sluit is je sessie ook afgelopen.

[Verwijderd]

In deze tijd van NAT gateways is een IP check inderdaad erg betrouwbaar .

Naar mijn idee en ervaring is een van de betere manieren toch het gebruik van cookies. Om geklooi met sniffers te verminderen (voorkomen kan je het nooit helemaal) kan je de cookie nog per request van waarde laten veranderen. Alleen de server kent het algorithme waarmee de cookies veranderen (en het kan zelfs random zijn) en een cookie is dan dus ook maar 1 request geldig. Om problemen met webfarms te voorkomen kan het tracen van de sessie ID via een database lopen. In het .net platform zit een speciale in-memory session service die webfarming niet in de weg zit maar tegelijk ook de overhead van een database vermijdt.

[gorgi_19]

Verwijderd schreef op 15 juli 2004 @ 12:54:
In het .net platform zit een speciale in-memory session service die webfarming niet in de weg zit maar tegelijk ook de overhead van een database vermijdt.

Maar nieuwe overhead introduceert in de vorm van een aparte state server Daarnaast moeten de objecten die je er in stopt dan serializable zijn. Eventueel kan je ook de state in SQL Server opslaan.

[Verwijderd]

Verwijderd schreef op 15 juli 2004 @ 11:09:
[...]

Dat is echt het allerslechtste wat je kan doen. Waarom? Aan de ene kant kan je dan een pagina niet goed meer bookmarken omdat je sessionID (hoop ik voor je) na enige tijd opgeruimd wordt uit de database en dus niet meer geldig is. Ten tweede is dat makkelijk leesbare informatie en elke kneus met een netwerk sniffer kan URL's sniffen. Met de URL heeft die persoon dan tevens je sessie ID en dus ook je account... Kwalijke zaak.

Als het session ID niet meer geldig is schotel je de gebruiker gewoon een pagina voor waar hij (opnieuw) moet inloggen, waarop een nieuwe sessie aangemaakt wordt. En als je heel lief bent stuur je 'm daarop ook meteen door naar de plek die hij net probeerde te bereiken. Minimale irritatie, nette oplossing.

En over dat sniffen: Nee, gelukkig kun je het in een cookie wel stoppen, want dat wordt niet meegesnifft. . Sorry, sarcasme-modus uit.

En puur op IP kun je het niet doen, ivm NAT routers, zoals al is opgemerkt.

Dus blijft er niet veel anders over dan een session-id, danwel in een cookie danwel in het URL, heen en weer sturen.

[Verwijderd]

Verwijderd schreef op 16 juli 2004 @ 11:09:
[...]
En over dat sniffen: Nee, gelukkig kun je het in een cookie wel stoppen, want dat wordt niet meegesnifft. . Sorry, sarcasme-modus uit.

Dus blijft er niet veel anders over dan een session-id, danwel in een cookie danwel in het URL, heen en weer sturen.

Wat is er voor de gemiddelde scriptkiddie moeilijker? Een URL overtypen uit de sniffer of aan een request zelf met de hand een cookie toevoegen? Uiteraard is een cookie ook niet helemaal veilig, maar het is al een eerste drempel. En dat is ook het hele idee; als het geen noemenswaardige moeite kost om iets een klein beetje veiliger te maken moet je dat vooral doen. Dat je uiteindelijk voor echt veilige oplossingen over moet schakelen op dingen als SSL/HTTPS is een ander verhaal...

[bigbeng]

Nu ben ik benieuwd of de TS uberhaupt het idee heeft dat men hem in de goede richting helpt. Hij vroeg namelijk om documentatie over de voor- en nadelen van sessies (tijdelijke sessie is volgens mij een pleonasme).

En het topic verzandt vervolgens in 1 aspect van sessies, namelijk het beveiligen ervan. Tis wel een nadeel, maar is het het enige?

[Verwijderd]

Verwijderd schreef op 16 juli 2004 @ 12:55:

Wat zie jij als andere mogelijkheden dan? .. behalve zeggen "ga maar weg want je ondersteund geen cookies".

De methode die hier wordt voorgesteld wordt echt niet, niet voor niets heel erg veel gebruikt bij ook de grote sites. Je hebt ook geen andere keuze. Sessionid kun je gewoon in combinatie met vergaarde data op het moment van zetten goed beveiligen.

[ Voor 21% gewijzigd door Verwijderd op 16-07-2004 14:28 ]