Benötigen Anmeldeformulare Token gegen CSRF-Angriffe?

161

Nach dem, was ich bisher gelernt habe, sollen Token verhindern, dass ein Angreifer eine Formularübermittlung fälscht.

Wenn eine Website beispielsweise über ein Formular verfügt, in dem Artikel in Ihren Warenkorb eingegeben werden, und ein Angreifer Ihren Warenkorb mit Artikeln spammen kann, die Sie nicht möchten.

Dies ist sinnvoll, da das Warenkorbformular mehrere gültige Eingaben enthalten kann. Der Angreifer muss lediglich einen Artikel kennen, den die Website verkauft.

Ich verstehe, wie Token funktionieren und in diesem Fall Sicherheit hinzufügen, da sie sicherstellen, dass der Benutzer tatsächlich die Schaltfläche "Senden" des Formulars für jeden Artikel, der dem Warenkorb hinzugefügt wurde, ausgefüllt und gedrückt hat.

Fügen Token jedoch einem Benutzeranmeldeformular Sicherheit hinzu, für das ein Benutzername und ein Kennwort erforderlich sind?

Da der Benutzername und das Passwort sehr eindeutig sind, müsste der Angreifer beides wissen, damit die Anmeldefälschung funktioniert (auch wenn Sie keine Token eingerichtet haben), und wenn ein Angreifer dies bereits wusste, kann er sich einfach auf der Website anmelden selbst. Ganz zu schweigen davon, dass ein CSRF-Angriff, bei dem sich der Benutzer selbst anmeldet, ohnehin keinen praktischen Zweck hat.

Ist mein Verständnis von CSRF-Angriffen und -Token korrekt? Und sind sie für Benutzeranmeldeformulare nutzlos, wie ich vermute?

php token csrf

— php_learner
quelle

Sie können Ihren Router entführen, da Sie wahrscheinlich das Standardkennwort verwenden und es nicht CSRF-geschützt für die Anmeldung ist.

— AbiusX

Ja, andere Websites können Ihr Anmeldeformular also nicht nachahmen. Was können sie damit erreichen? Zuerst willst du das nicht zulassen. Zweitens: Sehr einfache Fehlerfälle wie das Blockieren des Benutzers aufgrund eines falschen Passworts n-Nr. von Zeiten kann vermieden werden.

— Mayankcpdixit

126

Ja. Im Allgemeinen müssen Sie Ihre Anmeldeformulare wie alle anderen vor CSRF-Angriffen schützen.

Andernfalls ist Ihre Website anfällig für eine Art "Phishing-Angriff auf vertrauenswürdige Domänen". Kurz gesagt, eine CSRF-anfällige Anmeldeseite ermöglicht es einem Angreifer, ein Benutzerkonto für das Opfer freizugeben.

Die Sicherheitsanfälligkeit spielt sich folgendermaßen ab:

Der Angreifer erstellt ein Hostkonto in der vertrauenswürdigen Domäne
Der Angreifer fälscht eine Anmeldeanforderung im Browser des Opfers mit den Anmeldeinformationen dieses Hostkontos
Der Angreifer bringt das Opfer dazu, die vertrauenswürdige Site zu verwenden, auf der es möglicherweise nicht bemerkt, dass es über das Host-Konto angemeldet ist
Der Angreifer hat jetzt Zugriff auf alle Daten oder Metadaten, die das Opfer (absichtlich oder unbeabsichtigt) "erstellt" hat, während sein Browser mit dem Host-Konto angemeldet war

Betrachten Sie als einschlägiges Beispiel YouTube . YouTube ermöglichte es den Nutzern, eine Aufzeichnung ihres "eigenen" Anzeigeverlaufs anzuzeigen, und ihr Anmeldeformular war CSRF-anfällig! So als Folge könnte ein Angreifer ein Konto mit einem Kennwort bis sie wußte, melden Sie sich das Opfer in YouTube mit diesem Konto - Stalking , welche Videos der Opfer beobachtet wurden.

In diesem Kommentarthread gibt es einige Diskussionen , die implizieren, dass er "nur" für solche Datenschutzverletzungen verwendet werden kann. Vielleicht, aber um den Abschnitt im CSRF-Artikel von Wikipedia zu zitieren :

Login CSRF ermöglicht verschiedene neuartige Angriffe; Beispielsweise kann sich ein Angreifer später mit seinen legitimen Anmeldeinformationen bei der Site anmelden und private Informationen wie den im Konto gespeicherten Aktivitätsverlauf anzeigen.

