Van de week heb ik de map waar de session cookies op de server bij mijn host worden opgeslagen gewijzigd naar een map waar ik zelf toegang toe heb (buiten de root). De reden hiervan was dat het heel soms gebeurd dat een session cookie corrupt raakt en je dan de helpdesk moet vragen de session te verwijderen voordat je door sessions beveiligde gedeelte van de website weer werkt. Nu kan ik dat in geval van nood zelf. (Dit gebeurd overigens alleen tijdens development, als er heel veel geupload en gerefreshed wordt, heb het nog nooit in een live omgeving meegemaakt of gezien) https://secure.servage.net/wiki/Session
Anyway, nu valt me het volgende op. Als ik een sessie verwijder met session_destroy(); dan wordt de session cookie helemaal leeg gemaakt, maar het bestandje zelf blijft wel staan. Hoort dat zo? Ik ging er altijd van uit dat bij session_destroy() gewoon alles verwijderd zou worden...
De permissies van de map waarin de session cookies opgeslagen worden staan op 777 en de eigenaar ben ik.
Hm, laat voorlopig maar weg dan. Er stond mij iets bij over state changes, maar als de state change tevens inhoudt dat de sessie beëindigd wordt dan is dat nogal loos wellicht ja.
Er stond mij iets bij over state changes, maar als de state change tevens inhoudt dat de sessie beëindigd wordt dan is dat nogal loos wellicht ja.
Dat is gewoon correct. Overschakelen van HTTP naar HTTP/S is zo'n state change. En overschakelen van anonieme bezoeker naar ingelogde gebruiker is er ook een.
Maar de hamvraag is daarom: heeft de uitgelogde gebruiker nog een sessie? Gebruik je ergens anders nog een session_start(), dan is het antwoord waarschijnlijk: ja. Wordt de sessie na het uitloggen niet beëindigd maar voortgezet met minder rechten, dan is ook dat een state change.
De uitgelogde gebruiker heeft geen sessie meer, zie mijn uitlog script een paar posts hierboven.
Hoewel hij na het uitloggen geredirect wordt naar de login pagina waar ik wel weer session_start gebruik. (maar dat staat los van de uitloggende gebruiker)
Hmmm... Ok. Maar nu weet ik nog niet of ik nu bij het uitloggen het session id moet regeneren. De session cookie is dus leeg gemaakt, de lifetime in het verleden gezet, en daarna een session_destroy().
Is die sessie dan nog steeds niet echt weg? En zou ik dus toch het session id moeten regeneren?
Potverdorie wat moet je doen om van een sessie af te komen ;)
>> Is die sessie dan nog steeds niet echt weg? En zou ik dus toch het session id moeten regeneren?
Waarom zou je het NIET doen? Het kan toch geen enkel kwaad?
Het regenereren van een ID doe je om een mogelijke session-hijacking te voorkomen.
Als Piets eerste session ID 'abc' heeft en na het regenereren 'xyz' dan is hij nog steeds gewoon gekoppeld aan hetzelfde sessiebestand. Het enige wat je doet is het een hacker lastig maken die het gemunt heeft op de sessie (het sessiebestand) met ID 'abc'.
Dus ... heel simpel. Maak gewoon de sessie leeg als iemand uitlogt.
$_SESSION = [];
Nu staat er niks zinvols meer in. En als je wilt kun je dan ook nog regenereren.
Waarom zou je het NIET doen? Het kan toch geen enkel kwaad?
Dat is waar. Ik zet hem er wel weer in...
ondertussen ga ik wel een beetje off-topic, sorry daarvoor.
In totaal zijn de sessies nu beveiligd op de volgende manier:
- de session-cookies worden ingesteld op httponly en op secure als die mogelijkheid er is
- de user agent en het ip adres worden opgeslagen als er iemand inlogt (gehashed samen met het wachtwoord)
- het session id word geregenereerd direct na inloggen, en daarna bij 20% van de session_starts
- bij het uitloggen wordt de sessie leeggemaakt, de lifetime in het verleden gezet, nogmaals geregenarate en dan gedestroyed
- de formulieren zijn voorzien van tokens die ik ook in een sessie opsla en direct na het controleren weer leegmaak.
Kan ik nog meer doen om de sessies te beveiligen of zit ik zo wel goed?
Als je het token niet weghaalt zou je het form de hele tijd kunnen her-submitten, wat het (mede)doel van het token (dubbelposts tegengaan) een beetje verslaat :). Het is goed dat deze meteen ongeldig/verwijderd worden na eenmalig gebruik.
Ik denk dat het pas weer uitmaakt dat het sessie id verandert (na leeggooien, destroy en het unsetten van het cookie) als je er weer spannende dingen mee gaat doen zoals inloggen. Maar je zei al dat je op dat moment regenerate. Daarnaast ben je je "link" met je sessie id kwijt doordat je het sessie-cookie weggooit.
In het ergste geval kaapt iemand een lege sessie ;-). Niet zo bijzonder boeiend lijkt mij. Maar het is een state change, da's waar :].
