CSRF-Schutz ist aufgrund der Richtlinie gleichen Ursprungs nur für Operationen zur Änderung des Status erforderlich. Diese Richtlinie besagt, dass:

ein Webbrowser Skripten auf einer ersten Webseite den Zugriff auf Daten auf einer zweiten Webseite ermöglicht, jedoch nur, wenn beide Webseiten denselben Ursprung haben.

Der CSRF-Angriff kann also nicht auf die angeforderten Daten zugreifen, da es sich um eine standortübergreifende Anforderung handelt (dies ist die CS in CSRF ) und durch die Politik des gleichen Ursprungs verboten. Daher ist der illegale Datenzugriff bei CSRF kein Problem.

Da ein CSRF-Angriff Befehle ausführen kann, deren Ergebnisse jedoch nicht angezeigt werden können, muss er blind handeln. Beispielsweise kann ein CSRF-Angriff Ihren Browser anweisen, Ihren Kontostand anzufordern, dieser Kontostand kann jedoch nicht angezeigt werden. Dies ist offensichtlich ein sinnloser Angriff (es sei denn, Sie versuchen, den Bankserver oder etwas anderes zu DDoS). Es ist jedoch nicht sinnlos, wenn beispielsweise der CSRF-Angriff Ihren Browser anweist, Ihre Bank anzuweisen, Geld von Ihrem Konto auf das Konto des Angreifers zu überweisen. Auf die Erfolgs- oder Fehlerseite für die Übertragung kann das angreifende Skript nicht zugreifen. Zum Glück für den Angreifer müssen sie die Antwort der Bank nicht sehen, sie wollen nur das Geld auf ihrem Konto haben.

Da wahrscheinlich nur Operationen zur Änderung des Zustands Ziel von CSRF-Angriffen sind, benötigen nur sie CSRF-Verteidigung.

Normalerweise sichere Methoden müssen nicht vor CSRF geschützt werden, da sie keine Änderungen an der Anwendung vornehmen. Selbst wenn sie vertrauliche Informationen zurückgeben, wird dies durch die Gleiche geschützt Ursprungsrichtlinie im Browser.

Wenn Ihre Site gemäß den Standards implementiert ist, sollten Ihre GET-Anforderungen sicher sein und daher keinen Schutz benötigen.

Dies ist jedoch der Fall Ein spezieller Fall, in dem ein "Cross-Site DoS" ^{* sup> -Angriff ausgeführt werden könnte. Angenommen, die Ausführung Ihrer Berichtsseite dauert 10 Sekunden, wobei 100% der CPU auf Ihrem Datenbankserver und 80% der CPU auf Ihrem Webserver ausgelastet sind.}

Benutzer Ihrer Website wissen, dass sie niemals zu https wechseln müssen : //yoursite.example.org/Analysis/GetReport während der Bürozeiten, da dadurch der Server zerstört und andere Benutzer eine schlechte Benutzererfahrung erhalten.

Allerdings Chuck möchte Ihre yoursite.example.org Website offline schalten, weil er Sie oder Ihr Unternehmen nicht mag.

In dem geschäftigen Forum, in dem er häufig Beiträge veröffentlicht, http: //forum.walkertexasranger.example.com setzt er seine Signatur auf Folgendes:

  <img src = "https://yoursite.example.org/Analysis/GetReport" width = 0 height = 0 / >  

Er weiß auch, dass Ihre Unternehmensmitarbeiter das Forum häufig besuchen, während sie gleichzeitig bei yoursite.example.org angemeldet sind.

Jedes Mal, wenn Ihre Mitarbeiter einen Beitrag von Chuck lesen, werden Authentifizierungscookies an https: //yoursite.e gesendet xample.org/Analysis/GetReport , sodass Ihre Site die Anforderung verarbeitet und den Bericht generiert und Ihr System offline geschaltet wird, da die CPU von diesen konstanten Anforderungen beansprucht wird.

Auch wenn die Anforderung dies ist Eine GET-Anfrage, die keine dauerhaften Änderungen an Ihrem System vornimmt (auch als "sicher" bezeichnet). Sie führt tatsächlich dazu, dass Ihr System bei jeder Ausführung heruntergefahren wird. Daher ist es besser, dies mit einer CSRF-Präventionsmethode zu schützen.

^{* XSDoS oder Cross-Site Denial if Service ist eine von mir geprägte Phrase, also googeln Sie nicht danach. sup>}

Der CSRF-Schutz wird nicht zum Schutz von Daten verwendet. Es wird verwendet, um einen Benutzer vor einer unwissentlichen Änderung des Status zu schützen, z. B. vor der Überweisung von Geld oder der Abmeldung von einem Konto.

Wenn Ihre GET-Anforderung also einen Status ändert (der nicht sein sollte), dann Sie sollten CSRF-Schutz haben. Wenn jedoch nur Daten zurückgegeben werden, ist kein CSRF-Schutz erforderlich, da der CSRF-Schutz in diesem Fall nichts schützt.

Es kann hilfreich sein, diese Seite erneut durchzugehen: https: / /www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29

Bei CSRF oder Cross-Site Request Forgery geht es nicht darum, Daten vor dem Abrufen zu schützen, sondern darum, Daten vor Änderungen zu schützen. Dies wird auch als Zustandsänderung bezeichnet. In einer Anwendung können Statusänderungen Profildaten wie die E-Mail-Adresse, das Benutzerkennwort oder die Biografie oder die Überweisung von Geldern enthalten.

GET-Anforderungen müssen für idempotente Anforderungen oder Anforderungen verwendet werden, die den Status nicht ändern. Diese Anforderungen müssen keine Anti-CSRF-Token enthalten.

POST-Anforderungen müssen für nicht idempotente Anforderungen oder Anforderungen verwendet werden, die den Status ändern.

Im Allgemeinen sollten POST-Anforderungen zum Ändern des Status von etwas verwendet werden. Wenn Sie GET-Anforderungen eingerichtet haben, damit diese den Status ändern können (z. B. www.example.com/settings?delete_account=True), sollten Sie den CSRF-Schutz als Band-Aid-Fix verwenden.

Versuchen Sie, den Status mithilfe von POSTs zu ändern, nicht von GETs.