Schwerpunkt auf "neuartigen Angriffen". Stellen Sie sich die Auswirkungen eines Phishing-Angriffs auf Ihre Benutzer vor und stellen Sie sich dann vor, dass dieser Phishing-Angriff über das vertrauenswürdige Lesezeichen des Benutzers auf Ihrer Website funktioniert! Das im oben genannten Kommentarthread verlinkte Papier enthält mehrere Beispiele, die über einfache Datenschutzangriffe hinausgehen.

— natevw
quelle

6

Wie hilft der CSRF-Schutz? Gibt es irgendetwas, das den Angreifer daran hindert, nach seinem eigenen CSRF-Token zu fragen und nur damit einzureichen? Da keine authentifizierte Sitzung vorhanden ist, gibt es für den Webserver keinen Grund, ein Token einem anderen vorzuziehen.

— A. Wilson

2

"Gibt es irgendetwas, das den Angreifer daran hindert, nach seinem eigenen CSRF-Token zu fragen und nur damit einzureichen?" - Ja! Das ist die ganze Annahme hinter der CSRF-Präventionslogik. Browser haben / haben eine Formularübermittlung zugelassen, um auf einen anderen Ursprung abzuzielen, aber sie haben JS nie [absichtlich] erlaubt, Daten über Websites hinweg zu lesen , außer jetzt über Opt-In-CORS. Sofern Sie CORS nicht falsch eingerichtet haben, kann der Angreifer eine Formularübermittlung auslösen (die möglicherweise ein vorhandenes CSRF-Token in Cookies enthält ) , hat jedoch keine Möglichkeit , das Token zum Senden der erforderlichen zweiten Kopie zu kennen (z. B. im Text / in den Headern). CSRF-Code wird also abgelehnt.

— Natevw

7

Ich denke, Ihr letzter Kommentar ist falsch (Sie haben falsch verstanden, was A. Wilson gesagt hat). Wir sagen, dass ein Angreifer http://good.com/login.htmleinen Client laden, das verschachtelte CSRF-Token analysieren und dann veröffentlichen kann http://bad.com/login.html, das ein geändertes Formular enthält, das seinen Benutzernamen, sein Kennwort und sein Token unabhängig von der Eingabe des Opfers übermittelt . CORS gilt nicht, weil Sie ' Ich habe zwei separate Clients: den Angreifer und das Opfer. Um die Frage zu wiederholen: Funktioniert der CSRF-Schutz wirklich für Anmeldeformulare?

— Gili

8

Ja, CSRF schützt ein Anmeldeformular vor Fälschungen von standortübergreifenden Anfragen . Ein ordnungsgemäßes CSRF-Token ist bei jeder Generierung kryptografisch eindeutig. Sicher, der Angreifer kann selbst ein Token erhalten , aber es passt immer noch NICHT zu dem [möglicherweise nicht gesetzten] Cookie, das das Opfer in seinem Browser hat, und der Angreifer hat keine Möglichkeit, dieses Cookie zu setzen, ohne eine Seite in der guten Domain zu gefährden. (Ihr Beispiel scheint ein bisschen verwirrt zwischen CSRF und einer Art seltsamen Phishing-Attacke zu sein, daher bin ich mir nicht sicher, ob ich Ihre eigentliche Frage beantworte…)

— natevw

3

Ich kann mich irren, aber es scheint eine erhebliche Bedrohung zu bestehen, wenn der Benutzer versehentlich etwas im Zusammenhang mit dem Kauf von Artikeln tut. Ein Angreifer bringt den Benutzer beispielsweise dazu, sich bei einer Website anzumelden, und der Benutzer kauft Artikel, ohne zu bemerken, dass sie sich in einem anderen Konto befinden (denken Sie an Amazon oder ähnliches). Jetzt hat der Angreifer Zugriff auf gespeicherte Zahlungsinformationen, kann die Einkäufe umleiten usw.

— you786

14

Ihr Verständnis ist richtig - der springende Punkt bei CSRF ist, dass der Angreifer zuvor eine legitim aussehende Anfrage fälschen kann. Dies kann jedoch nicht mit einem Anmeldeformular erfolgen, es sei denn, der Angreifer kennt den Benutzernamen und das Passwort des Opfers. In diesem Fall gibt es effizientere Möglichkeiten, um anzugreifen (melden Sie sich selbst an).

Letztendlich kann ein Angreifer Ihren Benutzern nur Unannehmlichkeiten bereiten, indem er fehlgeschlagene Anmeldungen spammt, wenn das Sicherheitssystem den Benutzer für einen bestimmten Zeitraum sperrt.

