Det finnes mange forskjellige typer sikkerhetssårbarheter på nettsteder, en interessant kalles "Session Fixation". Sesjonsfiksering er et problem der en angriper kan påvirke øktidentifikatoren, også kjent som økt-ID-en til en bruker, og deretter bruke den til å få tilgang til kontoen sin. Det er to måter denne typen sårbarhet kan fungere på, den kan tillate angriperen å enten finne eller angi økt-IDen til en annen bruker.
Hvordan et øktfikseringsangrep utføres
Sesjons-IDen til en bruker er ofte en sentral del av autentiseringen til nettstedet og er i mange tilfeller de eneste dataene som identifiserer den spesifikke brukeren som er logget på. Problemet med dette er at hvis en angriper kan angi eller lære økt-IDen til en annen bruker, kan de bruke økttokenet og deretter kunne fungere som brukeren.
Vanligvis gjøres dette ved å lure en bruker til å klikke på en type phishing-lenke. Selve koblingen er helt legitim, men inkluderer en variabel som angir en spesifisert sesjons-ID. Hvis brukeren deretter logger på med økt-IDen og serveren ikke tildeler dem en ny sesjons-ID på pålogging, kan angriperen ganske enkelt stille inn økt-ID-en til å være den samme og ha tilgang til offerets regnskap.
En annen måte angriperen kan oppdage offerets sesjons-ID på, er hvis den vises i en URL. For eksempel, hvis angriperen kan lure offeret til å sende dem en lenke og den inkluderer offerets sesjons-ID, kan angriperen bruke sesjons-IDen for å få tilgang til offerets konto. I noen tilfeller kan dette skje helt ved et uhell. For eksempel, hvis brukeren kopierer URL-en med økt-ID-en og limer den inn til en venn eller i et forum, vil enhver bruker som følger koblingen bli logget på med brukerens konto.
Utbedring av sesjonsfiksering
Det er noen få løsninger på dette problemet, og som alltid er den beste løsningen å implementere så mange rettelser som mulig som en del av en dybdeforsvarsstrategi. Den første løsningen er å endre brukerens økt-ID når de logger på. Dette forhindrer at en angriper noen gang kan påvirke økt-ID-en til en pålogget bruker. Du kan også konfigurere serveren til å bare akseptere sesjons-IDer som den har generert, og eksplisitt avvise alle brukeroppgitte sesjons-IDer.
Nettstedet bør konfigureres til aldri å plassere noen sensitive brukerdetaljer som økt-ID i URL-en og bør plassere den i en GET- eller POST-forespørselsparameter. Dette forhindrer brukeren i å kompromittere sin egen økt-ID ved et uhell. Ved å bruke både en sesjons-ID og en separat autentiseringstoken dobler du mengden informasjon angriperen trenger for å få og forhindrer angripere fra å få tilgang til økter med kjente sesjons-IDer.
Det er viktig at alle gyldige sesjons-ID-er for en bruker blir ugyldig når du klikker på utloggingsknappen. Det er mulig å regenerere økt-ID-en på hver forespørsel, hvis tidligere økt-ID-er er ugyldig, forhindrer dette også angripere fra å bruke kjente økt-ID. Denne tilnærmingen reduserer også trusselvinduet betydelig hvis en bruker avslører sin egen økt-ID.
Ved å aktivere flere av disse tilnærmingene, kan en dybdeforsvarsstrategi eliminere dette problemet som en sikkerhetsrisiko.