django-forms - Wie man curl mit Django, csrf Tokens und POST Anfragen benutzt





django-csrf (6)


curl-auth-csrf ist ein Python-basiertes Open-Source-Tool, das dies für Sie curl-auth-csrf kann: "Python-Tool, das cURL nachahmt, aber eine Anmeldung durchführt und Cross-Site Request Forgery (CSRF) -Token verarbeitet. Nützlich für das normale Scraping von HTML nur zugänglich wenn eingeloggt. "

Das wäre deine Syntax:

echo -n YourPasswordHere | ./curl-auth-csrf.py -i http://127.0.0.1:8083/registrations/register/ -d '[email protected]&a=1' http://127.0.0.1:8083/registrations/register/

Dies wird die POST-Daten wie aufgelistet weitergeben, aber auch das über stdin übergebene Passwort enthalten. Ich gehe davon aus, dass die Seite, die Sie nach "Login" besuchen, dieselbe Seite ist.

Vollständige Offenlegung: Ich bin der Autor von curl-auth-csrf.

Ich benutze Curl, um eine meiner Django-Formen zu testen. Die Anrufe, die ich versucht habe (mit Fehlern von jedem, und über mehrere Zeilen für die Lesbarkeit):

(1):

curl
-d "{\"email\":\"[email protected]\"}"
--header "X-CSRFToken: [triple checked value from the source code of a page I already loaded from my Django app]"
--cookie "csrftoken=[same csrf value as above]"
http://127.0.0.1:8083/registrations/register/

(mit HTTP-Header und csrftoken in Cookie) führt zu einem Fehler 400 ohne Daten zurückgegeben.

(2):

curl
-d "{a:1}"
--header "X-CSRFToken:[as above]"
--cookie "csrftoken=[as above];sessionid=[from header inspection in Chrome]"
http://127.0.0.1:8083/registrations/register/

(wie in (1), aber keine Leerzeichen in der Deklaration der Header-Eigenschaften und auch in der sessionid im Cookie) führt zu demselben 400-Fehler, bei dem keine Daten zurückgegeben werden.

(3):

curl
-d "{a:1}"
--header "X-CSRFToken:[as above]"
http://127.0.0.1:8083/registrations/register/

(nur http-Header mit X-CSRFToken , kein Cookie) führt zum Fehlercode 403, mit der Meldung: CSRF-Cookie nicht gesetzt.

Wie kann ich meine Form mit Curl testen? Welche Faktoren betrachte ich neben Cookie-Werten und http-Headern nicht?




X-CSRFToken in Kopfzeilen müssen nur mit csrftoken in cookie csrftoken .

Beispiel:

curl -v http://www.markjour.com/login/ -H "X-CSRFToken: 123" -b "csrftoken=123" -d "username=admin&password=admin"



Hier ist, wie ich es gemacht habe, mit dem Rest Framework Tutorial

Öffnen Sie einen Browser, zB chrome, drücken Sie F12, öffnen Sie die Entwickler-Registerkarte und überwachen Sie das Netzwerk, melden Sie sich mit Ihren Benutzerdaten an und lassen Sie Ihr CRSF-Token von der Überwachung des POST abhalten

dann in curl ausführen:

curl http://127.0.0.1:8000/snippets/ \
 -X POST \
 -H "Content-Type: application/json" \
 -H "Accept: text/html,application/json" \
 -H "X-CSRFToken: the_token_value" \
 -H "Cookie: csrftoken=the_token_value" \
 -u your_user_name:your_password \
 -d '{"title": "first cookie post","code": "print hello world"}' 

Ich denke, es ist sauberer, den Token nicht in den Körper zu setzen, sondern den Header mit X-CSRFToken




Versuchen:

curl
 -d "[email protected]&a=1"
 http://127.0.0.1:8083/registrations/register/

Beachten Sie insbesondere das Format des Arguments -d .

Dies wird jedoch wahrscheinlich nicht funktionieren, da Ihre Ansicht wahrscheinlich eine POST-Anfrage statt einer GET-Anfrage benötigt. Da Daten geändert werden, werden nicht nur Informationen zurückgegeben.