— Jon
quelle

2

Wow Super schnelle Antwort! Vielen Dank! Jetzt kann ich meine Website sicher weiterbauen.

— php_learner

21

Login CSRF kann weiterhin für Angriffe auf die Privatsphäre des Benutzers verwendet werden. Seclab.stanford.edu/websec/csrf/csrf.pdf

— squiddle

6

@squiddle: Das ist ein ziemlich interessantes Papier, danke für den Link. Es hängt jedoch davon ab, ob der Benutzer mit einem Konto unter der Kontrolle des Angreifers angemeldet wird, und es wird davon ausgegangen, dass der Benutzer nicht erkennt, dass etwas nicht stimmt, und dass der Benutzer vertrauliche Informationen erstellt, die dann auf dem Server gespeichert werden. IMHO ist es also weniger ernst als "klassisches" CSRF.

— Jon

6

@ Jon Ja, es kann weniger ernst sein, aber am Ende kann es mehr als nur unangenehm sein, nämlich die Verletzung der Privatsphäre. Jeder Dienst muss sein Bedrohungsmodell selbst definieren und entsprechend behandeln. Dazu müssen Sie sich zumindest der möglichen Bedrohungen bewusst sein. Deshalb habe ich meine 2 Cent hinzugefügt.

— Squiddle

1

Könnten Sie bitte erläutern, wie sie vorgehen würden? "Letztendlich kann ein Angreifer Ihren Benutzern nur Unannehmlichkeiten bereiten, indem er fehlgeschlagene Anmeldungen spammt, wenn das Sicherheitssystem den Benutzer für einen bestimmten Zeitraum sperrt."

— Samthebest

0

Ja , andere Websites können Ihr Anmeldeformular also nicht nachahmen! So einfach ist das.

Was können sie damit erreichen?

Erstens: Das willst du nicht zulassen.
Zweitens: Auch sehr einfache Fehlerfälle wie:
- Benutzer wegen falschem Passwort blockieren nNr. von Zeiten kann vermieden werden.
- Flase-Hacking-Warnungen können verhindert werden. etc etc. etc.

— mayankcpdixit
quelle

Die meisten dieser Punkte sind falsch. Der Angreifer kann ein Anmeldeformular erstellen, die Anmeldeinformationen des Benutzers abrufen, das Anmeldeformular (mit csrf-Token) laden und die drei Informationen an das Ziel senden. CSRF verhindert dies nicht.

— Snapey

@ Snapey-Browser erlauben JS im Allgemeinen nicht, CSRF-Daten zu lesen. Mit JS können Sie die echte Formularübermittlungsanforderung nicht nachahmen.

— Mayankcpdixit

Das csrf-Token wird häufig zur Verwendung durch Javascript an den Client übergeben. Ich spreche nicht von Cors, die ich über den Angreifer nehme, der nur das Anmeldeformular anfordert und Anmeldeinformationen ausfüllt. @ Mayankcpdxit. Sie scheinen zu implizieren, dass csrf das Füllen von Anmeldeinformationen verhindert, was nicht der Fall ist.

— Snapey

Theoretisch kann es ja nicht verhindern. Es ist jedoch nicht möglich, das Füllen von Anmeldeinformationen nach CSRF zu automatisieren, wenn Sie das Laden von CSRF-Formularen in Iframes beenden und keine Ursprungsübergreifende Anforderung mehr zulassen.

— Mayankcpdixit

-1

Die Voranmeldung zur CSRF-Validierung macht meiner Meinung nach nicht allzu viel Sinn.

Vielen Dank an @squiddle für den Link: seclab.stanford.edu/websec/csrf/csrf.pdf , wir können auf der allerersten Seite lesen:

The most popular CSRF defense is to include a secret
token with each request and to validate that the received
token is correctly bound to the user’s session,
preventing CSRF by forcing the attacker to guess the
session’s token.

Wenn Sie versuchen, sich vor der Anmeldung für die CSRF-Validierung anzumelden, geben Sie einem potenziellen Angreifer die Möglichkeit, einen gültigen Code Ihrer Website zu entfernen! Er / sie wäre dann in der Lage, den Token, der den Zweck verfehlt, erneut zu veröffentlichen.

Vielleicht kann ein Angreifer dann versuchen, einen Benutzernamen Ihrer Site zu erraten. Was ich getan habe, wenn die IP-Adresse versucht, 10 Benutzernamen ohne Erfolg zu erraten, schreibe ich sie einfach auf die schwarze Liste.

— Patrice Gagnon
quelle