session cookies verwijderen
Je genereert toch een nieuw token bij ieder request?
Ozzie PHP op 16/02/2017 21:11:22:
>>> de user agent en het ip adres worden opgeslagen als er iemand inlogt (gehashed samen met het wachtwoord)
Dit kun je beter niet doen. Een IP-adres kan gedurende de sessie wijzigen.
Dit kun je beter niet doen. Een IP-adres kan gedurende de sessie wijzigen.
Dat kun je beter wél doen inclusief eventuele proxy. Hoewel een IP-adres inderdaad kan wijzigen, is het tijdens één sessie toch veel vaker vast dan variabel. Verandert een IP-adres (opnieuw een state change) als je bijvoorbeeld midden in een betaalproces zit, dan kan het toch wel verstandig zijn om de gebruiker zekerheidshalve opnieuw om een wachtwoord te vragen.
De combinatie $_SERVER['REMOTE_ADDR'] . $_SERVER['HTTP_USER_AGENT'] is zelfs zó uniek dat je er individuele internetgebruikers aan kunt herkennen.
Marlies Maalderink op 16/02/2017 20:05:28:
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?
- 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?
Ik zou er nog vier aan toevoegen:
- alles over SSL (anders is de sessie-ID uit HTTP-headers te hengelen);
- alleen HTTP-cookies gebruiken;
- een sterker hashalgoritme gebruiken (want MD5 is de standaardinstelling);
- de sessieduur voor kritieke applicaties verkorten tot 2 tot 5 minuten (vereist voor creditcardbetalingen bijvoorbeeld).
Ozzie PHP op 16/02/2017 21:11:22:
Gewoon zorgen dat er iedere keer als je het formulier aanroept een nieuwe token wordt gegenereerd.
Maar als je de verwerkstap rechtstreeks aanroept (zonder het formulier te herladen) dan staat de poort dus continu open als je het token niet elke keer invalideert in de verwerkstap.
(ik ga er hierbij vanuit dat we het over tokens hebben die CSRF zouden moeten voorkomen)
Thomas van den Heuvel op 17/02/2017 14:40:42:
Maar als je de verwerkstap rechtstreeks aanroept (zonder het formulier te herladen) dan staat de poort dus continu open als je het token niet elke keer invalideert in de verwerkstap.
(ik ga er hierbij vanuit dat we het over tokens hebben die CSRF zouden moeten voorkomen)
Ozzie PHP op 16/02/2017 21:11:22:
Gewoon zorgen dat er iedere keer als je het formulier aanroept een nieuwe token wordt gegenereerd.
Maar als je de verwerkstap rechtstreeks aanroept (zonder het formulier te herladen) dan staat de poort dus continu open als je het token niet elke keer invalideert in de verwerkstap.
(ik ga er hierbij vanuit dat we het over tokens hebben die CSRF zouden moeten voorkomen)
Idd, gaat om beveiliging tegen CSRF, dan is het toch wel handig om hem te verwijderen.
Thomas van den Heuvel op 17/02/2017 14:40:42:
In het ergste geval kaapt iemand een lege sessie ;-). Niet zo bijzonder boeiend lijkt mij. Maar het is een state change, da's waar :].
Nee precies. Het is wel een kwestie van 'het kan geen kwaad om het er toch tussen te zetten' maar ik ben sowieso niet zo dol op overbodige code.
Ward van der Put op 17/02/2017 08:37:37:
- alles over SSL (anders is de sessie-ID uit HTTP-headers te hengelen);
- alleen HTTP-cookies gebruiken;
- een sterker hashalgoritme gebruiken (want MD5 is de standaardinstelling);
- de sessieduur voor kritieke applicaties verkorten tot 2 tot 5 minuten (vereist voor creditcardbetalingen bijvoorbeeld).
- alles over SSL (anders is de sessie-ID uit HTTP-headers te hengelen);
- alleen HTTP-cookies gebruiken;
- een sterker hashalgoritme gebruiken (want MD5 is de standaardinstelling);
- de sessieduur voor kritieke applicaties verkorten tot 2 tot 5 minuten (vereist voor creditcardbetalingen bijvoorbeeld).
Ward dank je wel voor de tips. SSL gebruik ik nu niet maar moet er nog wel op. Kost 30 euro per jaar bij mijn host (stelt ook niets voor) maar wilde nog even uitzoeken hoe het zat met gratis certificaten want daar las ik laatst ook wat over.
Sessieduur verkorten is misschien wel handig om toe te voegen aan het inogsysteem zodat het er vast in zit en ik het aan kan zetten als het in de toekomst wel eens nodig is! Heb ik er dan geen werk meer van...
Wachtwoorden in de database hash ik met Bcrypt, de gehaste sessie variabelen met sha512.
Gewijzigd op 17/02/2017 15:06:38 door Marlies Maalderink
Marlies Maalderink op 17/02/2017 15:06:10:
Ward dank je wel voor de tips. SSL gebruik ik nu niet maar moet er nog wel op. Kost 30 euro per jaar bij mijn host (stelt ook niets voor) maar wilde nog even uitzoeken hoe het zat met gratis certificaten want daar las ik laatst ook wat over.
Ward dank je wel voor de tips. SSL gebruik ik nu niet maar moet er nog wel op. Kost 30 euro per jaar bij mijn host (stelt ook niets voor) maar wilde nog even uitzoeken hoe het zat met gratis certificaten want daar las ik laatst ook wat over.
Dat is LetsEncrypt, en werkt eigenlijk best wel makkelijk. Ik weet niet welk controlepaneel je bij je hosting hebt, maar de meesten ondersteunen Lets Encrypt inmiddels wel. Dan kan je in no-time een gratis SSL-certificaat aanvragen en die wordt dan meteen voor je geconfigureerd. Op deze manier kan ik via DirectAdmin op gebruikersniveau in ongeveer halve minuut een domein voorzien van een mooi groen slotje. Uiteraard moet het wel in DirectAdmin aan staan. Dergelijke certificaten zijn maar 3 maanden geldig, maar met een cronjob kan je dit her-activeren eenvoudig automatiseren. Zelfs DirectAdmin kan dat.
Ward van der Put op 17/02/2017 08:37:37:
Dat kun je beter wél doen inclusief eventuele proxy. Hoewel een IP-adres inderdaad kan wijzigen, is het tijdens één sessie toch veel vaker vast dan variabel.
Ozzie PHP op 16/02/2017 21:11:22:
>>> de user agent en het ip adres worden opgeslagen als er iemand inlogt (gehashed samen met het wachtwoord)
Dit kun je beter niet doen. Een IP-adres kan gedurende de sessie wijzigen.
Dit kun je beter niet doen. Een IP-adres kan gedurende de sessie wijzigen.
Dat kun je beter wél doen inclusief eventuele proxy. Hoewel een IP-adres inderdaad kan wijzigen, is het tijdens één sessie toch veel vaker vast dan variabel.
Mja, daar kun je dus over discussiëren. De vraag is dan in welk geval je er iets mee doet. Tegenwoordig is het helemaal niet meer vreemd dat een IP-adres wijzigt tijdens een sessie. Denk bijv. maar aan mensen die in de trein of auto zitten van of naar hun werk. Tegenwoordig is een IP-adres (helaas) geen vast gegeven meer. Het is bijzonder vervelend als je tijdens je treinrit continu wordt uitgelogd omdat je IP-adres wisselt, of dat daardoor je aankoop mislukt.
Thomas van den Heuvel op 17/02/2017 14:40:42:
Maar als je de verwerkstap rechtstreeks aanroept (zonder het formulier te herladen) dan staat de poort dus continu open als je het token niet elke keer invalideert in de verwerkstap.
(ik ga er hierbij vanuit dat we het over tokens hebben die CSRF zouden moeten voorkomen)
Ozzie PHP op 16/02/2017 21:11:22:
Gewoon zorgen dat er iedere keer als je het formulier aanroept een nieuwe token wordt gegenereerd.
Maar als je de verwerkstap rechtstreeks aanroept (zonder het formulier te herladen) dan staat de poort dus continu open als je het token niet elke keer invalideert in de verwerkstap.
(ik ga er hierbij vanuit dat we het over tokens hebben die CSRF zouden moeten voorkomen)
Ik snap wat je bedoelt. Als het een losse stap is, is dat inderdaad het geval. Bij mij zit het iets anders in elkaar waardoor dat niet gebeurt, maar ik snap wat je bedoelt.
Ozzie PHP op 17/02/2017 16:07:32:
Mja, daar kun je dus over discussiëren. De vraag is dan in welk geval je er iets mee doet. Tegenwoordig is het helemaal niet meer vreemd dat een IP-adres wijzigt tijdens een sessie. Denk bijv. maar aan mensen die in de trein of auto zitten van of naar hun werk. Tegenwoordig is een IP-adres (helaas) geen vast gegeven meer. Het is bijzonder vervelend als je tijdens je treinrit continu wordt uitgelogd omdat je IP-adres wisselt, of dat daardoor je aankoop mislukt.
Ward van der Put op 17/02/2017 08:37:37:
Dat kun je beter wél doen inclusief eventuele proxy. Hoewel een IP-adres inderdaad kan wijzigen, is het tijdens één sessie toch veel vaker vast dan variabel.
Ozzie PHP op 16/02/2017 21:11:22:
>>> de user agent en het ip adres worden opgeslagen als er iemand inlogt (gehashed samen met het wachtwoord)
Dit kun je beter niet doen. Een IP-adres kan gedurende de sessie wijzigen.
Dit kun je beter niet doen. Een IP-adres kan gedurende de sessie wijzigen.
Dat kun je beter wél doen inclusief eventuele proxy. Hoewel een IP-adres inderdaad kan wijzigen, is het tijdens één sessie toch veel vaker vast dan variabel.
Mja, daar kun je dus over discussiëren. De vraag is dan in welk geval je er iets mee doet. Tegenwoordig is het helemaal niet meer vreemd dat een IP-adres wijzigt tijdens een sessie. Denk bijv. maar aan mensen die in de trein of auto zitten van of naar hun werk. Tegenwoordig is een IP-adres (helaas) geen vast gegeven meer. Het is bijzonder vervelend als je tijdens je treinrit continu wordt uitgelogd omdat je IP-adres wisselt, of dat daardoor je aankoop mislukt.
Daar moest ik inderdaad wel aan denken, op een mobiele telefoon wippen mensen nauurlijk van het ene naar het andere wifi netwerk. Misschien gewoon een beetje per situatie beoordelen. Ik laat het er nu in ieder geval in staan, maar als de situatie het verlangd zou het er uit kunnen. Vind het toch wel prettig om het er in te hebben.
Ward, nou, beetje een domper. Mijn host heeft een eigen control panel.
Dan houdt het op. Ze ondersteunen LetEncrypt ook niet. Ze bieden zelf gratis gebruik van SSL certificaten aan, maar als je die gebruikt kun je niet tegelijkertijd ook je domeinnaam gebruiken. Ik heb dat gisteren al nagevraagd. In plaats van je eigen domeinnaam kijg je dan zoiets: https://a3652ffd.servage-customer.net Das ook niet echt fraai. Dan toch eerdaags maar even een certificaat kopen...
Ozzie PHP op 17/02/2017 16:07:32:
Mja, daar kun je dus over discussiëren. De vraag is dan in welk geval je er iets mee doet.
Jij gebruikt zelf al maanden hetzelfde IP-adres, dus daar kunnen we inderdaad over discussiëren. ;-)
Het is gebruikelijk dat je een IP-adres in elk geval logt bij de log-in, in de sessie zelf of voor langere tijd in een database. (Bij bedrijfskritieke applicaties log je zelfs alles.) Als jij ineens vanaf een ander IP-adres een groot bedrag naar het buitenland zou willen overmaken, dan denk ik dat ik je even zou bellen, als ik jouw bank was...
Dat sommige gebruikers geen vast IP-adres hebben, wil nog niet zeggen dat je niets kunt doen met/voor de gebruikers die wél een vast IP-adres hebben. Sterker nog, voor streng beveiligde applicaties gebruiken we zelfs een white list: staat je IP-adres niet op de lijst, dan kom je er niet in.
Of op zoek naar een andere host ;-)
>> Jij gebruikt zelf al maanden hetzelfde IP-adres, dus daar kunnen we inderdaad over discussiëren. ;-)
Correct, en velen met mij. Maar ik representeer helaas niet alle internetgebruikers :-) En ja, er zijn er dus ook een hele hoop die op en neer rijden terwijl ze surfen. Het lijkt me wel iets om mee rekening te houden. Het regenereren van een sessie ID bij een wisselend IP-adres is geen probleem, maar iemand uitloggen kan wel degelijk een probleem zijn.
Uhm... Je hebt toch een VPS?
Anders heb ik het helemaal mis hoor.
Maar mocht het zo zijn, dan is Let's encrypt harstikke makkelijk.
Je moet even dit lezen: https://letsencrypt.org/getting-started/
Ik weet niet welke distro je gebruikt maar daar hebben ze een super handige oplossing voor:
https://certbot.eff.org/
Nog even alles aan elkaar knopen in je apache config dat het aan je domein zit, en klaar ben je. ;)
Gewijzigd op 17/02/2017 20:56:34 door Marlies Maalderink