Wozu Laravel Ajax X-CSRF-TOKEN?
Hallo, kennt sich jemand mit dem dem X-CSRF-Token im Php Laravel Framework aus?
Im HTML:
<meta name="_token" content="{{csrf_token()}}">
Ich benutze dieses Token zum Beispiel in einem Ajax Post Request wie hier im Header:
$.ajaxSetup({
headers: {
'X-CSRF-TOKEN': $('meta[name="_token"]').attr('content')
}
});
Danach folgt dann der eigentliche Post Request.
Dieses Token soll wohl Sicherheit bieten, damit niemand von einer anderen Seite Daten an mein Backend senden kann, der nicht das Token mitsendet. Leider verstehe ich nicht, wie das funktionieren soll, weil man das Token ja im Quelltext sehen kann. Könnte man es nicht einfach im Header mitsenden und damit den Schutz umgehen? Also ich blicke da nicht so richtig durch...
Dankeschön, Fabian
3 Antworten
Das könnte man meinen, so ist es aber nicht.
Der Token ist an die Session gebunden. Ein Angreifer müsste nicht nur den Token kennen, sondern auch Zugriff auf die aktuelle Benutzersession haben.
Da sich der Token bei jedem Request verändert und immer nur ein Teil des Sicherheitsmechanismus darstellt, ist der Token allein wertlos.
Dieses Token ist dazu da, damit nicht jemand über die Aktion eines anderen Nutzers Daten an deine Webseite schicken kann. Stell dir beispielsweise vor, jemand baut deine Webseite Eins-zu-eins nach und lotst einen deiner Nutzer auf diese Seite. Sobald der Nutzer auf einen Button o.ä. klickt, wird ein Request an deinen Server geschickt, welcher zum Beispiel den Kauf eines Produkts anfordert. Dieser Fall indirekten Zugriffs soll verhindert werden.
Ein CSRF-Token schützt davor, denn er wird individuell (und eindeutig) für den Nutzer generiert und mit der Nutzersession verknüpft. Ein Angreifer müsste Zugriff auf das System/den Browser/das Dokument selbst (welches dem Nutzer zugespielt wurde) erlangen, um den richtigen Token zu erhalten. Zudem ist die Zeitspanne, in der er den Token nutzen kann, begrenzt.
Bei Aufruf einer Formularseite beispielsweise (der klassische Anwendungsfall) wird auf Serverseite ein individueller Nutzertoken generiert und im Formular (meist in einem Hidden-Feld) platziert. Ebenso merkt sich die Anwendung den Token innerhalb der Nutzersession (also z.B. einem Sessioncookie). Nach dem Datenversand prüft der Server, ob die beiden Tokens aus Formular und Sessioncookie übereinstimmen.
Selbst wenn ein Nutzer seinen Token aus dem Markup ausliest und in die große Welt hinausposaunt, hätte ein Angreifer noch zwei Probleme: Er müsste Zugriff auf die explizite Session erlangen, denn die muss ja auch noch zufriedengestellt werden. Zum anderen würde eine Anfrage von einer anderen Domain aus innerhalb des Browsers blockiert werden (Stichwort CORS; außer dein Server erlaubt einfach alle externen Aufrufe und filtert auch später nicht).
Hi protonfab,
allgemein ein Sicherheitstoken besteht immer aus einem Token der ausgegeben wird im generierten HTML-Dokument und der Gegenteil der serverseitig generiert als Session gespeichert wird. Dieser ändert sich wenn die Seite neu geladen wird und verhindert das Angreifer via Request mit Datenmüll whatever, den Server angreift.
Serverseitig werden beide Werte verglichen und bei nicht gleichen Werten wird der HTTP-Request ignoriert und eventuell wird bei einer Flut an Anfragen, etc. der Client blockiert.
Ok, die Sache ist ja, dass ich mit Ajax poste. D.h. es ist ja kein herkömmliches Formular, weil da könnte man ja jedes mal, wenn die HTML Seite generiert wird auch eine neues Token generieren.
Ajax ist ein anderer Begriff für einen HTTP-XML-Request. Auch diese sollten gesichert werden und einen Token zurück an den Server schicken um die Werte zu vergleichen. Und wenn du eine neue Seite generierst erneuert sich auch der Sicherheitstoken.
Naja, so richtig geschnallt habe ich es immer noch nicht, aber ich verstehe worauf es hinaus läuft. Das Token ist ja im Quellcode der Seite sichtbar, wenn man sich den im Browser ausgeben lässt.