In welchem ​​Fall kann eine CSRF-Befreiung gefährlich sein?

Question

Diese Frage ist mehr eine Rückversicherung als eine direkt über wie zu codieren. Als Autodidakt hatte ich nicht viele Möglichkeiten, Profis solche Dinge zu fragen, also versuche ich es hier.

Ich habe die Dokumente in dem django-docs (https://docs.djangoproject.com/en/1.3/ref/contrib/csrf/) und einige Informationen auf dieser Seite zu lesen: http://cwe.mitre.org/top25/#CWE-352

Soweit ich verstanden habe, django ein Token (eine Art von Pin-Code) ein liefert Benutzer. Und um zu bestätigen, dass es wirklich er ist, muss er es zurückgeben, wenn er das nächste Mal eine Anfrage macht. Und einige Leute bei Google haben herausgefunden, dass dies sogar mit Ajax-Anfragen möglich ist, weshalb wir seit 1.2.6 auch die neue Richtlinie haben, sie zu schützen. Und bei CSRF geht es darum, dass jemand mir etwas gibt (schlechter, gefährlicher Code, korrupte Dateien oder so ähnlich) und vorgibt, jemand anderes zu sein.

Also, wenn ich habe einige Code wie folgt aus:

@csrf_exempt  
def grab(request): 
    """ 
    view to download an item 
    POST because it stores that a user has downloaded this item 
    """ 
    item_id = request.POST.get('item', None) 
    if not loop: return HttpResponseBadRequest('no item id provided') 
    item = Item.objects.get(pk=int(item_id)) 

, die sparen sollte, wie ich keinen Zugriff auf die Datenbank oder einen Teil meiner Anwendung geben werde, bevor Sie den angegebenen Wert in eine umwandeln ganze Zahl. Und es gibt nicht zu viel Schaden, wenn ich eine falsche Aufzeichnung von jemandem mache, der eine Datei herunterlädt (in diesem Fall ist es fast keine). Angenommen, ich würde Rechnungen schreiben, die sich auf diese Sichtweise stützen, wäre die CSRF-Befreiung eine sehr schlechte Idee (Ist das richtig?).

Ich verstehe auch nicht, warum jemand das CSRF-Token von einem Benutzer nicht stehlen kann und es immer noch dazu benutzt, mich (oder den Benutzer) auszutricksen. Also habe ich ein paar Fragen zu diesem Thema:

1) sind meine Annahmen von oben rechts?

2) kann mir jemand sagen, was (und wahrscheinlich wie) ein nicht so netter Kerl könnte die obige Ansicht benutzen, um schmutzige Tricks zu machen, und was wären sie?

3) ist ein CSRF ein Beispiel für einen Man-in-the-Middle-Angriff, ist es nur damit verwandt oder ist es etwas ganz anderes?

4) Gibt es wertvolle Links, um weitere Informationen zu solchen Gefahren zu erhalten?

Vielleicht klingen einige dieser Fragen nicht allzu gut informiert, aber ich versuche, darüber hinweg zu kommen. Ich wäre sehr froh, wenn mir jemand helfen könnte.

Answer 1

CSRF attacks sind über Erzwingen eines Opfers Browser gezwungen, gefälschte Anfragen zu senden. Eine einfache oder automatisch übermittelte <form> reicht aus, dies sowohl für GET-und POST-Methode zu tun. Und wenn die Anfragen vom Browser gesendet werden, sendet er Authentifizierungsdaten mit und macht die Anfragen aus der Sicht des Servers authentisch und legitim, da sie sich grundsätzlich nicht von denen unterscheiden, die durch die Aktionen des Benutzers ausgelöst werden.

Und genau dafür wird das CSRF-Token verwendet: Ermitteln Sie einen Unterschied zwischen Anfragen, die vom Benutzer initiiert wurden, und solchen, die von einer Website eines Drittanbieters gefälscht wurden. Zu diesem Zweck fungiert das CSRF-Token als ein Geheimnis, das nur dem Server und dem Benutzer bekannt ist. Der Server legt das Geheimnis in das Dokument in einer Antwort und erwartet, dass es bei der nächsten Anfrage zurückgesendet wird.

Und da das Geheimnis in das Antwortdokument eingebettet ist, das für diesen bestimmten Benutzer zugewiesen ist, muss ein Angreifer diese spezifische Antwort abhören oder auf andere Weise auf das Dokument zugreifen. Es gibt sicherlich Angriffe bekommen die CSRF-Token (z. B. eavesdropping, MITM, XSS, etc.). Wenn Sie jedoch vor diesen Angriffen geschützt sind, kann ein Angreifer keine authentische Anfrage fälschen.

Answer 2

CSRF-Angriff

ich Dich in Betrachtung eine Webseite verleiten, wo ich einige Codes eingefügt (eine Anforderung, in der Regel durch img oder form) an einem anderen Ort (wo Sie möglicherweise einige Rechte haben).

Innocuous Beispiel

<img src="http://www.yoursite.net/changelanguage?lang=fr"> 

Ich änderte grausam die Sprache Ihrer Sitzung auf französisch. Oh nein! Sie können den csrf-Schutz sicher entfernen und einen db-Treffer speichern.

Gefährliche Beispiele

<img src="http://www.yourbank.net/sendmoney?amt=9999&account=123> 

Wenn Sie in yourbank.net angemeldet wurden (und es hat keine csrf oder anderen Schutz), sollten Ihr Konto fühlen jetzt leichter. (Ich bin 123.)

<img src="http://www.yoursite.net/admin/users/123/edit?admin=1"> 

Wenn Sie in yoursite.net als Administrator angemeldet waren, dann sind wir beide. (Ich bin 123.)