Frage Verstehen des Rails Authenticity Tokens


Ich stoße auf einige Probleme bezüglich des Echtheitstokens in Rails, wie ich es schon oft habe.

Aber ich möchte wirklich nicht nur dieses Problem lösen und weitermachen. Ich würde gerne das Authenticity Token verstehen. Nun, meine Frage ist, haben Sie eine vollständige Quelle von Informationen zu diesem Thema oder würden Sie Ihre Zeit verbringen, um hier im Detail zu erklären?


877
2018-06-02 20:01


Ursprung


Antworten:


Was geschieht

Wenn der Benutzer ein Formular anzeigt, um eine Ressource zu erstellen, zu aktualisieren oder zu löschen, erstellt die Rails-App eine zufällige Datei authenticity_token, speichert dieses Token in der Sitzung und platziert es in einem ausgeblendeten Feld im Formular. Wenn der Benutzer das Formular absendet, sucht Rails nach dem authenticity_token, vergleicht es mit dem in der Sitzung gespeicherten, und wenn sie übereinstimmen, kann die Anfrage fortgesetzt werden.

Warum es passiert

Da das Authentizitätstoken in der Sitzung gespeichert ist, kann der Client seinen Wert nicht kennen. Dies verhindert, dass Benutzer Formulare an eine Rails-App senden, ohne das Formular in dieser App selbst anzuzeigen. Stellen Sie sich vor, Sie verwenden Service A, Sie haben sich in den Service eingeloggt und alles ist in Ordnung. Stellen Sie sich nun vor, dass Sie Service B benutzt haben und ein Bild gesehen haben, das Ihnen gefällt und auf das Bild gedrückt hat, um es größer zu sehen. Nun, wenn böser Code auf Dienst B war, könnte er eine Anfrage an Dienst A senden (an der Sie angemeldet sind) und Sie bitten, Ihr Konto zu löschen, indem Sie eine Anfrage an senden http://serviceA.com/close_account. Dies ist, was bekannt ist als CSRF (Cross Site Request Forgery).

Wenn Dienst A Authentizitätstoken verwendet, ist dieser Angriffsvektor nicht mehr anwendbar, da die Anforderung von Dienst B das korrekte Authentizitätstoken nicht enthält und nicht fortgesetzt werden kann.

API-Dokumente beschreibt Details zum Meta-Tag:

Der CSRF-Schutz ist mit der protect_from_forgery Methode,   welches das Token überprüft und die Sitzung zurücksetzt, wenn es nicht mit was übereinstimmt   war erwartet. Ein Aufruf dieser Methode wird für neue Rails generiert   Anwendungen standardmäßig.   Der Token-Parameter wird benannt authenticity_token standardmäßig. Der Name   und der Wert dieses Tokens muss jedem Layout hinzugefügt werden, das rendert   Formen durch Einbeziehung csrf_meta_tags im HTML-Kopf.

Anmerkungen

Beachten Sie, dass Rails nur nicht idempotente Methoden überprüft (POST, PUT / PATCH und DELETE). GET-Anforderung wird nicht auf Authentizitätstoken überprüft. Warum? weil die HTTP-Spezifikation besagt, dass GET-Anfragen idempotent sind und sollten nicht Ressourcen auf dem Server erstellen, ändern oder zerstören, und die Anforderung sollte idempotent sein (wenn Sie denselben Befehl mehrmals ausführen, sollten Sie jedes Mal das gleiche Ergebnis erhalten).

Auch die eigentliche Implementierung ist, wie eingangs definiert, etwas komplizierter und sorgt für mehr Sicherheit. Rails gibt nicht das gleiche gespeicherte Token mit jedem Formular aus. Es erzeugt und speichert auch nicht jedes Mal ein anderes Token. Es generiert und speichert einen kryptografischen Hash in einer Sitzung und gibt jedes Mal, wenn eine Seite gerendert wird, neue kryptografische Tokens aus, die mit den gespeicherten verglichen werden können. Sehen request_forgery_protection.rb.

Unterricht

Benutzen authenticity_token um Ihre nicht idempotenten Methoden zu schützen (POST, PUT / PATCH und DELETE). Stellen Sie außerdem sicher, dass keine GET-Anforderungen zulässig sind, die Ressourcen auf dem Server möglicherweise ändern könnten.


BEARBEITEN: Prüfen der Kommentar von @erturne GET-Anfragen sind idempotent. Er erklärt es besser als ich es hier getan habe.


1371
2017-10-15 11:52



