Wanneer wordt sessie cookie weggeschreven?
Pagina: « vorige 1 2 3 volgende »
Code (php)
1
2
3
4
5
6
2
3
4
5
6
<?php
$_SESSION = array();
session_destroy();
session_start();
session_regenerate_id();
?>
$_SESSION = array();
session_destroy();
session_start();
session_regenerate_id();
?>
Deze code vernietigde de huidige sessie en maakte een nieuwe aan met een nieuw id.
Nu heb ik 'm vervangen door:
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
<?php
$_SESSION = array();
session_destroy();
$session_name = session_name();
if (isset($_COOKIE[$session_name])) {
$session_cookie_parameters = session_get_cookie_params();
setcookie($session_name, false, $session_cookie_parameters['lifetime'], $session_cookie_parameters['path'], $session_cookie_parameters['domain'], $session_cookie_parameters['secure']);
}
?>
$_SESSION = array();
session_destroy();
$session_name = session_name();
if (isset($_COOKIE[$session_name])) {
$session_cookie_parameters = session_get_cookie_params();
setcookie($session_name, false, $session_cookie_parameters['lifetime'], $session_cookie_parameters['path'], $session_cookie_parameters['domain'], $session_cookie_parameters['secure']);
}
?>
Deze code vernietigt ook de huidige sessie evenals de cookie (indien die geset is). Er wordt nu dus geen nieuwe sessie meer gestart. Op het moment dat ik nu een nieuwe sessie aanmaak krijg ik ook automatisch een nieuwe id. Het lijkt allemaal goed te werken.
Toevoeging op 16/12/2010 13:06:09:
Ik ben zelf bezig met een framework waarin standaard een sessie wordt gestart. Nu vraag ik me af wat wijsheid is. Stel dat iemand geen cookies accepteert, dan kun je A) een melding tonen dat hij / zij cookies moet inschakelen omdat de site anders niet werkt B) de sessie id via de url meesturen.
Optie B lijkt me vanwege veiligheidsrisico's niet echt wenselijk. Optie A is echter ook vrij drastisch. Wat is de beste oplossing?
Gewijzigd op 16/12/2010 13:07:03 door Ozzie PHP
Maar goed, als jij login hebt, en ze proberen dat, worden ze elke keer weer uitgelogd nadat ze zijn 'ingelogd' simpel omdat er geen sessie's zijn gestart. Maar ik vraag me af hoeveel % van de internetgebruiker geen sessie's toestaat.
Een gemiddeld persoon maak gebruik van een email client op het web. Daarvoor zijn ook sessie's nodig. Als sessie's uitstaan moet je denk ik gelijk rekening mee houden dat er mensen met verkeerde bedoelingen op je site zitten. Want, als je het namelijk slecht gescript hebt, wat ik overigens niet van je verwacht hoor, en je controleert niet of een sessie is gezet of waarde bevat kan die kwaadwillige persoon weer 'extra' dingen op jouw. Maar goed, ik zou als ik jouw was jezelf er niet te veel druk om maken.
Gewijzigd op 16/12/2010 13:23:46 door Niels K
Waarom geef je daar trouwens de voorkeur voor, boven de al eerder door mij aangegeven code?
$_SESSION = array();
session_destroy();
if( isset($_COOKIE[session_name()]) ) {
//setcookie(session_name(),'',time()-42000,'/');
}
Dit kun je doen door, de code tags om je code heen te zetten. Gelijk heb je overigens dat knopjes bij het plaatsen van een reactie niet overbodig zullen zijn. Maak anders hiervoor een topic aan in de plaats die daarvoor bestemd is?
EDIT.
BB parser werkt niet meer.. of werkt niet goed? bij ignore
Gewijzigd op 16/12/2010 13:38:31 door Niels K
de code die ik gebruik past volgens mij ook alle parameters aan of iets dergelijks. Hij stond exact zo op php.net
Code (php)
1
test code tags
Ah, met rechte blokcodes dus
Maar toen ik dit onderwerp opende heb ik de code ook niet in zo'n netjes blokje geplaatst in toelichting in vakje 3. Nu weet ik dus wel hoe het moet.
Gewijzigd op 16/12/2010 13:54:29 door Ellen P
Code (php)
1
2
3
2
3
<?*php
*?>
*?>
zonder de st*rretjes
Als je je echt zorgen maakt over beveiliging moet je over naar SSL, maar voor een gewone website, ook een webwinkel winkelmandje, is het gebruik van een voldoende lang en willekeurig sessie id prima. Tot aan de opgave van persoonlijke gegevens en de betaling tenminste.
Over dat SSL ben ik het niet met je eens, je krijgt dan alleen een beveiligde verbinding. Als je script nog steeds lek als een mandje is door SQL, XXS injecties kan je site nog steeds naar galemoeren worden geholpen.
F Loogman op 16/12/2010 14:08:20:
Als je het sessie_id in de URL meegeeft dat is dat normaal gesproken geen bijzonder security risico.
Het risico is wel hoger, want als iemand met een sniffer programma jouw url met sessie id tegenkomt, kan ie jouw sessie kapen / overnemen.
Gewijzigd op 16/12/2010 14:16:55 door Ozzie PHP
Ozzie PHP op 16/12/2010 14:16:36:
Het risico is wel hoger, want als iemand met een sniffer programma jouw url met sessie id tegenkomt, kan ie jouw sessie kapen / overnemen.
F Loogman op 16/12/2010 14:08:20:
Als je het sessie_id in de URL meegeeft dat is dat normaal gesproken geen bijzonder security risico.
Het risico is wel hoger, want als iemand met een sniffer programma jouw url met sessie id tegenkomt, kan ie jouw sessie kapen / overnemen.
Een sniffer leest ook de headers wel mee, het risico zit meer in logs die te lezen.
Ook heb zit het probleem in het kopieren van een url uit de browser naar een forum o.i.d. Hierbij moet je verder je sessie beveiligen wat toch al moet.
TJVB tvb op 16/12/2010 14:22:03:
Een sniffer leest ook de headers wel mee, het risico zit meer in logs die te lezen.
Ook heb zit het probleem in het kopieren van een url uit de browser naar een forum o.i.d. Hierbij moet je verder je sessie beveiligen wat toch al moet.
Ook heb zit het probleem in het kopieren van een url uit de browser naar een forum o.i.d. Hierbij moet je verder je sessie beveiligen wat toch al moet.
Bedoel je dat iemand met sniffer software gewoon de sessie_id ziet staan?
Pagina: « vorige 1 2 3 volgende »