Tijden veranderen
ingelogd blijven
Tips?
Ook raad ik aan om deze gemaakte inlogsessie te fixeren op een IP-adres, zodat je inlogpoging dubbel zo veilig is, ook al jatten ze je cookie via XSS (wat je sowieso wilt voorkomen), maar ook bij cookies kan je gebruik maken van Secured Cookies wat het veiliger maakt. En misschien kan je zelfs wat doen met 'browser-fingerprinting'.
Voegt een cookie met user id nog iets toe? Alleen maar informatie om hackers mee te voeden, toch?
Ik zie trouwens dat phphulp 2 cookies opslaan, 1 met sessie id en 1 met IP. Als ik echter mijn IP wissel, blijf ik gewoon ingelogd. In de manier zoals ik het omschrijf, zal dat nooit gebeuren lijkt me. En meer dan het IP adres heb ik niet om op te gaan. Ik kan niet het Mac address achterhalen bijv.
In plaats van een cookie kun je ook een (vrij lang) ID in de localStorage opslaan. Op het moment dat je dan redirect naar de loginpagina controleer je met javascript dit token, en als het correct is (bestaat in de database) redirect je meteen weer door naar de pagina waar de gebruiker in eerste instantie naar toe wilde. Hierdoor hoeft dit (vrij lange) token niet bij elke request meegestuurd te worden (zo werken cookies namelijk).
Nadat het "sessie token" is gebruikt om opnieuw te authenticeren kun je evt. een nieuw token uitdelen, zodat een "blijf ingelogd" token maar 1x kan worden gebruikt.
Voor extra veiligheid kun je bijvoorbeeld wel controleren waar het IP-adres precies vandaan komt ( https://dev.maxmind.com/geoip/geolite2-free-geolocation-data?lang=en ). Als dat opeens "een ander land" is laat je de gebruiker alsnog opnieuw inloggen.
localStorage is ook minder hackgevoelig?
Het nadeel van een cookie is dat ie bij _elke_ request wordt meegestuurd (ook als je al lang en breed bent ingelogd) = overhead. Ook is de omvang van een cookie (van alle cookies samen) vaak beperkt (in de localStorage is meer ruimte), en is het dus zonde om die beperkte ruimte te besteden aan iets wat je maar 1x per sessie nodig hebt.
Ondertussen sta ik nog open voor andere ideeën.
Veur Heur op 15/04/2022 09:33:25:
... maar is het dan niet mogelijk zelf een cookie te maken met die id om vervolgens ingelogd te zijn namens die gebruiker?
Je wilt terecht waken voor "session hijacking", er zijn verschillende technieken voor.
De hele wereld werkt met willekeurige sessie ID's, die per sessie worden gegenereerd en alleen via HTTPS (via de HTTP-header) wordt meegegeven op zo'n manier dat je er niet bij kunt via JavaScript, dat is voor de veiligheid.
Dus:
- je verbindt met een HTTPS site
- je geeft je account en wachtwoord
- je controleert of het klopt en maakt een sessie ID die cryptografisch sterk is
- je geeft een nieuwe pagina met een cookie met die sessie ID
- bij elke nieuwe pagina controleer je of de sessie ID in de tijdelijke opslag (in een map of database) bestaat, daarmee is de gebruiker 'ingelogd'
- je houdt een verlooptijd bij, dat bijvoorbeeld de sessie verloopt bij 15 minuten inactiviteit
Voor het hele plaatje moet je hier kijken:
https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
Als je sessies wilt gebruiken kan je 3 dingen doen:
- de vanille sessie functies gebruiken van PHP
- eventueel de SessionHandlerInterface implementeren om de database te gebruiken (veiliger dan /tmp)
- zelf sessiebeheer schrijven (wanneer je voldoende tijd hebt is dat het meest leerzaam)
Als je het nog uitgebreider wilt kan je sessiebeheer aan je database over laten, zodat je geen applicatie-account op je database nodig hebt. Met PostgreSQL functies met de optie SECURITY DEFINER kan je sessiefuncties maken zodat elke gebruiker z'n eigen databaseaccount heeft. Het voordeel is dat je autorisaties van elke gebruiker ook door de database kan laten doen. Het scheelt heel erg veel PHP code als je het op deze manier doet, maar er moet bij worden gezegd dat het niet de meest ideale situatie is voor gewone, niet al te ingewikkelde publieke websites.