Der Authentizitätstoken ist so konzipiert, dass Sie wissen, dass Ihr Formular von Ihrer Website stammt. Es wird von der Maschine generiert, auf der es ausgeführt wird, mit einer eindeutigen Kennung, die nur Ihre Maschine kennt, und hilft so, Cross-Site-Request-Forgery-Angriffe zu verhindern.

Wenn Sie nur Schwierigkeiten mit den Rails haben, die Ihren AJAX-Skript-Zugriff verweigern, können Sie verwenden

<%= form_authenticity_token %>

um das richtige Token zu generieren, wenn Sie Ihr Formular erstellen.

Sie können mehr darüber in der Dokumentation.


129
2018-06-02 20:16



Was ist CSRF?

Das Authenticity Token ist eine Gegenmaßnahme zu Cross-Site Request Forgery (CSRF). Was ist CSRF, fragen Sie?

Auf diese Weise kann ein Angreifer möglicherweise Sitzungen entführen, ohne die Sitzungs-Tokens zu kennen.

Szenario:

  • Besuchen Sie die Seite Ihrer Bank, loggen Sie sich ein.
  • Dann besuchen Sie die Website des Angreifers (z. B. gesponserte Anzeige von einer nicht vertrauenswürdigen Organisation).
  • Die Angreifer-Seite enthält ein Formular mit den gleichen Feldern wie das Formular "Transfer Funds" der Bank.
  • Angreifer kennt Ihre Kontoinformationen und hat vorgefüllte Formularfelder, um Geld von Ihrem Konto auf das Konto des Angreifers zu übertragen.
  • Angreifer-Seite enthält Javascript, das das Formular an Ihre Bank übermittelt.
  • Wenn das Formular übermittelt wird, enthält der Browser Ihre Cookies für die Banksite einschließlich des Sitzungstokens.
  • Bank transferiert Geld auf das Konto des Angreifers.
  • Das Formular kann sich in einem unsichtbaren iframe befinden, sodass Sie nie wissen, dass der Angriff stattgefunden hat.
  • Dies wird als Cross-Site Request Forgery (CSRF) bezeichnet.

CSRF-Lösung:

  • Der Server kann Formulare markieren, die vom Server selbst stammen
  • Jedes Formular muss ein zusätzliches Authentifizierungstoken als verstecktes Feld enthalten.
  • Token muss unvorhersehbar sein (Angreifer kann es nicht erraten).
  • Der Server stellt gültige Token in Formularen auf seinen Seiten bereit.
  • Der Server überprüft das Token, wenn das Formular gepostet wird, und lehnt Formulare ohne korrektes Token ab.
  • Beispiel-Token: Sitzungs-ID, die mit dem geheimen Schlüssel des Servers verschlüsselt ist.
  • Rails generiert automatisch solche Tokens: siehe Eingabefeld authenticity_token in jedem Formular.

77
2018-06-13 01:54



Minimales Angriffsbeispiel, das verhindert werden würde

Auf meiner Website evil.com Ich überzeuge Sie, das folgende Formular einzureichen:

<form action="http://bank.com/transfer" method="post">
  <p><input type="hidden" name="to"      value="ciro"></p>
  <p><input type="hidden" name="ammount" value="100"></p>
  <p><button type="submit">CLICK TO GET PRIZE!!!</button></p>
</form>

Wenn Sie über Session-Cookies bei Ihrer Bank angemeldet sind, werden die Cookies gesendet und die Übertragung erfolgt, ohne dass Sie es überhaupt merken.

Das ist, wenn das CSRF-Token ins Spiel kommt:

  • Mit der GET-Antwort, die das Formular zurückgegeben hat, sendet Rails einen sehr langen zufälligen versteckten Parameter
  • Wenn der Browser die POST-Anfrage macht, sendet er den Parameter mit, und der Server akzeptiert ihn nur, wenn er übereinstimmt

So würde das Formular auf einem authentischen Browser aussehen:

<form action="http://bank.com/transfer" method="post">
  <p><input type="hidden" name="authenticity_token" value="j/DcoJ2VZvr7vdf8CHKsvjdlDbmiizaOb5B8DMALg6s=" ></p>
  <p><input type="hidden" name="to"                 value="ciro"></p>
  <p><input type="hidden" name="ammount"            value="100"></p>
  <p><button type="submit">Send 100$ to Ciro.</button></p>
</form>

Somit würde mein Angriff fehlschlagen, da er nicht gesendet wurde authenticity_token Parameter, und ich konnte es auf keinen Fall erraten haben, da es eine riesige Zufallszahl ist.

Diese Präventionstechnik wird genannt Synchronisations-Token-Muster.