CSRF-Schutz wird nur für 'unsichere' Anfragen benötigt (POST, PUT, DELETE). Es funktioniert, indem Sie das "csrftoken" Plätzchen gegen das "csrfmiddlewaretoken" Formularfeld oder den "X-CSRFToken" http-Überschrift prüfen.

Damit:

curl
 -X POST
 -d "[email protected]&a=1&csrfmiddlewaretoken={inserttoken}"
 --cookie "csrftoken=[as above]"
 http://127.0.0.1:8083/registrations/register/

Es ist auch möglich, --header "X-CSRFToken: {token}" anstatt sie in die Formulardaten aufzunehmen.




Ich habe so mit Curl gearbeitet

  • Sie müssen csrftoken im Header als X-CSRFToken einreichen.
  • Sie müssen Formulardaten im JSON-Format übermitteln. Demo,

Zuerst holen wir csrf_token & store in cookie.txt (oder cookie.jar, wie sie es nennen)

$ curl -c cookie.txt http://localhost.com:8000/ 

cookie.txt Inhalt

# Netscape HTTP Cookie File
# http://curl.haxx.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.
localhost.com  FALSE   /   FALSE   1463117016  csrftoken   vGpifQR12BxT07moOohREGmuKp8HjxaE

Als nächstes senden wir den Benutzernamen, Passwort im JSON-Format. (Sie können es auf normale Weise senden). Überprüfen Sie die JSON-Datenflucht.

$curl --cookie cookie.txt http://localhost.com:8000/login/   -H "Content-Type: application/json" -H "X-CSRFToken: vGpifQR12BxT07moOohREGmuKp8HjxaE" -X POST -d "{\"username\":\"username\",\"password\":\"password\"}" 
{"status": "success", "response_msg": "/"}
$

Sie können den neuen csrf_token Session-Cookie in derselben Datei oder in derselben neuen Datei speichern (ich habe ihn in der gleichen Datei mit der Option -c gespeichert).

$curl --cookie cookie.txt http://localhost.com:8000/login/   -H "Content-Type: application/json" -H "X-CSRFToken: kVgzzB6MJk1RtlVnyzegEiUs5Fo3VRqF" -X POST -d "{\"username\":\"username\",\"password\":\"password\"}" -c cookie.txt

-Content von cookie.txt

# Netscape HTTP Cookie File
# http://curl.haxx.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.

localhost.com  FALSE   /   FALSE   1463117016  csrftoken   vGpifQR12BxT07moOohREGmuKp8HjxaE
#HttpOnly_localhost.com    FALSE   /   FALSE   1432877016  sessionid   cg4ooly1f4kkd0ifb6sm9p

Wenn Sie ein neues Cookie csrf_token & session id in cookie.txt speichern, können Sie dieselbe cookie.txt auf der Website verwenden.

Sie lesen Cookies aus einer früheren Anfrage von cookie.txt (--cookie) und schreiben neue Cookies aus der Antwort in derselben cookie.txt (-c).

Das Formular zum Lesen und Absenden funktioniert nun mit csrf_token & session id.

$curl --cookie cookie.txt http://localhost.com:8000/home/



Ein guter Grund, den Sie angesprochen haben, besteht darin, dass das CSRF-Cookie nach dem Empfang in der gesamten Anwendung im Clientskript für die Verwendung in regulären Formularen und AJAX-POSTs verfügbar ist. Dies wird in einer starken JavaScript-Anwendung wie der von AngularJS sinnvoll sein (die Verwendung von AngularJS erfordert nicht, dass die Anwendung eine Einzelseiten-App ist, also wäre es nützlich, wo der Status zwischen verschiedenen Seitenanforderungen mit dem CSRF-Wert fließen muss) kann normalerweise nicht im Browser bestehen).

Berücksichtigen Sie die folgenden Szenarien und Prozesse in einer typischen Anwendung für einige Vor- und Nachteile der einzelnen Ansätze, die Sie beschreiben. Diese basieren auf dem Synchronizer Token Pattern .

Anfrage Körper Approach

  1. Der Benutzer meldet sich erfolgreich an.
  2. Der Server gibt auth cookie aus.
  3. Der Nutzer klickt, um zu einem Formular zu navigieren.
  4. Wenn er für diese Sitzung noch nicht generiert wurde, generiert der Server das CSRF-Token, speichert es für die Benutzersitzung und gibt es in einem versteckten Feld aus.
  5. Der Benutzer reicht das Formular ein.
  6. Der Server prüft, ob das versteckte Feld mit dem gespeicherten Sitzungs-Token übereinstimmt.

