it-swarm.com.de

CSRF in der Microservice-Architektur

Was sollte der richtige Weg sein, um den CSRF-Schutz in der Microservice-Architektur zu implementieren? Wo Dienste staatenlos sind.

  1. Um die CSRF-Überprüfung auf den Systemeintrag zu setzen? z.B. Tor

    Mit dieser Option kann ich nicht garantieren, dass das Kunden-Gateway dies tut.

  2. Oder bei jedem Microservice?

    Hier können wir garantieren, dass Dienste nach bestimmten Spezifikationen erstellt werden.Problem ist die Kommunikation von Dienst zu Dienst. Muss der Dienst in diesem Fall das CSRF-Token an einen anderen Dienst oder einen Header-API-Schlüssel übergeben? Weil einige Dienste vom Gateway und direkt von einem anderen Dienst aus erreichbar sind.

9
d-sauer

TL; DR: Behandeln Sie CSRF an derselben Stelle (Gateway oder ein dahinter stehender Dienst), an der Sie die Authentifizierung durchführen. Oder verwenden Sie keine Cookies für Authentifizierungstoken.

Die lange Version

In einem zustandslosen Design ist der häufigste Ansatz für den CSRF-Schutz Double Submit Cookie . Obwohl der Server keinen Status oder keine Sitzung hat, ist auf der Clientseite eine Sicherheitssitzung vorhanden. Es ist sehr wichtig, Double-Submit-Cookies so zu implementieren, dass sie an diese Sicherheitssitzung gebunden sind, und dies nicht zu tun naiv . Bitte lesen Sie diese Papier für weitere Details.

Ein Ansatz, um dies zu archivieren, besteht darin, das CSRF-Token in das Authentifizierungscookie aufzunehmen und das Authentifizierungscookie httpOnly zu erstellen. Auf diese Weise muss ein Angreifer in einer kompromittierten Subdomain sowohl das Authentifizierungscookie als auch das CSRF-Token überschreiben, was er nicht tun kann, da er keine Authentifizierungscookies fälschen kann. Selbst wenn er ein gültiges Authentifizierungscookie hat (z. B. sein eigenes), ändert dies den authentifizierten Benutzer und macht den Zweck von CSRF in erster Linie zunichte. Das Überschreiben des Cookies reicht auch nicht aus, um CSRF zu besiegen, da die Clientanwendung das CSRF-Token nicht aus dem Cookie selbst liest (es ist nur http), sondern bei einer erfolgreichen Authentifizierung ein CSRF-Token erhält.

Schritte zur Implementierung dieses Ansatzes finden Sie hier . Obwohl sich die Antwort auf diesen Link auf JWT bezieht, gilt der gleiche Ansatz für jedes Token-Format, das Sie für die Authentifizierung verwenden.

In der zustandslosen Microservice-Architektur besteht der beste Ansatz darin, CSRF an derselben Stelle zu verarbeiten, an der Sie die Authentifizierung durchführen, sei es auf dem Gateway oder einem anderen dahinter stehenden Dienst, da Sie die Authentifizierung bei jeder Anforderung durchführen müssen und das CSRF-Token lautet (wenn Sie meinen Rat implementieren oben) an die Authentifizierung gebunden. Jede andere Option erschwert die Sache weiter und bricht möglicherweise den CSRF-Schutz insgesamt. Zum Beispiel:

  1. Sie verarbeiten die Authentifizierung auf einem Gateway oder einem anderen Dienst, können jedoch die Art und Weise der Authentifizierung nicht ändern und können daher an dieser Stelle keinen CSRF-Schutz hinzufügen. In diesem Fall müssen Sie das CSRF-Token aus dem Authentifizierungstoken extrahieren und zusammen mit dem CSRF-Header zur Verarbeitung an den Zieldienst weiterleiten. Dies bedeutet, dass Sie in jedem Dienst einen CSRF-Schutz durchführen müssen, was nicht gut ist. Sie können nicht garantieren, dass jeder Dienst diese Prüfung durchführt. Außerdem müssen Sie sich um die Kommunikation zwischen den Diensten kümmern. Das Deaktivieren des CSRF-Schutzes bei Vorhandensein eines bestimmten Headers ist möglich, kann jedoch ein Sicherheitsrisiko darstellen.
  2. Sie führen keine Authentifizierung für ein Gateway durch oder Sie haben kein Gateway. Client-Anmeldeinformationen (Authentifizierungstoken/Cookie) werden an jeden Dienst in der Anforderungskette weitergeleitet, und jeder Dienst muss seinen eigenen Authentifizierungs-/CSRF-Schutz verwalten. Wie oben können Sie nicht garantieren, dass jeder Dienst dies tut, aber der Ansatz für den Umgang mit CSRF ist oben beschrieben.

Ein anderer Ansatz für den Umgang mit CSRF besteht darin, keine Cookies für Authentifizierungstoken zu verwenden und stattdessen Header für die Weitergabe von Authentifizierungstoken zu verwenden. Im Falle einer XSS-Sicherheitsanfälligkeit erleichtert dies jedoch den Diebstahl von Authentifizierungstoken. Ein Artikel über dieses Dilema ist zu finden hier .

10
Marko Vodopija

CSRF ist nur ein Problem bei Browsern (und Apps, die einen Browser wie eine Webansicht in eine mobile App einbetten). Daher muss kein Schutz für die Kommunikation von Maschine zu Maschine implementiert werden, da diese eine HTTP-Clientbibliothek und fest codierte URLs verwenden Möglichkeit, sie dazu zu bringen, einen CSRF-anfälligen Endpunkt zu "durchsuchen", wie Sie es mit einem normalen Browser können (z. B. mit einem img -Tag).

Für normale Clients sollte dies kein Problem sein, auch wenn Ihr Mikrodienst von außen erreichbar ist, da sein Authentifizierungssystem nur autorisierte Clients (andere Microservices, mobile Apps usw.) zulassen sollte und selbst wenn ein Kunde ausgetrickst wird Beim Zugriff auf seine API-Endpunkte sollte es nicht über die richtigen Anmeldeinformationen verfügen, um sich bei ihm zu authentifizieren (es sei denn, Ihre kundenorientierten API-Schlüssel oder Cookies können irgendwie für interne Mikrodienste funktionieren, was eine schlechte Idee ist und Sie sollten dies verhindern).

1
André Borie