Er zijn veel verschillende soorten beveiligingsproblemen op websites, een interessante heet "Session Fixation". Sessiefixatie is een probleem waarbij een aanvaller de sessie-ID, ook wel de sessie-ID van een gebruiker genoemd, kan beïnvloeden en deze vervolgens kan gebruiken om toegang te krijgen tot zijn account. Er zijn twee manieren waarop dit type kwetsbaarheid kan werken: het kan de aanvaller in staat stellen de sessie-ID van een andere gebruiker te vinden of in te stellen.
Hoe een sessiefixatie-aanval wordt uitgevoerd
De sessie-ID van een gebruiker is vaak een belangrijk onderdeel van de authenticatie van de website en is in veel gevallen de enige gegevens die de specifieke ingelogde gebruiker identificeren. Het probleem hiermee is dat als een aanvaller de sessie-ID van een andere gebruiker kan instellen of leren, hij de sessietoken kan gebruiken en vervolgens als gebruiker kan optreden.
Meestal wordt dit gedaan door een gebruiker te misleiden om op een type phishing-link te klikken. De link zelf is volledig legitiem, maar bevat een variabele die een gespecificeerde sessie-ID instelt. Als de gebruiker vervolgens inlogt met de sessie-ID en de server hem geen nieuwe sessie-ID toewijst op inloggen, kan de aanvaller eenvoudig zijn sessie-ID hetzelfde instellen en toegang krijgen tot die van het slachtoffer rekening.
Een andere manier waarop de aanvaller de sessie-ID van het slachtoffer kan ontdekken, is als deze in een URL wordt weergegeven. Als de aanvaller het slachtoffer bijvoorbeeld kan misleiden om hen een link te sturen en deze de sessie-ID van het slachtoffer bevat, kan de aanvaller de sessie-ID gebruiken om toegang te krijgen tot het account van het slachtoffer. In sommige gevallen kan dit volledig per ongeluk gebeuren. Als de gebruiker bijvoorbeeld de URL met de sessie-ID kopieert en deze naar een vriend of in een forum plakt, wordt elke gebruiker die de link volgt, aangemeld met het account van de gebruiker.
Oplossingen voor sessiefixatie
Er zijn een paar oplossingen voor dit probleem, en zoals altijd is de beste oplossing om zoveel mogelijk fixes te implementeren als onderdeel van een diepgaande verdedigingsstrategie. De eerste oplossing is om de sessie-ID van de gebruiker te wijzigen wanneer deze zich aanmeldt. Dit voorkomt dat een aanvaller ooit de sessie-ID van een ingelogde gebruiker kan beïnvloeden. U kunt de server ook configureren om alleen sessie-ID's te accepteren die hij heeft gegenereerd en om expliciet door de gebruiker verstrekte sessie-ID's te weigeren.
De website moet worden geconfigureerd om nooit gevoelige gebruikersgegevens zoals sessie-ID in de URL te plaatsen en moet deze in een GET- of POST-verzoekparameter plaatsen. Dit voorkomt dat de gebruiker per ongeluk zijn eigen sessie-ID compromitteert. Door zowel een sessie-ID als een afzonderlijk authenticatietoken te gebruiken, verdubbelt u de hoeveelheid informatie die de aanvaller nodig heeft om te verkrijgen en voorkomt u dat aanvallers toegang krijgen tot sessies met bekende sessie-ID's.
Het is essentieel dat alle geldige sessie-ID's voor een gebruiker ongeldig worden gemaakt wanneer op de uitlogknop wordt geklikt. Het is mogelijk om de sessie-ID bij elk verzoek opnieuw te genereren. Als eerdere sessie-ID's ongeldig worden gemaakt, voorkomt dit ook dat aanvallers bekende sessie-ID's gebruiken. Deze aanpak verkleint ook het dreigingsvenster aanzienlijk als een gebruiker zijn eigen sessie-ID bekendmaakt.
Door meerdere van deze benaderingen mogelijk te maken, kan een diepgaande verdedigingsstrategie dit probleem als veiligheidsrisico elimineren.