PHP sessions zorgen ervoor dat een website gebruikersgegevens kan onthouden tussen paginaverzoeken, zoals een login-status of winkelwagentje. Standaard instellingen zijn echter niet altijd veilig genoeg voor productieomgevingen. In dit artikel lees je hoe sessions werken, welke php.ini-instellingen belangrijk zijn, en met welke concrete maatregelen je sessions beschermt tegen hijacking en fixation.
Hoe PHP sessions werken
Wanneer een bezoeker een website bezoekt die sessions gebruikt, maakt PHP een uniek session-ID aan. Dit ID wordt meestal opgeslagen in een cookie (PHPSESSID) bij de bezoeker en gebruikt om bijbehorende gegevens op de server terug te vinden, bijvoorbeeld in een bestand of database. Bij elk volgend verzoek stuurt de browser dit cookie mee, zodat de server weet welke sessiegegevens horen bij welke bezoeker.
Het probleem ontstaat wanneer dit session-ID wordt onderschept of geraden. Een aanvaller die het ID bemachtigt, kan zich voordoen als de ingelogde gebruiker zonder wachtwoord nodig te hebben. Goede configuratie van sessions is daarom net zo belangrijk als een sterk wachtwoordbeleid.
Belangrijke php.ini instellingen
De volgende instellingen in php.ini (of in een .user.ini-bestand bij shared hosting) bepalen hoe veilig sessions werken:
session.cookie_httponly = 1– voorkomt dat JavaScript bij het sessiecookie kan, wat cross-site scripting (XSS) minder gevaarlijk maakt.session.cookie_secure = 1– zorgt dat het cookie alleen via HTTPS wordt verstuurd, nooit onversleuteld.session.cookie_samesite = StrictofLax– beperkt het meesturen van het cookie bij verzoeken vanaf andere sites en vermindert CSRF-risico’s.session.use_strict_mode = 1– voorkomt dat PHP een door de aanvaller verzonnen session-ID accepteert.session.gc_maxlifetime– bepaalt hoe lang een inactieve sessie geldig blijft voordat deze wordt opgeruimd.session.name– wijzig de standaardnaam PHPSESSID naar iets unieks, zodat automatische scantools minder makkelijk herkennen welke techniek je gebruikt.
Sessions beveiligen tegen hijacking en fixation
Naast php.ini-instellingen zijn er maatregelen die je in je eigen applicatiecode doorvoert:
Regenereer het session-ID na login
Roep direct na een succesvolle login session_regenerate_id(true) aan. Dit voorkomt session fixation, waarbij een aanvaller een bezoeker vooraf een vast session-ID laat gebruiken.
Controleer het IP-adres en user-agent
Sla bij het starten van een sessie het IP-adres en de user-agent op en vergelijk deze bij elk verzoek. Bij een onverwachte wijziging kun je de sessie laten verlopen.
Stel een redelijke time-out in
Laat sessies na een periode van inactiviteit automatisch verlopen, zowel via session.gc_maxlifetime als een eigen tijdstempel-controle in de code.
Vernietig sessies correct bij uitloggen
Gebruik session_unset(), session_destroy() en verwijder het cookie expliciet, zodat er geen restgegevens achterblijven.
Forceer altijd HTTPS
Zonder geldig SSL-certificaat kan een sessiecookie worden onderschept op onbeveiligde verbindingen. Zorg dat je site alleen via HTTPS bereikbaar is.
Sessions configureren in Plesk
Bij hosting met Plesk kun je per domein aangepaste PHP-instellingen doorvoeren via de PHP-settings van het abonnement, of via een eigen php.ini in de hosting-instellingen. Zo kun je per website andere waarden voor cookie_secure, cookie_samesite of gc_maxlifetime instellen zonder de serverbrede configuratie aan te passen. Op NVMe-opslag met LiteSpeed verwerk je deze instellingen direct, zonder noemenswaardige vertraging voor bezoekers.
Twijfel je of je huidige hostingomgeving goede PHP-beveiliging ondersteunt? Bekijk de mogelijkheden van webhosting met vaste prijzen en gratis SSL, of lees hoe overstappen naar Tandata werkt als je sessiebeveiliging nu niet goed is geregeld.
Veelgestelde vragen
Waarom werken mijn sessions niet na het instellen van cookie_secure?
Als je site nog via HTTP in plaats van HTTPS draait, wordt het cookie niet verstuurd zodra cookie_secure aanstaat. Controleer of je SSL-certificaat actief en geldig is.
Is het gebruik van sessions veiliger dan JWT-tokens?
Beide hebben voor- en nadelen. Sessions zijn makkelijker serverzijdig in te trekken, terwijl JWT-tokens stateless zijn. Voor de meeste reguliere websites zijn goed geconfigureerde sessions voldoende veilig.
Hoe lang moet ik session.gc_maxlifetime instellen?
Dit hangt af van je toepassing. Voor een webshop of informatieve site volstaat vaak een kortere levensduur, terwijl een dashboard waar gebruikers lang ingelogd blijven een langere waarde kan gebruiken.
Kan ik sessiebestanden ook opslaan in een database?
Ja, met een eigen session handler kun je sessiedata in bijvoorbeeld MySQL opslaan in plaats van bestanden. Dit is handig bij load balancing over meerdere servers.
Waar vind ik meer informatie over serverinstellingen?
In de kennisbank staan meer artikelen over PHP-configuratie, SSL en serverbeheer.
Conclusie
Goed geconfigureerde PHP sessions beschermen gebruikersgegevens tegen hijacking en fixation. Zorg voor de juiste php.ini-instellingen, regenereer session-ID’s na login, forceer HTTPS en vernietig sessies correct bij uitloggen. Met de juiste hostingomgeving pas je deze instellingen eenvoudig toe zonder concessies aan snelheid.