Als een webapplicatie vóór en na het inloggen dezelfde sessie-ID blijft gebruiken, kan een aanvaller de gebruiker een vooraf door de aanvaller klaargemaakte sessie-ID laten gebruiken en zich na het inloggen van de gebruiker met die ID als de gebruiker voordoen. Wat is de meest geschikte tegenmaatregel tegen deze aanval?

Antwoord: B. Bij een geslaagde inlog een nieuwe sessie-ID uitgeven en de vorige ID ongeldig maken

Deze aanval heet session fixation. Een webapplicatie herkent een ingelogde gebruiker aan een sessie-ID die in een cookie of iets dergelijks wordt doorgegeven. Als een aanvaller de gebruiker vóór het inloggen een sessie-ID kan laten gebruiken die de aanvaller kent, en die ID na het inloggen in gebruik blijft, kan de aanvaller met dezelfde ID als de gebruiker toegang krijgen. De tegenmaatregel is op het moment van een geslaagde inlog een nieuwe, onvoorspelbare sessie-ID uit te geven en de oude ongeldig te maken. De ID die de aanvaller vóór het inloggen kende, wordt dan nutteloos. Aanvallen waarbij gebruikers worden nagebootst door sessie-ID's te stelen of te raden, heten in het algemeen session hijacking; ze worden bestreden met een combinatie van maatregelen zoals ID's voldoende lange willekeurige waarden maken, ze alleen via HTTPS versturen (het attribuut Secure van de cookie) en ze niet in URL's opnemen (waar ze gemakkelijk uitlekken via de Referer-header of de geschiedenis). Opeenvolgende ID's zijn gemakkelijk te raden en gevaarlijk.