Das Synchronizer Token Pattern funktioniert wegen der Gleiche Ursprungsrichtlinie: wenn ich eine XHR GET Anfrage an deine Bank machen könnte evil.com, und lesen Sie das Ergebnis, ich könnte nur ein Token lesen und dann die Anfrage später machen. Ich habe das weiter erklärt unter: https://security.stackexchange.com/a/72569/53321

Ich empfehle Ihnen sehr zu lesen der OWASP-Leitfaden, zu dieser und jeder anderen Sicherheitsfrage.

Wie Rails die Tokens sendet

Abgedeckt bei: Rails: Wie funktioniert csrf_meta_tag?

Grundsätzlich gilt:

  • HTML-Helfer mögen form_tag Fügen Sie dem Formular ein verstecktes Feld für das Formular hinzu, wenn es sich nicht um ein GET-Formular handelt

  • AJAX wird automatisch von behandelt jquery-ujs, die das Token aus dem liest meta Elemente, die Ihrer Kopfzeile hinzugefügt wurden csrf_meta_tags (in der Standardvorlage vorhanden) und fügt sie zu jeder Anfrage hinzu.

    uJS versucht auch das Token in Formularen in veralteten, zwischengespeicherten Fragmenten zu aktualisieren.

Andere Präventionsansätze


36
2017-11-12 20:30



Das Authenticity Token ist rails 'Methode zu verhindern  "Cross-Site Request Forgery (CSRF oder XSRF) Angriffe".

Um es einfach zu machen, es stellt sicher, dass die PUT / POST / DELETE (Methoden, die Inhalt ändern) Anforderungen an Ihre Web-App aus dem Browser des Clients und nicht von einem Dritten (einem Angreifer), der Zugriff auf ein Cookie erstellt hat auf der Client-Seite.


35
2018-06-02 20:17



schon seit Authenticity Token ist so wichtig, und in Rails 3.0+ können Sie verwenden

 <%= token_tag nil %>

erschaffen

<input name="authenticity_token" type="hidden" value="token_value">

irgendwo


32
2017-08-01 05:12



Vorsicht vor dem Authenticity Token-Mechanismus kann zu Race-Bedingungen führen, wenn Sie mehrere gleichzeitige Anfragen vom selben Client haben. In diesem Fall kann Ihr Server mehrere Authentizitätstokens generieren, wenn nur eines vorhanden sein sollte, und der Client, der das frühere Token in einem Formular empfängt, schlägt bei der nächsten Anforderung fehl, weil das Sitzungscookie-Token überschrieben wurde. Es gibt eine Beschreibung zu diesem Problem und eine nicht ganz triviale Lösung hier: http://www.paulbutcher.com/2007/05/race-conditions-in-rails-sessions-and-how-to-fix-them/


25
2017-08-30 23:52



Das Authentizitätstoken wird verwendet, um Cross-Site-Request-Forgery-Angriffe (CSRF) zu verhindern. Um das Authentizitätstoken zu verstehen, müssen Sie zuerst CSRF-Angriffe verstehen.

CSRF

Angenommen, Sie sind der Autor von bank.com. Sie haben ein Formular auf Ihrer Website, mit dem Geld mit einer GET-Anfrage an ein anderes Konto überwiesen wird:

enter image description here

Ein Hacker könnte einfach eine HTTP-Anfrage an den Server senden GET /transfer?amount=$1000000&account-to=999999, Recht?

enter image description here

Falsch. Der Hackerangriff wird nicht funktionieren. Der Server wird grundsätzlich denken?

Hä? Wer versucht diesen Transfer zu initiieren? Es ist nicht der Besitzer des Kontos, das ist sicher.

Wie weiß der Server das? Weil es keine gibt session_id Cookie, der den Anforderer authentifiziert.

Wenn Sie sich mit Ihrem Benutzernamen und Ihrem Passwort anmelden, setzt der Server ein session_id Cookie in Ihrem Browser Auf diese Weise müssen Sie nicht jede Anfrage mit Ihrem Benutzernamen und Passwort authentifizieren. Wenn Ihr Browser die session_id Cookie, der Server weiß:

Oh, das ist John Doe. Er hat sich vor 2,5 Minuten erfolgreich angemeldet. Es ist gut zu gehen.

Ein Hacker könnte denken:

Hmm. Eine normale HTTP-Anfrage wird nicht funktionieren, aber wenn ich meine Hand darauf bekommen könnte session_id Keks, ich wäre golden.

Der Browser des Benutzers hat eine Reihe von Cookies für die bank.com Domain. Jedes Mal, wenn der Benutzer eine Anfrage an die bank.com Domain werden alle Cookies gesendet. Einschließlich der session_id Plätzchen.