Vorteile:

  • Einfach zu implementieren.
  • Funktioniert mit AJAX.
  • Arbeitet mit Formularen.
  • Cookie kann eigentlich nur HTTP sein .

Nachteile:

  • Alle Formulare müssen das ausgeblendete Feld in HTML ausgeben.
  • Alle AJAX POSTs müssen auch den Wert enthalten.
  • Die Seite muss im Voraus wissen, dass das CSRF-Token erforderlich ist, damit es in den Seiteninhalt aufgenommen werden kann. Daher müssen alle Seiten den Token-Wert irgendwo enthalten, wodurch die Implementierung für eine große Site zeitaufwendig wird.

Benutzerdefinierter HTTP-Header (Downstream)

  1. Der Benutzer meldet sich erfolgreich an.
  2. Der Server gibt auth cookie aus.
  3. Der Nutzer klickt, um zu einem Formular zu navigieren.
  4. Die Seite wird im Browser geladen, und anschließend wird eine AJAX-Anforderung zum Abrufen des CSRF-Tokens ausgeführt.
  5. Der Server generiert ein CSRF-Token (sofern nicht bereits für die Sitzung generiert), speichert es für die Benutzersitzung und gibt es in einen Header aus.
  6. Benutzer reicht Formular ein (Token wird über verstecktes Feld gesendet).
  7. Der Server prüft, ob das versteckte Feld mit dem gespeicherten Sitzungs-Token übereinstimmt.

Vorteile:

  • Funktioniert mit AJAX.
  • Cookie kann nur HTTP sein .

Nachteile:

  • Funktioniert nicht ohne eine AJAX-Anfrage, um den Header-Wert zu erhalten.
  • Alle Formulare müssen den Wert dynamisch zu ihrem HTML hinzugefügt haben.
  • Alle AJAX POSTs müssen auch den Wert enthalten.
  • Die Seite muss zuerst eine AJAX-Anfrage machen, um das CSRF-Token zu erhalten, was jedes Mal eine extra Rundreise bedeutet.
  • Könnte auch einfach das Token auf die Seite ausgeben, die die zusätzliche Anfrage speichern würde.

Benutzerdefinierter HTTP-Header (Upstream)

  1. Der Benutzer meldet sich erfolgreich an.
  2. Der Server gibt auth cookie aus.
  3. Der Nutzer klickt, um zu einem Formular zu navigieren.
  4. Wenn er für diese Sitzung noch nicht generiert wurde, generiert der Server ein CSRF-Token, speichert es für die Benutzersitzung und gibt es irgendwo im Seiteninhalt aus.
  5. Benutzer sendet Formular über AJAX (Token wird über Header gesendet).
  6. Der Server prüft, ob der benutzerdefinierte Header mit dem gespeicherten Sitzungs-Token übereinstimmt.

Vorteile:

  • Funktioniert mit AJAX.
  • Cookie kann nur HTTP sein .

Nachteile:

  • Funktioniert nicht mit Formularen.
  • Alle AJAX-POSTs müssen die Kopfzeile enthalten.

Benutzerdefinierter HTTP-Header (Upstream und Downstream)

  1. Der Benutzer meldet sich erfolgreich an.
  2. Der Server gibt auth cookie aus.
  3. Der Nutzer klickt, um zu einem Formular zu navigieren.
  4. Die Seite wird im Browser geladen, und anschließend wird eine AJAX-Anforderung zum Abrufen des CSRF-Tokens ausgeführt.
  5. Der Server generiert ein CSRF-Token (sofern nicht bereits für die Sitzung generiert), speichert es für die Benutzersitzung und gibt es in einen Header aus.
  6. Benutzer sendet Formular über AJAX (Token wird über Header gesendet).
  7. Der Server prüft, ob der benutzerdefinierte Header mit dem gespeicherten Sitzungs-Token übereinstimmt.

Vorteile:

  • Funktioniert mit AJAX.
  • Cookie kann nur HTTP sein .

