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, von der das Opfer glaubte, sie sei anonym oder unter seinem eigenen Konto und sende sie dann an das Konto des Angreifers. 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 Hier können authentifizierte Aktionen außerhalb der Hauptanwendung selbst ausgeführt werden. z.B. von einem Browser-Plugin oder Widget, das auf einer anderen Site eingebettet ist. Dies liegt daran, dass diese Aktionen durch die Verwendung von Cookies authentifiziert werden. Wenn Sie sich bei einem Angreifer angemeldet haben, wird jede Aktion in seinem 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. Hier finden Sie ein aktuelles Beispiel - LostPass.

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 Daimler 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 .
ol>

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

Anmelden? Ja. Ausloggen? Nein.

Warum anmelden? 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 Sie tun können, ist, jemanden vom System abzumelden, was höchstens Ärger verursacht.

BEARBEITEN : Es gibt keine Sicherheitsauswirkungen beim Abmelden von CSRF-Angriffen . 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.

Abmelden und Anmelden CSRF ist tatsächlich 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 die Abmeldung des Opfers erzwingen und sich mit Ihrem Konto anmelden, das über das selbst-XSS verfügt angewendet, und führen Sie dann Code aus, um einen Phishing-Angriff auszuführen, außer in der richtigen Domäne 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 dann dort ist, wo er sie erwartet), werden Sie jetzt angemeldet haben ihr Passwort und die gleiche Ursprungsausführung. Führen Sie jetzt einfach eine gewisse Exploit-Persistenz in ihren privaten Einstellungen aus, und jetzt haben Sie 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 aktivieren private Felder, da nur der Benutzer dies sehen kann und keinen Grund hat, Code gegen sich selbst auszuführen. Mit einem CSRF-Exploit zum Abmelden von Anmeldungen können Sie Phishing mit demselben Ursprung durchführen. Wenn für dieselben Iframes der gleiche Ursprung aktiviert ist, können Sie die Anmeldeseite auch im Vollbildmodus einbetten und dann den gewünschten Code in den scheinbar legitimen Iframe ausführen Die Fehler allein reichen 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.

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 für die Abmeldung - ja, kann DOS absolut verhindern