Ik heb de toegang ingetrokken en toch zit diegene er nog: een sessie is niet hetzelfde als een bevoegdheid

U heeft de bevoegdheid van een gebruiker weggehaald. Misschien heeft u het account helemaal uitgezet. Daarna merkt u dat die persoon nog steeds dingen kan doen.

Er is niets stuk. Inloggen en bevoegd zijn zijn twee aparte momenten, en daartussen zit een gat.

Inloggen gebeurt één keer, bevoegdheid wordt elke keer gevraagd

Wanneer u inlogt overhandigt het systeem u een ticket. Het ticket zegt: deze persoon heeft bewezen wie hij is, en dit ticket geldt tot dat tijdstip.

Bevoegdheid is een aparte vraag, die bij elk verzoek opnieuw wordt gesteld. Maar in de praktijk nemen veel systemen bij het inloggen een kopie van de bevoegdhedenkaart, voor de snelheid, en gebruiken die kopie een tijd lang.

Daaruit ontstaan twee vertragingen.

De eerste: haalt u een bevoegdheid weg, dan kan een open sessie die kopie blijven meedragen. De wijziging bereikt hem pas wanneer de sessie wordt vernieuwd.

De tweede, en de belangrijkere: een gebruiker verwijderen of uitzetten verscheurt het ticket in zijn hand niet. Het ticket is op zichzelf staand en blijft geldig tot het verloopt.

De regel: toegang intrekken is niet een sessie beëindigen

Dit zijn twee aparte handelingen, en alleen de eerste doen laat achter u een venster openstaan.

Het venster is niet oneindig; een ticket geldt geen hele dag. Maar nul is het ook niet, en in een dringend geval is "het sluit zo meteen" geen afdoende antwoord.

Wanneer iemand vertrekt, of een wachtwoord verdacht is

Doe drie dingen, op volgorde.

Haal de bevoegdheid weg. Zet ook het account uit als dat aan de orde is.

Wijzig het wachtwoord. Dat sluit de weg om een vers ticket te halen ter vervanging van het ticket dat hij heeft. Alleen een bevoegdheid weghalen doet dat niet.

Verwijder de toegangstokens apart. Dit is de stap die het vaakst wordt overgeslagen. Een token is geen sessie: het verloopt niet vanzelf, het leeft tot u het verwijdert. Het wachtwoord van een gebruiker wijzigen maakt zijn tokens niet ongeldig. Controleer bij het verwijderen van een gebruiker apart wat er van zijn tokens is geworden.

En laten we een misverstand wegnemen: tweestapsverificatie helpt u hier niet. Die beschermt het moment van inloggen. Over een al geopende sessie heeft die niets te zeggen.

De andere richting: waarom word ik steeds uitgelogd

Dit is de keerzijde van hetzelfde mechanisme.

Het ticket heeft een beperkte levensduur, en de interface vernieuwt het regelmatig zolang u op het tabblad bent. Sluit het tabblad en kom uren later terug: er is geen vernieuwing geweest, het ticket is dood, en u wordt gevraagd opnieuw in te loggen. Dat is geen storing.

De tweede, minder bekende oorzaak is interessanter: de klok van de machine. Een ticket draagt een tijdstempel. Loopt de klok van de server uit de pas, dan kan een zojuist uitgegeven ticket eruitzien alsof het uit de toekomst komt of allang verlopen is. Het verschijnsel is verwarrend: het wachtwoord klopt, het inloggen lijkt aanvaard, en meteen daarna valt de sessie weg. Aan een klokprobleem denken aan de identiteitskant komt bij niemand op, maar zoek ernaar.

Wat Atlas doet

Bij Atlas is de cookie die naar de browser gaat niet het echte ticket. De browser draagt alleen een betekenisloze willekeurige aanduiding; het eigenlijke ticket blijft op de server.

Het verschil is concreet: zelfs als een browserlek de cookie leest, komt het niet weg met het ticket zelf, dus het kan het niet ergens anders heen dragen en daar gebruiken. Het enige wat het kan doen is handelen vanuit die browser zolang die sessie leeft. Dat is geen nulrisico, maar het versmalt de reikwijdte van de dreiging.

Open sessies worden naar schijf geschreven, zodat er niemand uitvliegt wanneer het product bijwerkt. Het schrijven gebeurt bewust in één stap: was het bestand half geschreven blijven staan, dan zouden, hoewel de leeskant dat verdraagt, alle open sessies zijn weggevallen.

Wat echt het vertellen waard is, is een gebrek dat hier door meten is gevonden.

Verlopen sessieregistraties werden alleen uit het geheugen opgeruimd, niet uit het bestand. Er is naar een draaiende machine gekeken: in het bestand lagen vijf verlopen registraties, elk met een ticket erin. Ze zouden daar tot de volgende aanmelding zijn blijven liggen, want niets anders schreef ooit naar dat bestand.

De bedoeling van de code was al om ze niet te bewaren. Het enige wat ontbrak was de schrijfstap.

De les geldt voor iedereen die beveiligingscode schrijft: vergeten heeft twee plaatsen. Wat uit het geheugen is gehaald, is niet van de schijf gehaald, en van de twee leeft die op schijf altijd langer. Wanneer u besluit dat iets niet bewaard mag worden, is de tweede vraag altijd dezelfde: waar wordt het bewaard?