it-swarm.com.de

Sollten Anmelde- und Abmeldeaktionen CSRF-Schutz haben?

Ich mache eine Webanwendung in Django, die CSRF-Token für Sitzungen generiert und enthält (a Django Sitzung kann anonym oder ein registrierter Benutzer sein). Sollte ich behalten CSRF-Schutz für die Controller, die Anmelde- und Abmeldeaktionen ausführen?

25
Jesvin Jose

Möglicherweise sollten Sie sich vor Login CSRF schützen. Ohne diesen Schutz kann ein Angreifer einen CSRF-Angriff effektiv umkehren. Anstatt dass das Opfer in seinem eigenen Konto angemeldet ist und der Angreifer versucht, die Sitzung zu starten, indem er mithilfe der Cookies des Opfers Anfragen an die Site stellt, meldet er sich unter den Anmeldeinformationen des Angreifers auf der Site an, sodass der Angreifer Anfragen an die Website effektiv entführen kann Domain, die das Opfer für anonym hielt oder die sich unter seinem eigenen Konto befand, und die dann an das Konto des Angreifers gesendet wurde. Ob dies für Ihre Site relevant ist oder nicht, hängt natürlich von der Art Ihrer Site ab und davon, ob so etwas für einen Angreifer von Vorteil ist. Ein Beispiel ist ein Login-CSRF-Angriff auf eine Suchmaschine, bei dem der Angreifer die gesuchten Begriffe sehen kann, wenn sie unter dem Konto des Angreifers anstatt unter dem des Opfers protokolliert werden.

Die Hauptziele für diese Art von Angriff sind authentifizierte Aktionen, die außerhalb der Hauptanwendung selbst ausgeführt werden können. z.B. von einem Browser-Plugin oder Widget, das auf einer anderen Site eingebettet ist. Dies liegt daran, dass diese Aktionen mithilfe von Cookies authentifiziert werden. Wenn Sie sich als Angreifer angemeldet haben, wird jede Aktion in ihrem Konto aufgezeichnet.

Sie sollten Ihren Abmeldemechanismus auch vor CSRF schützen. Auf den ersten Blick scheint ein Angreifer nur den Benutzer abmelden zu können, was im schlimmsten Fall ärgerlich wäre. Wenn Sie dies jedoch mit einem Phishing-Angriff kombinieren, kann der Angreifer das Opfer möglicherweise dazu verleiten, sich mit seinem eigenen Formular erneut anzumelden und dann die Anmeldeinformationen zu erfassen. Siehe hier für ein aktuelles Beispiel - LostPass .

33
SilverlightFox

Anmeldung? Ja. Ausloggen? Nein.

Warum einloggen? Es gibt diesen lustigen CSRF-Anmeldeangriff, bei dem sich der Angreifer unter einem vom Angreifer kontrollierten Konto beim Opfer anmeldet und dann "die Kontrolle über den Inhalt erlangen kann, den das Opfer erstellt hat, während er unter diesem Konto angemeldet ist". Die Auswirkungen sind IMO ziemlich lahm, aber sie begannen dies als Problem zu betrachten, da mehr saftige Angriffsvektoren verschwunden sind. ;-);

Warum nicht abmelden? Es gibt keine Sicherheitsauswirkungen. Das Beste, was man tun kann, ist, jemanden vom System abzumelden, was höchstens Ärger verursacht.

EDIT : Es gibt keine Sicherheitsauswirkungen beim Abmelden von CSRF-Angriffen von selbst. Es kann Fälle geben, in denen dies bei einem mehrstufigen Angriff verwendet wird, um zuerst jemanden abzumelden und ihn dann auf einer gefälschten Seite zur Anmeldung aufzufordern.

6

CSRF-Schutz beim Abmelden ist ein Muss!

Warum? Nehmen Sie das folgende Szenario an:

  1. Sie befinden sich auf einer Handelsseite und bereiten eine Bestellung für z. 1000 Daimler auf einem Exchange XETRA.
  2. Bis Sie die Bestellung vorbereiten, sendet Ihnen jemand, der weiß, dass Sie angemeldet sind https://anybrokerpage.com/ , einen Phishing-Link. z.B. https://anybrokerpage.com/logout
  3. Wenn Sie auf den Link klicken, werden Sie abgemeldet und die Bestellung ist möglicherweise noch nicht abgeschlossen.
  4. Nachdem Sie sich erneut angemeldet haben, erkennen Sie, dass der Preis für die 1000 Daimlers höher ist als eine Minute, bevor Sie sich über diesen Phishing-Link abgemeldet haben.
  5. Jetzt müssen Sie einen höheren Preis bestellen.

Ein CSRF-Token beim Abmelden hätte dieses Durcheinander verhindert.

6
security-guest

Abmelden und Anmelden CSRF ist eigentlich sehr ausnutzbar.

Wenn Sie eine Möglichkeit finden, ein permanentes privates/selbst-XSS zu erhalten (z. B. ein ungesichertes privates Feld wie in den Benutzereinstellungen), können Sie das Abmelden des Opfers erzwingen, sich mit Ihrem Konto anmelden, auf das das selbst-XSS angewendet wurde, und dann Code ausführen um einen Phishing-Angriff durchzuführen außer es befindet sich in der richtigen Domain mit einem gültigen SSL-Zertifikat. Wenn sich der Benutzer anmeldet (oder über eine automatische Ausfüllung verfügt, mit der Sie seine Anmeldeinformationen stehlen können, bevor er überhaupt auf "Senden" klickt, und sich dann automatisch für ihn anmeldet, damit seine Seite möglicherweise nur weiß blinkt und er dann dort ist, wo er sie erwartet), werden Sie jetzt angemeldet haben ihr Passwort und die gleiche Origin-Ausführung. Führen Sie jetzt einfach eine Exploit-Persistenz in den privaten Einstellungen aus, und Sie haben jetzt eine permanente Remote-JS-Ausführung für das Benutzerkonto.

Dies ermöglicht sehr große Angriffe, zumal viele Entwickler nicht beide mit HTML-Injection-Exploits auf privaten Feldern arbeiten, da nur der Benutzer dies sehen sollte und keinen Grund hat, Code gegen sich selbst auszuführen. Mit einem CSRF-Exploit zum Abmelden der Anmeldung können Sie dasselbe Origin-Phishing ausführen. Wenn dieselben Origin-Iframes aktiviert sind, können Sie die Anmeldeseite auch im Vollbildmodus einbetten und dann den gewünschten Code in den scheinbar legitimen Iframe ausführen.

Jeder der Fehler allein reicht von nutzlos bis bestenfalls ärgerlich, aber wenn Sie diese beiden haben (und es ist am besten, immer davon auszugehen, dass Sie dies tun), kann ein Angreifer ein Benutzerkonto mit nur einer bösen Anzeige entführen.

3
Sirens

CSRF für die Anmeldung im Allgemeinen ja, hängt jedoch von Ihrer Anwendung ab. Ein Angreifer kann Sie bei einem böswilligen Konto anmelden, z. B. bei Google, und dann alle Ihre Site-Besuche überwachen.

CSRF zum Abmelden - ja kann DOS absolut verhindern

2
Darragh