Admin-Subdomain stoppt CSRF nicht: vier Prüfungen vor dem Start

Die Administrationsoberfläche nach admin.example.com zu verschieben ist eine echte Verbesserung: Sie hält Admin-Cookies von öffentlichen Seiten fern, gibt beiden Anwendungen getrennte Caches und erlaubt es, eine strengere Netzwerkrichtlinie auf einen Hostnamen zu richten. Es ist aber keine CSRF-Kontrolle, und es macht den Code der öffentlichen Seite nicht sicher, sie für einen angemeldeten Administrator offen zu halten. Die Trennung ändert, was der Browser als Grenze betrachtet, nicht was der Server prüft, deshalb erledigen Sie diese vier Prüfungen, bevor Sie die Sache als fertig bezeichnen.

Lesen Sie Origin und Site als zwei verschiedene Wörter

Ein Origin ist Schema, Host und Port, also sind https://www.example.com und https://admin.example.com verschiedene Origins. Eine Site im Sinne von SameSite ist Schema plus registrierbare Domain, also sind dieselben zwei Hostnamen meist dieselbe Site. Dieser Unterschied ist die ganze Falle: Das SameSite-Attribut hilft Ihnen nicht über gleichrangige Subdomains hinweg, weil der Browser die Anfrage überhaupt nicht als site-übergreifend betrachtet. Richten Sie die Administrationsoberfläche auf eine wirklich andere registrierbare Domain, etwa admin-example.net, und die Anfrage wird tatsächlich site-übergreifend, und dort beginnt SameSite=Lax oder Strict Arbeit zu leisten, auf die Sie sich verlassen können.

Prüfen Sie es im Browser, statt darüber zu räsonieren.

Laden Sie die öffentliche Seite, öffnen Sie die Entwicklerwerkzeuge und sehen Sie nach, welche Cookies der Browser an eine Anfrage an den Admin-Host anhängt. Hat das Cookie kein Domain-Attribut, gilt es nur für den Host und bleibt auf seinem eigenen Namen; trägt es Domain=example.com, reist es zu jedem Geschwister, und die neue Subdomain hat für dieses Cookie nichts gebracht.

Trennen Sie Antwort lesen können von Anfrage senden können

Die Same-Origin-Policy beschränkt das Lesen von Antworten über Origins hinweg. Sie verhindert nicht, dass eine Anfrage gesendet wird, und sie verhindert nicht, dass ein Formular Anmeldedaten mitführt, die der Browser bereits hat. Eine einfache Anfrage, mit Formular-Inhaltstyp oder schlichtem GET, wird ohne Vorabprüfung zugestellt; CORS entscheidet dann, ob das aufrufende Skript die Antwort lesen darf. CSRF lebt vollständig auf der Sendeseite.

Deshalb braucht der Server eine ausdrückliche Prüfung für zustandsändernde Operationen. Ein an die Sitzung gebundenes Synchronisationstoken oder ein serverseitig verglichenes Double-Submit-Cookie deckt den Fall ab; ein Origin- oder Referer-Vergleich ist als zweites Gate sinnvoll, aber nicht als einziges, weil nicht jede Anfrage den Header trägt und nicht jeder Proxy ihn bewahrt. Die OWASP-Anleitung zur CSRF-Abwehr behandelt SameSite genau deshalb als eine Schicht unter mehreren.

Entscheiden Sie, was das Netzwerk-Gate wirklich beweist

Eine Allowlist für VPN-Ausgänge vor dem Admin-Host ist eine gute Kontrolle und eine schwache Identitätsaussage. Sie beweist, dass die Anfrage von einer Adresse kam, die das VPN vergibt, die sich alle an diesem Ausgang teilen können, und sie sagt nichts darüber, welche Person oder welches Gerät dahintersteht. Behandeln Sie sie als Eintrittsfilter, nicht als Authentifizierung.

Halten Sie sie unabhängig von den Prüfungen auf Anfrageebene. Ist die Liste das Einzige zwischen einem Angreifer und einem zustandsändernden Endpunkt, entfernt eine fehlkonfigurierte Route, ein Split-Tunnel-Client oder ein geliehener Laptop die Kontrolle vollständig.

Protokollieren Sie auch Ablehnungen außerhalb der erwarteten Bereiche. Ein Schwall davon ist das nützlichste Signal, dass jemand die gerade gebaute Grenze sondiert, und Stille ist das Signal, dass der Filter überhaupt nicht erreicht wird.

Halten Sie Cookies, Anmeldung und Autorisierung ausdrücklich

Der Cookie-Geltungsbereich entscheidet den größten Teil des Ergebnisses. Ein Cookie der Parent-Domain wird an den Admin-Host gesendet, sodass eine Skript-Injektion auf der öffentlichen Seite mit der Sitzung eines Administrators handeln kann; ein reines Host-Cookie kann das nicht. Bevorzugen Sie die Host-Form, fügen Sie das Secure-Attribut hinzu und nutzen Sie das Präfix __Host-, wo die Plattform es unterstützt, denn dieses Präfix verlangt Secure, Path=/ und kein Domain-Attribut. Lesen Sie den Antwort-Header statt das Cookie-Glas: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, ohne Domain-Attribut. Ein Browser verwirft ein __Host--Cookie mit Domain, ein Cookie, das noch auf Geschwister-Hosts erscheint, beweist also, dass das Präfix nie gegriffen hat.

Halten Sie dann die Autorisierung auf dem Server, pro Anfrage, an jedem administrativen Endpunkt, nicht nur bei der Anmeldung. Eine Anfrage aus einem erlaubten Netzwerk muss weiterhin authentifiziert und für die verlangte Operation autorisiert werden; der Hostname ist kein Akteur. Wenn öffentliche und administrative Anwendung einen Anmeldeablauf oder einen Sitzungsspeicher teilen, schreiben Sie diese Beziehung auf, denn sie ist der kürzeste Weg von einem Fehler auf der öffentlichen Seite zu einer administrativen Aktion.

Prüfen Sie die Grenze nach der Trennung erneut

Führen Sie die Negativtests aus, nicht nur den glücklichen Pfad: Ein site-übergreifendes Formular ohne Token muss abgelehnt werden, ein Token aus einer anderen Sitzung muss abgelehnt werden, und kein GET darf Zustand ändern. Prüfen Sie die Cookie-Attribute in den Entwicklerwerkzeugen, bestätigen Sie, dass die Origin-Prüfung bei einer unpassenden Anfrage greift, und versuchen Sie den Admin-Host von außerhalb des VPN-Bereichs, um den Filter arbeiten zu sehen.

Nichts davon beseitigt einen XSS-Fehler innerhalb der administrativen Anwendung selbst. Ein getrennter Hostname ist eine Isolationsgrenze auf Browserseite mit echtem Wert, und er ersetzt weder die Verhinderung unsicherer Codeausführung noch den Schutz von Anfragen auf Serverseite. Nach der Trennung ist die Liste kürzer, als sie aussieht: eigener Origin, reine Host-Cookies, ein Token bei jeder Änderung, ein Eintrittsfilter, dem Sie nicht als Identität vertrauen, und pro Anfrage entschiedene Autorisierung.