Warum CSRF-Token sollte in Meta-Tag und in Cookie sein?

Question

Was die Notwendigkeit zu setzen CSRF-Token Namen und den Wert innerhalb <Kopf>-Tag <meta> wie ist:

zB:

<meta content="authenticity_token" name="csrf-param" /> 
<meta content="4sWPhTlJAmt1IcyNq1FCyivsAVhHqjiDCKRXOgOQock=" name="csrf-token" /> 

ich gelesen habe über Konzept Halten Sie CSRF-Wert in Cookie, aber nicht finden, warum in <Kopf> Tag zu halten.

Answer 1

Um prevent CSRF benötigen Sie einen Wert, der mit der Anforderung übermittelt wird, die nicht von einer bösartigen Website gesendet werden kann. Authentifizierungscookies sind nicht geeignet, denn wenn ein Angreifer den Browser dazu veranlassen kann, eine Anfrage an die Opferseite zu senden, werden die Cookies automatisch übermittelt.

Zum Beispiel, indem ein Formular über JavaScript auf www.evil.com enthaltenen Vorlage der Sitzung des Benutzers auf www.example.com angreifen:

<form method="post" action="https://www.example.com/executeAction"> 
    <input type="hidden" name="action" value="deleteAllUsers"> 
</form> 

<script>document.forms[0].submit()</script> 

Speichern eines anti CRSF Token innerhalb der Seite ist die OWASP empfohlene Lösung zur Verhinderung einer anderen Website von der Abgabe Das Formular, da das zufällige Token in der Sitzung des Benutzers nicht von www.evil.com aufgrund der Same Origin Policy verhindert JavaScript unter www.evil.com Lesen des Seiteninhalts von www.example.com gelesen werden kann.

Diese Tokens können an beliebiger Stelle auf der Seite gespeichert werden. Am häufigsten wird es innerhalb versteckter Formularfelder sein, aber sie könnten auch innerhalb HTML 5 data- attributes gespeichert werden. Es scheint, als ob die Verwendung von meta Tags ist einfach eine andere Möglichkeit, es gespeichert werden kann, wo das JavaScript kann es in Form von Übermittlungen der Seite enthalten.

Answer 2

Die einzige Option, die ich mir vorstellen könnte, ist, diese Daten von JavaScript zugänglich zu machen. Nur für den Fall, dass die Cookies nur http sind.

Answer 3

Das liegt daran, dass es nichts gibt, was eine anstößige Website daran hindert, Daten an eine legitime Website zu senden, die Ihr Authentifizierungsticket und Ihr CSRF-Token enthalten könnte. Stellen Sie sich dieses Szenario ... von ASP.NET

1. Ein Benutzer meldet sich auf www.siteA.com, mit Formularauthentifizierung.
2. Der Server authentifiziert den Benutzer. Die Antwort vom Server enthält einen Authentifizierungscookie.

3. Ohne Abmelden besucht der Benutzer eine bösartige Website. Diese bösartige Website enthält das folgende HTML-Formular:

   <h1>You Are a Winner!</h1> 
       <form action="http://siteA.com/api/account" method="post"> 
        <input type="hidden" name="Transaction" value="withdraw" /> 
        <input type="hidden" name="Amount" value="1000000" /> 
   <input type="submit" value="Click Me"/> 
       </form> 
   

Beachten Sie, dass die Form Aktion Beiträge an die betroffenen Site, nicht auf die bösartige Site. Dies ist der "Cross-Site" -Teil von CSRF.

Der Benutzer klickt auf die Schaltfläche Senden. Der Browser enthält das Authentifizierungs-Cookie mit der Anfrage. Die Anforderung wird auf dem Server mit dem Authentifizierungskontext des Benutzers ausgeführt und kann alles ausführen, was ein authentifizierter Benutzer ausführen darf.

Wenn sitesA.com den CSRF-Angriff empfängt, sollte es also im Grunde das CSRF-Token im Cookie mit dem im Meta-Tag übereinstimmen. Eine legitime Anfrage enthält beide, ein Fälschungsangriff umfasst jedoch nur das im Cookie angegebene CSRF-Token.

Answer 4

CSRF-Tokens werden normalerweise in Form verborgener Formularfelder angezeigt. Es ist nur sinnvoll, sie in ein Meta-Tag einzufügen, wenn Sie JavaScript verwenden. JavaScript könnte die Token vom Meta-Tag lesen und sie an eine Aktion senden.

Sie möchten kein CSRF-Token in einen Cookie einfügen, da der Cookie unabhängig von seiner Herkunft für jede Anfrage an die spezifische Website vom Webbrowser gesendet wird. Die einzige Ausnahme wären sichere Cookies, die der gleichen Ursprungsrichtlinie folgen sollen.