Session

HTTP er tilstandsløst, så websessioner lægges ovenpå, næsten altid via cookies (RFC 6265). Der er to grundlæggende designs. I en serverside-session indeholder cookien kun et tilfældigt id, og tilstanden ligger i et lager på serveren som hukommelse, Redis eller en database; OWASP's Session Management Cheat Sheet kræver mindst 64 bit entropi fra en kryptografisk sikker generator. I en klientside- eller tilstandsløs session bærer cookien eller bearer-tokenet selv tilstanden, signeret og ofte krypteret, som med et JWT. Tilstandsløse designs skalerer let, men kan ikke tilbagekaldes før udløb uden en afvisningsliste på serveren eller korte levetider plus refresh, og det er den egentlige afvejning.

Hærdning af cookies er standard: Secure (kun HTTPS, understøttet af HSTS), HttpOnly (kan ikke læses fra JavaScript, hvilket begrænser tyveri via XSS), SameSite=Lax eller Strict (begrænser afsendelse på tværs af websites og svækker CSRF) og navnepræfikset __Host-, der gennemtvinger Secure, Path=/ og ingen Domain-attribut, så underdomæner hverken kan plante eller læse cookien. Sessions-id'et skal genereres på ny ved login og ved enhver ændring af rettigheder; ellers arver en angriber, der på forhånd har plantet et kendt id, den autentificerede session (session fixation). Logud skal ugyldiggøre sessionen på serveren og ikke bare slette cookien i browseren.

Levetider fastlægges i sikkerhedspolitikken. OWASP foreslår inaktivitetsgrænser på 2 til 5 minutter for applikationer med høj værdi og 15 til 30 minutter for applikationer med lavere risiko samt absolutte grænser på 4 til 8 timer, cirka en arbejdsdag, for applikationer med høj risiko. NIST SP 800-63B-4 fastsætter grænser for genautentificering efter sikringsniveau: på AAL2 højst 24 timer i alt og 1 time uden aktivitet og på AAL3 12 timer i alt med inaktivitet begrænset til 15 minutter. Følsomme handlinger som at skifte adgangskode eller godkende en betaling bør kræve frisk autentificering uanset sessionens alder.

Den dominerende moderne trussel er tyveri af en session, der er oprettet helt legitimt. Adversary-in-the-middle-phishingkits opsnapper den cookie, der udstedes efter MFA, og infostealer-malware eksporterer cookies fra browserprofiler; MITRE ATT&CK beskriver det som Steal Web Session Cookie (T1539) og genbrug af Web Session Cookie (T1550.004). Modtrækket er at binde sessionen til klienten: Den tidligere standard Token Binding (RFC 8471) fik kun ringe browserunderstøttelse, og nyere tilgange binder cookies eller refresh-tokens til en nøgle, som enheden har. At binde en session til en IP-adresse er skrøbeligt på mobilnet. Med single sign-on er der flere lag, IdP-sessionen, hver applikations session og eventuelle OAuth-refresh-tokens, og afslutning af ét lag afslutter ikke de andre, medmindre logud videreformidles. Applikationssessioner er også forskellige fra genoptagelse af TLS-sessioner og fra styresystemets logonsessioner, der deler navnet, men ikke mekanismen.