10.3 Mitigation of Infostealer and Cookie Exploitations
What an Infostealer Actually Wants
Infostealer malware is rarely after passwords any more; it exports the browser's state directory and lifts the cookies database, the local storage leveldb, saved cards, and extension tokens. A stolen session cookie is more valuable than a stolen password because it has already passed the login ceremony: it clears multi-factor checks, skips risk prompts, and replays until it expires. Defenses therefore stop being "stop the malware" and become "make the harvested artifact worthless fast" -- shorten its life, bind it to context, and keep the server in the loop.
Cookie Flags Are Boundaries, Not Encryption
Three attributes decide who can touch a session cookie. HttpOnly removes it from document.cookie, so injected DOM script -- the vector that infostealers happily piggyback on -- cannot read or copy it, though the browser still attaches it to requests. Secure confines it to TLS, killing network sniffing and downgrade stripping, and it is a prerequisite for the next flag. SameSite decides whether the cookie rides along on cross-site requests: Lax permits top-level navigation GETs, Strict blocks cross-site sends almost entirely, and None -- the legacy default -- is what makes CSRF possible at all. SameSite plus anti-CSRF tokens bind the cookie to the site that owns it; see the OWASP Session Management Cheat Sheet for the full attribute matrix.
Short TTLs, Rotation, and Revalidation
Expiry is the mitigation with the best ratio of pain to payoff. Keep access tokens in the five-to-fifteen-minute band and put longevity in a refresh token that rotates on every use, so a replayed old refresh reveals itself and revokes the family. Store token state server-side -- a revocation list, token introspection, or a session record -- because client-side JWTs cannot be revoked once minted. Revalidate inside the session, not just at login: bind to a device or network fingerprint, force step-up for sensitive actions, and re-authenticate after an IP jump or password change. That continuous verification is exactly what a stolen cookie cannot reproduce, and it is an explicit requirement area in the OWASP Application Security Verification Standard.
Storage Choice Is Exposure Choice
Anything parked in localStorage or sessionStorage is a plain string readable by any script on the origin, by a malicious browser extension, and by anyone who gets physical access for ten seconds. That is why putting a long-lived token there to "avoid cookie hassle" is a downgrade: it removes HttpOnly and SameSite protection and hands XSS a one-call exfiltration. Keep tokens in HttpOnly cookies, keep only non-secret UI state in storage, and pair it with a Content Security Policy so the read primitive is harder to obtain.
Architecture Diagram
Key Takeaways
- Infostealers harvest live session cookies and stored tokens because those already cleared login and multi-factor.
- HttpOnly blocks script access, Secure confines the cookie to TLS, and SameSite limits cross-site attachment -- three different leak paths closed.
- Fifteen-minute access tokens with rotating refresh tokens and server-side revocation cap the value of any captured artifact.
- Continuous, in-session revalidation is what a replayed cookie cannot imitate; login-time-only checks assume the token is honest.
- Secrets in localStorage trade cookie-flag protections for a store any script, extension, or shoulder can read.