Das folgende Zitat stammt aus Ссылка
Wenn ein Benutzer eine Site besucht, sollte die Site ein (kryptografisch stark) pseudozufällig und setzen Sie es als Cookie auf dem Computer des Benutzers. Die Website sollte jedes Formular einreichen diesen Pseudozufallswert als einen Formwert und auch als ein Cookie-Wert. Wenn eine POST-Anfrage an die Site gesendet wird, wird die Anfrage gesendet sollte nur gültig sein, wenn der Formularwert und der Cookie-Wert sind gleich. Wenn ein Angreifer ein Formular im Auftrag eines Benutzers einreicht, wird er kann nur die Werte des Formulars ändern. Ein Angreifer kann keine lesen Daten, die vom Server gesendet werden oder Cookie-Werte für denselben Ursprung ändern Politik. Dies bedeutet, dass ein Angreifer einen beliebigen Wert senden kann Mit dem Formular kann er den gespeicherten Wert nicht ändern oder lesen der Keks. Da der Cookie-Wert und der Formularwert der sein müssen Ebenso kann der Angreifer ein Formular nicht erfolgreich übermitteln, es sei denn Er kann den Pseudozufallswert erraten.
Die obige Methode verhindert CSRF-Angriffe, indem der pseudo-and-Wert im Cookie und Formular verglichen wird. Warum muss der Wert aber auch mit dem Formular zurückgegeben werden? Ich gehe davon aus, dass sowohl das Formular als auch der Cookie denselben verschlüsselten Wert haben, den sie an den Server zurückgeben. Und der Server validiert ihn, indem er den Wert entschlüsselt.
Auch wenn der Wert nur vom Cookie zurückgegeben wird, kann der Server ihn entschlüsseln und die Anfrage verifizieren. Welchen Zweck hat die Rückgabe des verschlüsselten Wertes mit dem Formular?
Cookies werden automatisch bei jeder Anfrage gesendet, unabhängig davon, ob die Anfrage von der ursprünglichen Site oder von einer dritten Site initiiert wurde. Deshalb reicht ein Cookie alleine nicht aus, da jede Anfrage es enthält.
Aber da das Token auch in der Anfrage selbst enthalten ist, kann eine angreifende Site keine gültigen Anfragen mehr erzeugen, da sie das Token des Benutzers nicht erreichen können.
Ok, also lasst uns das Problem auf atomare Fragen zum besseren Verständnis aufteilen:
Was ist das CSRF?
Es ist eine Art von Sicherheitsanfälligkeit für Webanwendungen. Grundlegend für einen CSRF ist, dass der Browser nicht versteht, wie er zu unterscheiden hat, wenn eine Aktion von einem Benutzer absichtlich ausgeführt wurde (z. B. durch Klicken auf eine Schaltfläche in einem Formular oder durch Klicken auf einen Hyperlink usw.) oder wenn Der Benutzer hat die Aktion unwissentlich ausgeführt (z. B. wenn der Benutzer eine Seite aus einer Domäne aufgerufen hat, z. B. bad.com, und bad.com eine Anfrage an good.com/some_action gesendet hat, während der Benutzer bereits bei good.com angemeldet war).
Was bedeutet CSRF?
Nun ersetzen wir good.com oben durch facebook.com. Nehmen wir an, dass wenn ein Benutzer, der bei facebook.com angemeldet ist, einen Kommentar an seine Pinnwand schreibt, eine HTTP GET-Anfrage gesendet wird, beispielsweise im Format https: //facebook.com/postComment?userId=Abhinav_123&comment=HiIAmAbhinav.
Nehmen wir nun an, dass der Benutzer, während er noch bei facebook.com angemeldet ist, eine Seite auf bad.com aufruft. Jetzt gehört bad.com einem Angreifer, wo er folgendes auf bad.com codiert hat:
%Vor%Sobald der Browser des Benutzers den Inhalt dieser Seite auf bad.com lädt, wird eine Anfrage auch an facebook.com gesendet:
Ссылка
, weil der Browser versucht, das img-Tag zu rendern. Dazu muss es die in src angegebene Ressource abrufen und sendet daher die obige HTTP-GET-Anforderung. Im Wesentlichen könnte der Angreifer also im Auftrag des Nutzers eine Anfrage an facebook.com stellen, ohne dass er dies tatsächlich weiß.
Was könnte diesen Angriff möglicherweise verhindert haben?
Wenn es nur einen Weg gäbe, um festzustellen, ob die Anfrage vom Benutzer absichtlich gemacht wurde. Um dies zu tun, kam ein Anti-CSRF-Token ins Spiel. Es ist nur eine zufällige, eindeutige Zeichenfolge, die vom Server generiert wird (facebook.com in unserem Beispiel oben) und an den Benutzer gesendet und im Browser des Benutzers als Cookie gesetzt wird. Nun wird der Browser diese zufällige Zeichenfolge zusammen mit der Anfrage senden, bevor die Aktion durchgeführt wird, um zu überprüfen, ob die zufällige Zeichenfolge die ist, die sie hatte an den Browser gesendet oder nicht.
Die Idee ist, dass diese zufällige Zeichenfolge dem Angreifer nicht bekannt sein wird. Selbst wenn der Angreifer einen img src wie oben gezeigt erstellt und der Benutzer bad.com besucht, wird die Aktion (des Postens eines Kommentars in unserem obigen Beispiel) nicht ausgeführt, da für die auszuführende Aktion, abgesehen von der URL , eine zusätzliche Sache ist auch erforderlich, das ist die zufällige Zeichenfolge, die der Angreifer nicht hat.
Aber das Setzen dieser zufälligen Zeichenfolge in einem Cookie hat wieder einen RIESIGEN Fehler
Aufgrund der Art und Weise, wie Cookies gestaltet sind, und der Art und Weise, wie Browser Cookies handhaben, wird das Setzen dieser zufälligen Zeichenfolge (das Anti-CSRF-Token) im Cookie nicht unserem Zweck dienen. Von Grund auf werden Cookies mit jeder Anfrage, die der Client an diesen Server stellt, automatisch an den Server gesendet (einfach gesagt und zur Vereinfachung weggelassen. Weitere Einzelheiten finden Sie unter: RFC2965 )
In unserem obigen Beispiel braucht der Angreifer die zufällige Zeichenfolge nicht wirklich zu kennen. Die Aktion zum Kommentieren von Kommentaren wird weiterhin abgeschlossen. Sobald der Nutzer bad.com besucht und die Postkommentar-URL lädt (wie oben erläutert), wird das angeforderte Anti-CSRF-Token (im Cookie enthalten) automatisch mit der Anfrage verknüpft.
Was ist dann die Lösung?
Anstatt das Anti-CSRF-Token in den Cookie zu setzen, muss der Server (facebook.com) es als versteckten Parameter in ein Formular setzen und machen, wenn der Benutzer ein Kommentar dieses Formular anfordert CSRF-Token) sollte ebenfalls gepostet werden.
Nun hat der Angreifer keine Möglichkeit mehr, diese sensible Aktion im Namen des Benutzers auszuführen (es sei denn, er findet irgendwie das zufällige Anti-CSRF-Token selbst heraus)
Kommen Sie nun zum Problem der Anmeldung von CSRF und doppelter Submission-Cookie
Viele Websites würden sich gegen CSRF-Angriffe schützen, indem sie eine Form der anti_CSRF-Token-Architektur bereitstellen. Aber viele Websites kümmern sich nicht viel darum, ihr Login-Formular gegen CSRF-Angriffe zu schützen. Warum ? - Da selbst ein Login-Formular für CSRF anfällig ist und ein Angreifer versucht, es auszunutzen, indem eine Login-Anfrage an good.com (facebook.com) über seine Domain (bad.com) gesendet wird, muss der Benutzer seine gültigen Zugangsdaten eingeben auf facebook.com eingeloggt werden. Diese Anmeldeinformationen sind nur für den echten Benutzer und nicht für den Angreifer verfügbar. Daher kann der Angreifer keine erfolgreiche Anmeldeanforderung einrahmen.
Was ist nun die Angriffsmöglichkeit für den Angreifer?
Der Angreifer kann sein eigenes Konto bei Facebook erstellen.com. Er hat jetzt einen gültigen Satz von Anmeldeinformationen für sich selbst. Jetzt rahmt er die Login-Anfrage auf facebook.com mit seinen Zugangsdaten und auf seiner Domain (bad.com). Wenn der Benutzer die Seite bad.com jetzt besucht, ist der Benutzer bei meinem Konto angemeldet. Ich als angegriffener kann später alle vom Benutzer ausgeführten Aktivitäten auf dem Konto sehen, die möglicherweise auch sensible Informationen offen legen (wie zum Beispiel Freundschaftsanfragen, die gesendet werden, wenn der Benutzer neue Freundschaftsanfragen sendet, Nachrichten, die erneut an den Benutzer gesendet werden Nach der Anmeldung in meinem Account hängen alle diese Möglichkeiten davon ab, wie überzeugt der Nutzer ist, dass er sich in diesen eigenen Account eingeloggt hat, was wiederum der Angreifer selbst dadurch erledigen kann, dass er seine eigene Facebook-Seite so nah wie möglich an das Opfer heranlegt er glaubt, dass es sein Konto ist)
Also, was ist die Minderungstechnik dagegen?
Es ist ein Double Submit Cookie, den wir jetzt hier brauchen.
Was genau bedeutet das
?Double submitting cookies ist so definiert, dass ein zufälliger Wert sowohl in einem Cookie als auch in einem Anfrageparameter gesendet wird, wobei der Server überprüft, ob der Cookie-Wert und der Anfragewert gleich sind.
Wie kann der Angriff gemildert werden?
Gemäß dem Implementierungsprinzip eines doppelten Cookies, wenn ein anonymer Benutzer (nicht eingeloggter Benutzer) eine Login-Seite besucht, setzt der Server ein Cookie mit einer zufälligen Zeichenfolge im Browser des Benutzers und setzt dasselbe in einem Anfrageparameter wie gut (sagen Sie ein Formular verstecktes Feld). Wenn der Benutzer die Anmeldeanforderung einreicht, werden diese Dinge mit der Anfrage übermittelt - die Benutzeranmeldeinformationen, die zufällige Zeichenfolge im versteckten Formularfeld und der Cookie mit der zufälligen Zeichenfolge (die automatisch gesendet wird).
Nun hat ein Angreifer Zugriff auf seine eigenen Zugangsdaten, die zufällige Zeichenfolge, die vom Server in Cookie und im versteckten Formularfeld für den Angreifer festgelegt wurde. Wenn der Angreifer diese ausgearbeitete Anmeldeanforderung an den Benutzer (das Opfer) sendet und der Benutzer versucht, diese Anforderung zu stellen, ist der Benutzer immer noch nicht angemeldet und ist bisher ein anonymer Benutzer für den Server. Der Server wird also einen Cookie im Browser des Benutzers mit einem anderen (vom Angreifer) Zufallswert setzen. Wenn der Benutzer nun die Anmeldung über den manipulierten Link des Angreifers anfordert, enthält die Anfrage die Anmeldeinformationen des Angreifers, die zufällige Zeichenfolge des Angreifers im Feld für das ausgeblendete Formular, aber die zufällige Zeichenfolge des Benutzers im Cookie (aus dem Browser des Benutzers). Wenn diese Anforderung den Server erreicht, stimmen die zufälligen Zeichenfolgen im Cookie und im ausgeblendeten Formularfeld nicht überein und werden daher als Ausnahme gekennzeichnet und entsprechend behandelt.
Das ist also der Grund für die Rückgabe des verschlüsselten Wertes mit dem Formular. Hoffe es klärt das Konzept.
Tags und Links security authentication authorization cookies csrf