Scanner für unsichere Cookies

Wie diese Prüfung funktioniert

Scanaris liest die Set-Cookie-Header, die dein Server beim Laden der Startseite sendet, und prüft die Attribute jedes Cookies. Drei Dinge: ob es Secure trägt (nur verlangt, wenn die Website über HTTPS läuft), ob es HttpOnly trägt und ob es SameSite deklariert. Deutet der Cookie-Name auf Sitzung oder Authentifizierung hin (session, auth, token, sid und ähnliche), hat der Fund mittleren Schweregrad, sonst niedrigen. Ein Sonderfall mit eigenem mittlerem Schweregrad: SameSite=None ohne Secure, das moderne Browser schlicht ablehnen, sodass das Cookie nicht funktioniert und zudem eine auf Cross-Site-Nutzung ausgelegte Konfiguration verrät. Gesehen werden nur die Cookies dieser ersten Antwort; die nach dem Login erzeugten prüfst du besser mit dem Befehl unten oder mit dem authentifizierten Scan.

Was jedes Attribut bedeutet

• Secure: Das Cookie reist nur über HTTPS. Ohne es schickt eine HTTP-Anfrage (ein alter Link, ein öffentliches Netz) es im Klartext, und jeder im Netz liest es.
• HttpOnly: JavaScript kann es nicht lesen. Das ist der Unterschied zwischen einem XSS, das die Sitzung stiehlt, und einem, das es nicht kann.
• SameSite: wann es von einer anderen Website aus mitgeschickt wird. Lax sendet es bei normalen Navigationen, aber nicht bei Anfragen, die eine fremde Website auslöst; Strict nie von außen; None immer, und verlangt Secure. Es ist die Hauptverteidigung gegen CSRF.

Was ein Angreifer mit einem Sitzungs-Cookie ohne diese Attribute tut

Ohne HttpOnly liest jedes injizierte Skript document.cookie, schickt den Wert an seinen Server und meldet sich mit deiner Sitzung an. Ohne SameSite kann eine fremde Seite ein Formular an deine Website senden, Cookie inklusive, und im Namen des Nutzers eine Bestellung aufgeben oder eine E-Mail-Adresse ändern. Ohne Secure genügt es, dass der Nutzer in einem geteilten Netz einen http://-Link zu deiner Domain öffnet. In allen drei Fällen ist das Ergebnis dasselbe: Jemand handelt als dein Nutzer.

Wie du es je nach Framework behebst

// Express mit express-session
app.use(session({
  cookie: { secure: true, httpOnly: true, sameSite: 'lax' }
}));

// Next.js (Route Handler oder Server Action)
cookies().set('session', value, { httpOnly: true, secure: true, sameSite: 'lax', path: '/' });

// Nuxt (server/api)
setCookie(event, 'session', value, { httpOnly: true, secure: true, sameSite: 'lax', path: '/' });

Mit Supabase in einer App mit Server speichert die Bibliothek @supabase/ssr die Sitzung in Cookies mit diesen Attributen; in einer reinen SPA landet die Sitzung im localStorage, was die Prüfung Tokens im Storage misst. In Django, Rails oder Laravel werden die Attribute in den Sitzungseinstellungen konfiguriert und sind standardmäßig vernünftig; prüf, ob sie niemand gesenkt hat, um ein Entwicklungsproblem zu „lösen".

Prüf, ob es behoben ist

curl -sI https://deinedomain.com | grep -i "set-cookie"
curl -sI -X POST https://deinedomain.com/api/login -d "..." | grep -i "set-cookie"

Jedes Sitzungs-Cookie muss Secure; HttpOnly; SameSite=Lax (oder Strict) zeigen. Läuft dein Login über ein Formular, schau dir die Antwort in den Browser-Tools an, Tab Netzwerk, Antwort-Header.

Häufige Fragen

Mein Cookie wird von JavaScript erzeugt (Analytics, Einstellungen). Es kann nicht HttpOnly sein.

Richtig, und das ist in Ordnung: Diese Cookies geben Zugriff auf nichts. Die Prüfung meldet das fehlende Attribut mit niedrigem Schweregrad; wichtig ist, dass die Sitzungs-Cookies es haben.

Ich brauche SameSite=None, weil meine App in einem iframe auf einer anderen Domain läuft.

Dann ist es legitim, immer mit Secure. Stell sicher, dass die übrigen CSRF-Verteidigungen (Tokens in Formularen, Prüfung des Origin) aktiv sind, denn SameSite schützt dich dann nicht mehr.

Lax oder Strict?

Lax für die meisten Fälle: Es hält die Sitzung, wenn der Nutzer über einen externen Link kommt. Strict, wenn das Cookie Zugang zu etwas sehr Sensiblem gibt und du akzeptierst, dass der Nutzer sich beim Kommen von außen neu anmelden muss.