Nachteile:

  • Funktioniert nicht mit Formularen.
  • Alle AJAX-POSTs müssen auch den Wert enthalten.
  • Die Seite muss zuerst eine AJAX-Anfrage stellen, um das CRSF-Token zu erhalten, so dass jedes Mal eine zusätzliche Rundreise erfolgen muss.

Set-Cookie

  1. Der Benutzer meldet sich erfolgreich an.
  2. Der Server gibt auth cookie aus.
  3. Der Nutzer klickt, um zu einem Formular zu navigieren.
  4. Der Server generiert das CSRF-Token, speichert es für die Benutzersitzung und gibt es an einen Cookie aus.
  5. Der Benutzer reicht das Formular über AJAX oder über das HTML-Formular ein.
  6. Der Server prüft den benutzerdefinierten Header (oder das ausgeblendete Formularfeld) mit dem gespeicherten Sitzungs-Token.
  7. Cookie ist im Browser für die Verwendung in zusätzlichen AJAX- und Formularanforderungen verfügbar, ohne dass zusätzliche Anforderungen an den Server zum Abrufen des CSRF-Tokens erforderlich sind.

Vorteile:

  • Einfach zu implementieren.
  • Funktioniert mit AJAX.
  • Arbeitet mit Formularen.
  • Es ist nicht unbedingt eine AJAX-Anforderung erforderlich, um den Cookie-Wert zu erhalten. Jede HTTP-Anfrage kann sie abrufen und sie kann über JavaScript an alle Formulare / AJAX-Anfragen angehängt werden.
  • Sobald das CSRF-Token abgerufen wurde, wie es in einem Cookie gespeichert ist, kann der Wert ohne zusätzliche Anforderungen wiederverwendet werden.

Nachteile:

  • Alle Formulare müssen den Wert dynamisch zu ihrem HTML hinzugefügt haben.
  • Alle AJAX POSTs müssen auch den Wert enthalten.
  • Der Cookie wird für jede Anforderung (dh alle GETs für Bilder, CSS, JS usw., die nicht am CSRF-Prozess beteiligt sind) eingereicht, wodurch die Anfragegröße erhöht wird.
  • Cookie kann nicht nur HTTP sein .

Der Cookie-Ansatz ist also ziemlich dynamisch und bietet eine einfache Möglichkeit, den Cookie-Wert (jede HTTP-Anfrage) abzurufen und zu verwenden (JS kann den Wert automatisch jedem Formular hinzufügen und in AJAX-Anfragen entweder als Header oder als Formularwert). Sobald das CSRF-Token für die Sitzung empfangen wurde, muss es nicht neu generiert werden, da ein Angreifer, der einen CSRF-Exploit verwendet, keine Methode zum Abrufen dieses Tokens hat. Wenn ein böswilliger Benutzer versucht, das CSRF-Token des Benutzers in einer der oben genannten Methoden zu lesen, wird dies durch die gleiche Ursprungsrichtlinie verhindert. Wenn ein böswilliger Benutzer versucht, die Seite des CSRF-Tokenservers abzurufen (z. B. via curl ), wird dieses Token nicht mit demselben Benutzerkonto verknüpft, da das Authentifizierungssitzungscookie des Opfers in der Anfrage fehlt (es wäre also der Angreifer) wird der Serverseite nicht mit der Sitzung des Opfers assoziiert).

Neben dem Synchronizer-Token-Muster gibt es auch die Double-Submit-Cookie- CSRF-Verhinderungsmethode, die natürlich Cookies verwendet, um einen Typ eines CSRF-Tokens zu speichern. Dies ist einfacher zu implementieren, da für den CSRF-Token kein serverseitiger Status erforderlich ist. Das CSRF-Token könnte tatsächlich der Standard-Authentifizierungscookie sein, wenn diese Methode verwendet wird, und dieser Wert wird wie üblich mit Cookies übermittelt, aber der Wert wird auch in einem versteckten Feld oder Header wiederholt, von dem ein Angreifer nicht replizieren kann Sie können den Wert überhaupt nicht lesen. Es wird jedoch empfohlen, einen anderen Cookie als den Authentifizierungscookie zu wählen, damit der Authentifizierungscookie mit HttpOnly geschützt werden kann. Dies ist ein weiterer häufiger Grund, warum Sie CSRF-Prävention mit einer Cookie-basierten Methode finden.





django curl django-forms csrf django-csrf