Jag drog in åtkomsten men hen är kvar därinne: en session är inte samma sak som en behörighet

Du tog bort en användares behörighet. Kanske stängde du av kontot helt. Sedan märker du att personen fortfarande kan göra saker.

Ingenting är trasigt. Att logga in och att vara behörig är två skilda ögonblick, och mellan dem finns ett glapp.

Inloggningen sker en gång, behörigheten frågas varje gång

När du loggar in räcker systemet dig en biljett. Biljetten säger: den här personen har bevisat vem hen är, och den här biljetten gäller till en viss tidpunkt.

Behörighet är en egen fråga som ställs om vid varje förfrågan. Men i praktiken tar många system vid inloggningen en kopia av behörighetskartan, för snabbhetens skull, och använder den kopian ett tag.

Härur uppstår två fördröjningar.

Den första: när du tar bort en behörighet kan en öppen session fortsätta bära den kopian. Ändringen når den först när sessionen förnyas.

Den andra, och viktigare: att radera eller stänga av användaren river inte sönder biljetten hen håller. Biljetten är självbärande och gäller tills den går ut.

Regeln: att dra in åtkomst är inte att avsluta en session

Detta är två skilda handlingar, och att bara göra den första lämnar ett fönster öppet bakom dig.

Fönstret är inte oändligt; en biljett gäller inte ett dygn. Men det är inte heller noll, och i ett brådskande läge räcker inte svaret "det stängs snart".

När någon slutar, eller ett lösenord är misstänkt

Gör tre saker, i ordning.

Ta bort behörigheten. Stäng av kontot också om det är befogat.

Byt lösenordet. Det stänger vägen att hämta en färsk biljett i stället för den hen har. Att bara ta bort en behörighet gör inte det.

Ta bort åtkomsttokenen separat. Det är steget som oftast hoppas över. En token är inte en session: den går inte ut av sig själv, den lever tills du raderar den. Att byta en användares lösenord ogiltigförklarar inte hens token. När du tar bort en användare, kontrollera separat vad som blev av tokenen.

Och låt oss avliva ett missförstånd: tvåstegsverifiering hjälper dig inte här. Den skyddar inloggningsögonblicket. Om en redan öppen session har den ingenting att säga.

Motsatt riktning: varför loggas jag ut hela tiden

Det är den andra sidan av samma mekanism.

Biljetten har begränsad livslängd, och gränssnittet förnyar den regelbundet så länge du är kvar på fliken. Stäng fliken och kom tillbaka timmar senare: ingen förnyelse har skett, biljetten är död, och du ombeds logga in igen. Det är inget fel.

Den andra, mindre kända orsaken är intressantare: maskinens klocka. En biljett bär en tidsstämpel. Om serverns klocka driver kan en nyss utfärdad biljett se ut att komma från framtiden eller vara sedan länge utgången. Symptomet förvirrar: lösenordet stämmer, inloggningen verkar accepteras, och strax därefter faller sessionen. Att leta efter ett klockproblem på identitetssidan faller ingen in, men leta.

Vad Atlas gör

I Atlas är kakan som går till webbläsaren inte den riktiga biljetten. Webbläsaren bär bara en meningslös slumpmässig identitet; själva biljetten stannar på servern.

Skillnaden är konkret: även om ett webbläsarhål läser kakan får det inte tag i biljetten själv, alltså kan det inte bära den någon annanstans och använda den där. Det enda det kan göra är att agera från den webbläsaren så länge den sessionen lever. Det är inte nollrisk, men det smalnar av hotets omfång.

Öppna sessioner skrivs till disk, så att ingen kastas ut när produkten uppdateras. Skrivningen görs avsiktligt i ett enda steg: hade filen blivit halvskriven skulle, trots att läsdelen tål det, alla öppna sessioner ha fallit.

Det som verkligen är värt att berätta är ett fel som hittades här genom mätning.

Utgångna sessionsposter rensades bara ur minnet, inte ur filen. En maskin i drift undersöktes: i filen låg fem utgångna poster, var och en med en biljett inuti. De hade blivit kvar där till nästa inloggning, eftersom inget annat någonsin skrev till den filen.

Kodens avsikt var redan att inte behålla dem. Det enda som saknades var skrivsteget.

Lärdomen gäller alla som skriver säkerhetskod: att glömma har två platser. Det som tagits bort ur minnet är inte borttaget från disken, och av de två lever det på disken alltid längre. När du bestämmer att något inte får sparas är den andra frågan alltid densamma: var sparas det?