{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"security/session-hijacking","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/session-hijacking/","da":"https://cmaintz.github.io/tech-atlas/da/terms/security/session-hijacking/"},"term":{"en":"Session hijacking","da":"Sessionskapring"},"aka":{"en":["session takeover","cookie theft"],"da":["session hijacking","sessionsovertagelse"]},"domain":["security"],"cluster":"fundamentals","layer":"identity","status":"current","era":1995,"summary":{"en":"Taking over someone's session after they have logged in, so the attacker is treated as that user without knowing the password.","da":"Overtagelse af en brugers session efter login, så angriberen behandles som brugeren uden at kende adgangskoden."},"body":{"formal":{"en":"An attack in which the session token or cookie that proves a user has already logged in is stolen or guessed and then reused from the attacker's own machine. Because the check happened at login, the system accepts the attacker as the real user.","da":"Et angreb, hvor den session-token eller cookie, der viser, at en bruger allerede er logget ind, bliver stjålet eller gættet og derefter genbrugt fra angriberens egen maskine. Fordi kontrollen skete ved login, accepterer systemet angriberen som den rigtige bruger."},"plain":{"en":"Someone copies the stamp on your hand outside the club and walks in as if they had shown ID at the door.","da":"En person kopierer stemplet på din hånd uden for diskoteket og går ind, som om vedkommende havde vist ID ved døren."},"inPractice":{"en":"A harmful browser extension on a case worker's PC in a Danish region copies her live session cookie for the cloud mail service; the attacker opens her inbox from abroad without ever meeting an MFA prompt.","da":"En skadelig browserudvidelse på en sagsbehandlers pc i en region kopierer i det skjulte hendes aktive sessionscookie til cloud-mailen; angriberen åbner indbakken fra udlandet uden nogensinde at blive bedt om MFA."},"whyItMatters":{"en":"It gets around strong passwords and even MFA, because it steals what the system hands out after those checks have passed.","da":"Det går uden om stærke adgangskoder og endda MFA, fordi det stjæler det, systemet udleverer, efter at kontrollerne er bestået."}},"deepDive":{"en":"Session hijacking exploits the stateless nature of HTTP: because the protocol does not remember a user between requests, a server issues a session identifier after authentication and thereafter trusts any request bearing it. In classic web applications this identifier is an opaque session ID stored server-side and carried in a cookie; in modern token-based systems it may be a bearer token such as a JWT or an OAuth 2.0 access/refresh token. Whoever presents a valid, unexpired session artefact is treated as the authenticated user, which is the crux of the attack - the credential being replayed is not the password but the proof-of-login the system minted afterwards. This is why hijacking bypasses even strong authentication and most MFA: those checks happened before the token was issued.\n\nThe token can be obtained in several ways. Cross-site scripting (XSS) is the predominant route for stealing cookies via injected script, unless the cookie is marked HttpOnly (which blocks script access); network interception applies where traffic is unencrypted, largely closed off by ubiquitous TLS; malware or malicious browser extensions can read cookie stores directly on the endpoint; and adversary-in-the-middle phishing proxies relay a real login to capture the resulting session in real time. Related but distinct are session fixation, where the attacker sets a known session ID before the victim logs in (defeated by regenerating the ID on authentication), and cross-site request forgery, which rides an existing session without stealing the token. In the OWASP Top 10:2025 these belong to A07 Authentication Failures.\n\nDefences layer around protecting, binding and expiring the session. Cookies should carry the HttpOnly, Secure and an appropriate SameSite attribute; the session ID must be long, random and regenerated on privilege changes; and idle and absolute timeouts limit the token's useful life. Because a stolen bearer token is inherently replayable, high-assurance systems move toward proof-of-possession or token-binding schemes (such as DPoP for OAuth) that cryptographically tie the token to a client key, and continuous or risk-based re-evaluation that invalidates a session when context shifts - a new IP, device or geolocation. This continuous verification is a core Zero Trust idea: authentication is not a one-time gate but an ongoing assessment.\n\nA key misconception is that MFA prevents session hijacking; it protects the login event, not the session that follows, so stolen-cookie attacks are precisely how attackers sidestep MFA, and the mitigations must target the token itself. Another is assuming HTTPS makes cookie theft impossible; TLS stops network sniffing but not XSS, endpoint malware or phishing-proxy capture. Session hijacking is the consequence that a man-in-the-middle position or an XSS flaw enables, and it stands adjacent to credential theft: stealing the password lets an attacker log in, while stealing the session lets them skip logging in entirely.","da":"Sessionskapring udnytter, at HTTP er tilstandsløst: fordi protokollen ikke husker en bruger mellem forespørgsler, udsteder serveren et session-id efter autentificering og stoler derefter på enhver forespørgsel, der bærer det. I klassiske webapplikationer er dette id et uigennemsigtigt session-id, der gemmes på serversiden og bæres i en cookie; i moderne token-baserede systemer kan det være et bearer-token som et JWT eller et OAuth 2.0 access-/refresh-token. Den, der fremviser et gyldigt, ikke-udløbet session-artefakt, behandles som den autentificerede bruger - og det er selve kernen i angrebet: det, der genafspilles, er ikke adgangskoden, men det loginbevis, systemet udstedte bagefter. Derfor omgår kapring selv stærk autentificering og de fleste MFA: de kontroller skete, før tokenet blev udstedt.\n\nTokenet kan skaffes på flere måder. Cross-site scripting (XSS) er den fremherskende vej til at stjæle cookies via indsprøjtet script, medmindre cookien er mærket HttpOnly (hvilket blokerer script-adgang); netværksaflytning gælder, hvor trafik er ukrypteret, men er stort set lukket af udbredt TLS; malware eller ondsindede browserudvidelser kan læse cookie-lageret direkte på endepunktet; og adversary-in-the-middle-phishingproxyer videresender et rigtigt login for at opsnappe den resulterende session i realtid. Beslægtede, men adskilte er session fixation, hvor angriberen sætter et kendt session-id, før offeret logger ind (modvirkes ved at regenerere id'et ved autentificering), og cross-site request forgery, der rider på en eksisterende session uden at stjæle tokenet. I OWASP Top 10:2025 hører disse under A07 Authentication Failures.\n\nForsvar lægges i lag omkring at beskytte, binde og udløbe sessionen. Cookies bør bære attributterne HttpOnly, Secure og en passende SameSite; session-id'et skal være langt, tilfældigt og regenereres ved rettighedsændringer; og inaktivitets- og absolutte timeouts begrænser tokenets brugbare levetid. Fordi et stjålet bearer-token i sig selv kan genafspilles, bevæger systemer med højt sikringsniveau sig mod proof-of-possession- eller token-binding-ordninger (som DPoP for OAuth), der kryptografisk binder tokenet til en klientnøgle, samt løbende eller risikobaseret revurdering, der ugyldiggør en session, når konteksten skifter - en ny IP, enhed eller geolokation. Denne løbende verifikation er en kerneidé i Zero Trust: autentificering er ikke en engangsport, men en vedvarende vurdering.\n\nEn central misforståelse er, at MFA forhindrer sessionskapring; det beskytter selve login-hændelsen, ikke sessionen, der følger, så cookie-tyveri er netop den måde, angribere kommer uden om MFA på, og modforanstaltningerne må ramme tokenet selv. En anden er at antage, at HTTPS gør cookie-tyveri umuligt; TLS stopper netværksaflytning, men ikke XSS, endpoint-malware eller phishingproxy-opsnapning. Sessionskapring er den konsekvens, en man-in-the-middle-position eller en XSS-fejl muliggør, og den står tæt på credential-tyveri: at stjæle adgangskoden lader en angriber logge ind, mens det at stjæle sessionen lader vedkommende springe login helt over."},"edges":[{"type":"requires","to":"cs/authentication","confidence":"high","strength":"normal"},{"type":"kind-of","to":"security/threat","confidence":"high","strength":"normal"},{"type":"exploits","to":"cs/session","why":{"en":"A session is trusted for its whole life without asking again, so whoever holds it is taken to be the user.","da":"En session betroes i hele sin levetid uden at spørge igen, så den, der har den, antages at være brugeren."},"confidence":"high","strength":"primary"}],"depth":3,"sources":[{"title":"OWASP - Session hijacking attack","url":"https://owasp.org/www-community/attacks/Session_hijacking_attack","tier":"reference","publisher":"OWASP"},{"title":"MITRE ATT&CK - T1539 Steal Web Session Cookie","url":"https://attack.mitre.org/techniques/T1539/","tier":"reference","publisher":"MITRE"}],"draft":true}