csrf-Angriffe und Doppel eingereicht cookie
Den unten Zitat aus http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html
Wenn ein Benutzer eine Website besucht, sollte die Website generieren
(kryptographisch starker) Pseudo-Wert und legen Sie es als cookie
auf der Maschine des Benutzers. Der Standort sollte fordern, dass jede form der Einreichung
diese Pseudo-zufälligen Wert als eine form Wert und auch als
cookie-Wert. Wenn eine POST-Anforderung gesendet wird, um die Website, die Anfrage
sollte nur als gültig angesehen werden, wenn die form-Wert und der cookie-Wert
sind die gleichen. Wenn ein Angreifer ein Formular übermittelt im Namen eines Benutzers ein, er
können ändern Sie nur die Werte aus dem Formular. Ein Angreifer kann nicht Lesen
Daten vom server gesendet oder ändern der cookie-Werte, pro den gleichen Ursprung
Politik. Dies bedeutet, dass, während ein Angreifer kann senden, jeder Wert er will
mit der form, wird er nicht in der Lage zu ändern oder Lesen der gespeicherte Wert in
der cookie. Seit dem cookie-Wert und die form muss der Wert der
derselbe, der Angreifer nicht in der Lage, erfolgreich ein Formular Absenden, es sei denn,
er ist in der Lage zu erraten, die Pseudo-Wert.
Die oben genannte Methode verhindert CSRF-Angriffe durch den Vergleich der psuedorandom Wert im cookie und form. Aber warum wird der Wert zurückgegeben werden müssen mit dem Formular auch ? Ich gehe davon aus, dass sowohl die form und cookie haben den gleichen verschlüsselten Wert, Sie kehren zurück an den server. Und der server bestätigt es, indem er den Wert.
So, auch wenn der Wert nur dann zurückgegeben wird nur das cookie, dann kann der server Sie entschlüsseln und überprüfen Sie die Anfrage. Welchen Zweck hat die Rückgabe der verschlüsselten Wert mit dem Formular dienen?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Automatisch Cookies gesendet werden, mit jeder Anfrage, unabhängig davon, ob der Antrag wurde initiiert von der original-Website oder von einem Drittanbieter-Website. Das ist, warum ein cookie allein reicht nicht aus, da jede Anfrage enthält es.
Sondern mit den token auch in dem Antrag selbst, eine angreifende Website generieren kann, gültige Anfragen mehr, da Sie nicht bekommen können, halten Sie auf dem token des Benutzers.
Ok, also lasst uns brechen das problem zu atomaren Fragen zum besseren Verständnis:
Was ist das CSRF ?
Es ist eine Art von web application vulnerability. Auf der grundlegendsten Ebene, ist der Grund für eine CSRF ist, dass browser, die nicht verstehen, wie man unterscheiden, ob eine Aktion durchgeführt wurde absichtlich von einem Benutzer (wie etwa ein Mausklick auf eine Schaltfläche auf einem Formular, oder klicken auf einen hyperlink etc.) oder, wenn die Benutzer unwissentlich die Aktion ausgeführt hat (sagen wir mal der Benutzer besucht eine Seite von einer domain, sagen wir bad.com und bad.com schickte eine Anfrage an good.com/some_action während der Benutzer bereits angemeldet good.com).
Also, was ist die Wirkung von CSRF
Nun lassen Sie uns ersetzen good.com oben mit facebook.com. Und lassen Sie uns davon ausgehen, dass, wenn ein Benutzer angemeldet facebook.com, posten Sie einen Kommentar auf seine Mauer, dort ist ein HTTP-GET-Anforderung gesendet wird, von der form sagen,
https: //facebook.com/postComment?userId=Abhinav_123&comment=HiIAmAbhinav.
Lassen Sie uns nun davon ausgehen, dass der Benutzer, während er ist noch angemeldet facebook.com Besuche eine Seite auf bad.com. Jetzt bad.com gehört zu einem Angreifer, wo er codiert die folgenden auf bad.com:
Nun, sobald der browser des Benutzers lädt die Inhalte von dieser Seite auf bad.com eine Anfrage wird auch verschickt facebook.com als :
https: //facebook.com/postComment?userId=Abhinav_123&comment=I_AM_AN_IDIOT
weil der browser versucht zu Rendern, das img-tag. Zu tun, so muss zum abrufen der Ressource angegeben, die in src und damit sendet es die oben genannten HTTP-GET-Anfrage. Also im wesentlichen die Angreifer tatsächlich senden Sie eine Anfrage an facebook.com im Namen des Benutzers, ohne ihn wirklich zu wissen, diese.
Nun, was hätte möglicherweise verhindert dieser Angriff ?
Wenn es nur einen Weg, um zu ermitteln, ob die Anforderung durch die Anwender bewusst. So, um dies zu tun, anti-CSRF-token kam ins Bild. Es ist nur eine zufällige, eindeutige Zeichenfolge, die vom server generiert (facebook.com in unserem Beispiel oben) und schickte an die Benutzer und setzen Sie in den browser des Nutzers ein cookie. Jetzt für jede Anfrage, mit ein paar sensible Aktion (wie das posting einen Kommentar in unserem facebook-Beispiel oben) den browser senden diese zufällige Zeichenfolge, die auch zusammen mit der Anfrage und der server vor dem ausführen der Aktion prüfen, ob die zufällige Zeichenfolge ist das eine, es hatte an den browser gesendet werden oder nicht.
Die Idee ist, dass diese zufällige Zeichenfolge, die nicht dem Angreifer bekannt. Also selbst wenn der Angreifer erstellt ein img-src wie oben gezeigt, und die der Nutzer besucht bad.com die Aktion (bei der Buchung einen Kommentar in unserem Beispiel oben) nicht durchgeführt werden, weil für die Aktion, die durchgeführt werden, abgesehen von der URL, eine weitere Sache ist auch erforderlich, die die zufällige Zeichenfolge, die der Angreifer nicht zu haben.
Aber diese Einstellung beliebige Zeichenfolge in einem cookie hat wieder einen RIESIGEN Fehler
Aufgrund der Art der cookies sind entworfen, und die Art und Weise, in dem die Browser mit cookies umgehen, indem Sie die zufällige Zeichenfolge (die anti-CSRF-token) in der cookie wird nicht dazu dienen, unser Ziel. Durch design, cookies werden automatisch an den server gesendet, mit jeder Anfrage, die der client mit dem server (einfach ausgedrückt, und details weggelassen werden, die für Einfachheit. Für mehr details Lesen Sie bitte : RFC2965)
So, in unserem Beispiel oben, den Angreifer gar nicht wirklich wissen müssen, um die zufällige Zeichenfolge. Die posting-Kommentar-Aktion wird noch abgeschlossen werden, da, sobald der Nutzer besucht bad.com und die Lasten der post-Kommentar-URL (wie oben erklärt) die zufällige anti-CSRF-token (in der "cookie") wird automatisch die Begleitung von der Anfrage.
Also, was ist die Lösung ?
Anstatt die anti-CSRF-token in den Cookies, die server - (facebook.com muss setzen es als versteckten parameter in eine form und machen Sie, wenn der Benutzer-Anfragen für die Buchung einen Kommentar in dieser form (halten Sie die anti-CSRF-token) sollte auch gepostet werden.
Der Angreifer hat nun keine Möglichkeit der Durchführung dieses sensible Aktion im Auftrag des Benutzers (sofern er irgendwie findet heraus, dass der random anti-CSRF-token selbst)
Jetzt kommt das problem der login-CSRF und double submit Cookies
Viele Male websites schützen sich gegen CSRF-Attacken durch den Einsatz von irgendeiner form von anti_CSRF-token-Architektur. Aber eine Menge Zeit websites, die nicht viel Wert auf den Schutz Ihrer login-Formular gegen CSRF-Angriffe. Warum ? - Denn selbst ein login-Formular ist anfällig für CSRF-Angriffe und der Angreifer versucht, die Ausbeuten durch framing eine login-Anfrage an good.com (facebook.com) durch seine domain (bad.com), die der Benutzer noch eingeben müssen, seine gültige Anmeldeinformationen loggedinto facebook.com. Diese Anmeldeinformationen sind verfügbar nur mit dem echten Benutzer und nicht der Angreifer und somit kann der Angreifer nicht in einem frame einer erfolgreichen login-Anfrage.
Was ist also der Angriff die Chance für die Angreifer hier ?
Kann der Angreifer seinen eigenen account mit facebook.com. Er hat jetzt einen gültigen Satz Anmeldeinformationen für sich selbst. Jetzt ist er frames die login-Anforderung zu facebook.com mit seinen Anmeldedaten ein, und auf seine domain (bad.com).
Nun, wenn der Benutzer die Seite besucht, bad.com der Benutzer ist in mein Konto eingeloggt. Ich als einer angegriffen wird kann später sehen, alle Aktivitäten der Benutzer auf das Konto möglicherweise die Offenlegung sensibler Informationen sowie (sagen wir mal Freundschaftsanfragen gesendet, wenn der Benutzer zum senden von Freundschaftsanfragen, Nachrichten an jemand, wieder, wenn der Nutzer muss also nach dem einloggen in mein Konto. Alle diese Möglichkeiten, die davon abhängen, wie die den Benutzer davon überzeugt ist, dass er sich angemeldet hat, das eigene Konto, was wiederum die Angreifer kümmern kann, indem er seine eigene facebook-Seite Aussehen, als in der Nähe des Opfers wie möglich zu con ihm zu glauben, dass es sein Konto)
Also was ist nun die Milderung Technik gegen diese?
Es ist ein double submit Cookies, die müssen wir jetzt hier.
Was genau bedeutet das
Wie kommt es dazu beitragen, die angreifen ?
Als pro die Implementierung Prinzip einer double cookie, wenn ein anonymer Benutzer (nicht angemeldet Benutzer) besucht eine login-Seite, die der server setzt ein cookie mit einigen zufälligen string im browser des Benutzers und bestimmt auch die gleichen, die in einem request-Parameters als auch (sagen wir ein Formular verstecktes Feld). Wenn der Benutzer sendet die login-Anfrage, diese Dinge vorgelegt bekommen, mit der Aufforderung, die Benutzer-Anmeldeinformationen, die zufällige Zeichenfolge in der hidden-form-Feld und das cookie hält die zufällige Zeichenfolge (das wird automatisch gesendet, natürlich).
Nun ein Angreifer Zugriff auf seine eigenen Anmeldeinformationen, die zufällige Zeichenfolge, die vom server festgelegt im cookie und in der hidden-form-Feld für die Angreifer. Wenn der Angreifer sendet diese gestaltete login-Anfrage an den Benutzer (das Opfer), und der Benutzer versucht, diesen Wunsch, der Benutzer ist noch nicht angemeldet und ein anonymer user für den server so weit. Also der server setzt ein cookie auf dem browser des Benutzers mit einer anderen (vom Angreifer) zufälliger Wert. Nun, wenn der Benutzer die Anforderung für die Anmeldung durch die Angreifer erstellten link, wird die Anforderung enthalten, die der Angreifer die Anmeldeinformationen, die vom Angreifer beliebige Zeichenfolge in das versteckte Formularfeld, aber der Benutzer zufällige Zeichenfolge, die in der cookie (aus dem browser des Benutzers). Nun, wenn diese Anfrage den server erreicht, der zufällige Zeichenfolgen in das cookie und die hidden-form-Feld würde nicht passen und würde somit gekennzeichnet werden als eine Ausnahme und entsprechend behandelt.
Also dies der Grund für die Rückgabe der verschlüsselten Wert mit dem Formular als gut. Hoffe, es klärt den Begriff.