Qua beveiliging van sessions zijn er in feite 2 delen die ge moet onderscheiden: de server-side en de client-side, waarbij de client-side veruit de belangrijkste is.
Aan de client-side wordt de session ID zoals al vermeld meegegeven via de URL of via een cookie. Een eerste checkpoint is al om ervoor te zorgen dat de session ID altijd via een cookie wordt meegegeven en nooit via een URL wegens veel te onveilig. Voor alle zekerheid kunt ge dat afdwingen met
PHP:
ini_set('session.use_trans_sid', 0);
ini_set('session.use_only_cookies', 1);
Ten tweede moet ge voorkomen dat de cookies van uw users gestolen worden. Het stelen van cookies gebeurt meestal via zogenaamde XSS exploits; dat komt erop neer dat iemand erin slaagt om een stukje Javascript (dat ze uiteraard zelf geschreven hebben) op uw site te laten uitvoeren. Aangezien ge via Javascript aan cookies kunt en de code vanop uw site wordt uitgevoerd, kan de cookie zo effectief gestolen worden, en dus ook de bijhorende session.
De boodschap is dus: XSS voorkomen, en dat is ook nog eens een categorie op zich. De vuistregel om XSS te voorkomen is ervoor te zorgen dat alle user input op uw site geëscaped wordt alvorens in de HTML te worden weergegeven. Met andere woorden, als ik als comment <script>alert('yu');</script> ingeef, mag dat niet als <script>alert('yu');</script> in de HTML komen te staan want dan hebt ge dus effectief een XSS-injection aan uw been. Om de user input te escapen voor HTML kunt ge gebruik maken van
http://www.php.net/manual/en/function.htmlentities.php. Let er goed op dat je dit consequent toepast. Er zijn eigelijk zelden plaatsen waar ge dit
niet moet toepassen, de voornaamste waarschijnlijk het weergeven van WYSIWYG-input (maar die input komt meestal toch van trusted users).
Sedert kort ondersteunen browsers trouwens ook cookies die gemarkeerd zijn als HTTP-only, maw. dat ze enkel nog via HTTP verstuurd worden en niet meer via Javascript kunnen gelezen worden. Als er dan toch XSS mogelijk is, dan kunnen ze in sommige gevallen toch nog de cookie niet lezen. Vanaf PHP 5.2.0 kun je dergelijke cookies aanvragen met
PHP:
ini_set('session.cookie_httponly', 1);
Dat zijn zowat de grootste gevaren waar ge voor moet uitkijken. Er zijn er nog een pak meer, maar dat wordt een beetje te lang om hier uit te leggen. Zoek zeker eens op Google naar onderwerpen als session hijacking, ik herinner mij ooit eens een PDF gelezen te hebben met een duidelijke uitleg van de verschillende soorten session-hijacking. Zo is het bijvoorbeeld belangrijk om telkens als er van userlevel gewisseld wordt (dus telkens als een user inlogt, naar de admin-panel gaat, etc) hem telkens opnieuw te authenticeren (ie. opnieuw laten inloggen). Lees ook zeker eens
dit artikel (inclusief comments), ik dacht dat ik die PDF via dat artikel had gevonden. Het kan zeker ook geen kwaad om de andere artikels ook eens door te nemen, staat heel interessante informatie in.
Aan de kant van de server is er eigenlijk alleen maar een probleem als ge op een shared server werkt. Standaard komen PHP's sessions namelijk in /tmp terecht, en onder bepaalde omstandigheden is het dan mogelijk dat elke site op die server via PHP andermans session ids en soms zelfs data kan lezen. Toegegeven, 't is enigszins ver gezocht, maar het is zeker niet onmogelijk en er moet rekening mee gehouden worden waar nodig. Een alternatief is het session save path veranderen naar een directory die niet voor iedereen toegankelijk is (via
session.save_path), of de sessions in een database opslaan (zie shiflett.org).
Om op uw vraag te antwoorden: de session data wordt opgeslaan in
geserialiseerde vorm (of toch een lichte variant ervan) in gewone tekstbestanden. Die data moet dus elke keer ge-unserialized worden telkens er een ingelogde users een request maakt, en
unserializen staat er niet bepaald om bekend snel te verlopen. Best dus geen al te grote hoeveelheden data in uw sessions opslaan, maar ge moet er nu ook weer geen schrik van hebben ze. Onder groot verstaan we arrays van 20.000 entries en dergelijke, geen 5 login variabelkes.
.
.