Also wenn ein Hacker kommen könnte Sie Um die GET-Anfrage zu machen, die Geld auf sein Konto überweist, wäre er erfolgreich. Wie konnte er dich dazu bringen, das zu tun?  Mit Cross Site Request Forgery.

Es ist ziemlich einfach, eigentlich. Der Hacker könnte Sie einfach dazu bringen, seine Website zu besuchen. Auf seiner Website könnte er folgendes Bild-Tag haben:

<img src="http://bank.com/transfer?amount=$1000000&account-to=999999">

Wenn der Benutzer-Browser auf dieses Image-Tag stößt, wird eine GET-Anfrage an diese URL gesendet. Und da die Anfrage von seinem Browser kommt, werden alle damit verbundenen Cookies mitgeschickt bank.com. Wenn der Benutzer sich kürzlich angemeldet hat bank.com... das session_id Cookie wird gesetzt, und der Server wird denken, dass der Benutzer $ 1.000.000 auf Konto 999999 übertragen wollte!

enter image description here

Nun, besuchen Sie keine gefährlichen Seiten und es wird Ihnen nichts passieren.

Das ist nicht genug. Was ist, wenn jemand dieses Bild auf Facebook veröffentlicht und es an deiner Wand erscheint? Was passiert, wenn es in eine Website eingefügt wird, die Sie mit einem XSS-Angriff besuchen?

Es ist nicht so schlecht. Nur GET-Anfragen sind anfällig.

Nicht wahr. Ein Formular, das eine POST-Anfrage sendet, kann dynamisch generiert werden. Hier ist das Beispiel von der Schienen-Führer auf Sicherheit:

<a href="http://www.harmless.com/" onclick="
  var f = document.createElement('form');
  f.style.display = 'none';
  this.parentNode.appendChild(f);
  f.method = 'POST';
  f.action = 'http://www.example.com/account/destroy';
  f.submit();
  return false;">To the harmless survey</a>

Authentizitätstoken

Wenn dein ApplicationController hat das:

protect_from_forgery with: :exception

Dies:

<%= form_tag do %>
  Form contents
<% end %>

Ist in diesem zusammengefasst:

<form accept-charset="UTF-8" action="/" method="post">
  <input name="utf8" type="hidden" value="&#x2713;" />
  <input name="authenticity_token" type="hidden" value="J7CBxfHalt49OSHp27hblqK20c9PgwJ108nDHX/8Cts=" />
  Form contents
</form>

Insbesondere wird Folgendes generiert:

<input name="authenticity_token" type="hidden" value="J7CBxfHalt49OSHp27hblqK20c9PgwJ108nDHX/8Cts=" />

Zum Schutz vor CSRF-Angriffen wird Rails das Authentifizierungs-Token, das mit einer Anfrage gesendet wurde, nicht als sicher betrachten.

Wie soll ein Angreifer wissen, was dieser Token ist? Bei jeder Generierung des Formulars wird ein anderer Wert zufällig generiert:

enter image description here

Ein Cross Site Scripting (XSS) Angriff - so. Aber das ist eine andere Schwachstelle für einen anderen Tag.


23
2018-04-14 04:33



Methoden Wo? authenticity_token Wird benötigt

authenticity_token wird bei idempotenten Methoden wie post, put und delete benötigt, da sich die Idempotenten Methoden auf die Daten auswirken.

Warum ist es erforderlich?

Es ist notwendig, vor bösen Aktionen zu schützen. authenticity_token wird in der Sitzung gespeichert, sobald ein Formular auf Webseiten zum Erstellen oder Aktualisieren von Ressourcen erstellt wird, wird ein Authentizitätstoken in einem versteckten Feld gespeichert und mit dem Formular auf dem Server gesendet. Vor der Ausführung der Aktion wird der Benutzer authenticity_token überprüft authenticity_token in der Sitzung gespeichert. Ob authenticity_token ist gleich, dann wird der Prozess fortgesetzt, andernfalls führt er keine Aktionen aus.


8
2018-02-26 11:13



Was ist ein authentication_token?

Dies ist eine zufällige Zeichenfolge, die von der Rails-Anwendung verwendet wird, um sicherzustellen, dass der Benutzer eine Aktion von der App-Seite anfordert oder ausführt, nicht von einer anderen App oder Site.

Warum ist ein authentication_token notwendig?

So schützen Sie Ihre App oder Site vor einer siteübergreifenden Anfragefälschung.

Wie füge ich ein authentication_token zu einem Formular hinzu?

Wenn Sie ein Formular mit form_for tag generieren, wird automatisch ein authentication_token hinzugefügt, das Sie verwenden können <%= csrf_meta_tag %>.


3
2017-07-22 02:02