SameSite-Attribut auf Lax statt Strict

Seit Browser SameSite=Lax als Standard verwenden, ist ein großer Teil der klassischen CSRF-Angriffe von selbst verschwunden. Dieser Erfolg verleitet dazu, die Einstellung als erledigt zu betrachten. Es bleibt jedoch eine bestimmte Kategorie übrig, die Lax bewusst durchlässt. In diesem Artikel lesen Sie, welche das ist und wann sich der Schritt zu Strict lohnt.

Was bewirkt das SameSite-Attribut?

Das SameSite-Attribut bestimmt, ob der Browser ein Cookie bei einer Anfrage mitsendet, die von einer anderen Website ausgeht. Es gibt drei Werte. Strict sendet das Cookie ausschließlich bei Anfragen, die innerhalb Ihrer eigenen Website entstehen. Lax tut dasselbe mit einer Ausnahme: Bei Navigation auf oberster Ebene mit einer sicheren Methode, kurz gesagt, wenn der Nutzer auf einen Link klickt und damit zu Ihrer Website gelangt, geht das Cookie sehr wohl mit. None hebt die Beschränkung ganz auf.

Diese eine Ausnahme bei Lax hat einen praktischen Grund. Ohne sie würde jeder, der über eine E-Mail, ein Suchergebnis oder einen geteilten Link auf Ihre Website kommt, mit einer Anmeldemaske begrüßt, obwohl er eine gültige Sitzung besitzt. Das ist lästig genug, um Lax zum üblichen Kompromiss zu machen.

Es handelt sich also nicht um einen Fehler, sondern um eine Abwägung. Vergleichen Sie es mit einer verschlossenen Tür, die für jeden geöffnet wird, der ordentlich klingelt. Für die meisten Gebäude ist das in Ordnung. Für einen Tresorraum nicht.

Was lässt Lax noch durch?

Der Unterschied wird konkret bei Endpunkten, die etwas ändern und über eine Navigation erreichbar sind.

Verwundbar:

Set-Cookie: sid=8f42c19ade7b3f5c; HttpOnly; Secure; SameSite=Lax; Path=/

Dieses Cookie ist ordentlich geschützt, und ein klassischer CSRF-Angriff mit einem automatisch abgesendeten POST-Formular von einer fremden Seite funktioniert nicht mehr: Bei einem seitenübergreifenden POST bleibt das Cookie zu Hause. Existiert jedoch irgendwo in der Anwendung ein Vorgang, der über ein GET läuft, ändert sich das Bild:

<!-- Auf der Seite des Angreifers; ein Klick des Opfers genügt -->
<a href="https://portal.example/abonnement/kuendigen?bestaetigen=ja">
  Ihre Rechnung ansehen
</a>

Dies ist Navigation auf oberster Ebene mit einer sicheren Methode, der Browser sendet das Session-Cookie also ganz normal mit. Der Vorgang wird im Namen des angemeldeten Nutzers ausgeführt. Dasselbe gilt für einen Angreifer, der mit JavaScript über window.open oder ein <form method="GET"> eine Navigation erzwingt. Auch kennen Browser in den ersten Minuten nach dem Setzen eines Cookies eine Ausnahme, bei der sich Lax nachgiebiger verhält, was ein kleines, aber reales Zeitfenster ergibt.

Sicher:

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

Mit Strict geht das Cookie bei keiner von außen angestoßenen Anfrage mit, auch nicht beim Folgen eines Links. Der obige Angriff führt dann zu einer abgemeldeten Sitzung statt zu einem gekündigten Abonnement.

Möchten Sie Strict nutzen, ohne Nutzer über externe Links stranden zu lassen, ist das übliche Muster ein Gespann aus zwei Cookies: ein kurzlebiges Lax-Cookie, das ausschließlich dazu dient zu erkennen, dass eine Sitzung besteht, und das eigentliche Session-Cookie auf Strict. Die Landeseite sieht dann, dass der Nutzer bekannt ist, und leitet ihn über eine interne Navigation weiter, wonach das Strict-Cookie sehr wohl mitgeht.

Welche Auswirkungen hat SameSite auf Lax?

Für sich genommen ist das ein Härtungsbefund mit niedrigem Schweregrad. Lax blockiert die meisten Angriffsmuster, und viele Anwendungen verfügen zusätzlich über CSRF-Token, wodurch das verbleibende Risiko klein bleibt.

Die Bedeutung entsteht im Zusammenspiel mit anderen Entscheidungen. Bestehen Endpunkte, die den Zustand über eine GET-Anfrage ändern, etwa eine Kündigung, eine Bestätigung, eine Aktivierung oder eine Löschung, fehlt der Schutz genau für diese Endpunkte. Und gerade solche Routen entstehen oft versehentlich, beispielsweise weil ein Bestätigungslink in einer E-Mail nun einmal ein GET ist.

Ein zweiter Faktor ist das Vorhandensein von Subdomains. Da diese als dieselbe Website gelten, bietet SameSite in keiner Variante Schutz vor einem Angriff, der von einer Ihrer eigenen Subdomains ausgeführt wird. Organisationen mit vielen Subdomains, Testumgebungen oder von Lieferanten betreuten Seiten haben von diesem Attribut also weniger, als es scheint.

Wie prüft man die SameSite-Einstellung?

Der Wert des Attributs lässt sich unmittelbar aus dem Set-Cookie-Header ablesen. Interessanter ist, was dieser Wert in dieser konkreten Anwendung bedeutet, und das erfordert eine Bestandsaufnahme der Endpunkte.

Ein Tester sucht nach Routen, die etwas ändern, aber über ein GET erreichbar sind: Bestätigungslinks, Aktivierungs-URLs, Kündigungen und Verwaltungsfunktionen, die als Link umgesetzt wurden. Für jede davon wird geprüft, ob ein CSRF-Token verlangt wird. Ebenso wird geprüft, ob das Attribut durchgängig auf allen Authentifizierungscookies steht, ob es Cookies mit SameSite=None gibt, die das nicht benötigen, und ob Subdomains bestehen, die als Sprungbrett dienen können. AssistSec bewertet dies nicht als einzelne Einstellung, sondern als Teil der CSRF-Widerstandsfähigkeit insgesamt, denn die Frage lautet nicht, welcher Wert dort steht, sondern ob ein Angreifer in der Praxis noch einen Vorgang erzwingen kann.

Wie setzt man SameSite sicher?

• Verwenden Sie SameSite=Strict für Session-Cookies von Anwendungen mit sensiblen oder unumkehrbaren Vorgängen.
• Arbeiten Sie mit einem Muster aus zwei Cookies, wenn Sie Strict nutzen möchten, ohne Nutzer über externe Links zu behindern.
• Verwenden Sie weiterhin CSRF-Token bei jedem zustandsändernden Vorgang; SameSite ist eine Ergänzung, kein Ersatz.
• Führen Sie nie eine Änderung über eine GET-Anfrage aus, auch nicht bei Bestätigungslinks aus E-Mails.
• Setzen Sie SameSite=None nur auf Cookies, die nachweislich seitenübergreifend benötigt werden, stets zusammen mit Secure.
• Betrachten Sie Subdomains als Teil Ihrer Angriffsfläche, da SameSite sie als dieselbe Website behandelt.
• Prüfen Sie bei sensiblen Vorgängen zusätzlich die Origin- und Referer-Header.
• Halten Sie den gewählten Wert in Ihrer Sitzungskonfiguration fest, damit neue Cookies ihn automatisch übernehmen.