Was war das Motiv für die Einführung von Vorfalldaten?
Vorfalldaten wurden eingeführt, damit ein Browser sicher sein konnte, dass er es mit einem CORS-fähigen Server zu tun hatte, bevor er bestimmte Anfragen sendete. Diese Anfragen wurden definiert als solche, die sowohl potenziell gefährlich (zustandsändernd) als auch neu waren (vor CORS aufgrund der Same Origin Policy nicht möglich). Die Verwendung von Vorfalldaten bedeutet, dass Server sich für die neuen, potenziell gefährlichen Arten von Anfragen, die CORS ermöglicht, freiwillig anmelden müssen (indem sie angemessen auf den Vorfalldaten antworten).
Das ist die Bedeutung von diesem Teil der ursprünglichen Spezifikation: "Um Ressourcen vor Cross-Origin-Anfragen zu schützen, die nicht von bestimmten Benutzeragenten stammen konnten, bevor diese Spezifikation existierte, wird eine Vorfaldatenanfrage gestellt, um sicherzustellen, dass die Ressource sich dieser Spezifikation bewusst ist."
Kannst du mir ein Beispiel geben?
Stellen wir uns vor, ein Browser-Benutzer ist bei seiner Bankwebsite A.com angemeldet. Wenn er auf die bösartige Seite B.com navigiert, enthält diese Seite einige Javascript-Codes, die versuchen, eine DELETE-Anfrage an A.com/account zu senden. Da der Benutzer bei A.com angemeldet ist, würde diese Anfrage, wenn sie gesendet würde, Cookies enthalten, die den Benutzer identifizieren.
Vor CORS hätte die Same Origin Policy des Browsers dies blockiert. Aber da der Zweck von CORS darin besteht, genau diese Art von Cross-Origin-Kommunikation zu ermöglichen, ist dies nicht mehr angemessen.
Der Browser könnte einfach die DELETE-Anfrage senden und den Server entscheiden lassen, wie damit umgegangen werden soll. Aber was ist, wenn A.com nicht mit dem CORS-Protokoll vertraut ist? Es könnte die gefährliche DELETE-Aktion durchführen. Es könnte angenommen haben, dass aufgrund der Same Origin Policy des Browsers eine solche Anfrage nie empfangen werden könnte, und würde daher nie gegen einen solchen Angriff geschützt worden sein.
Um solche nicht-CORS-fähigen Server zu schützen, verlangt das Protokoll vom Browser, zuerst eine Vorfalldatenanfrage zu senden. Diese neue Art von Anfrage ist etwas, auf das nur CORS-fähige Server richtig reagieren können, was es dem Browser ermöglicht zu wissen, ob es sicher ist, die tatsächliche DELETE-Anfrage zu senden.
Warum dieser ganze Aufwand für den Browser, kann der Angreifer nicht einfach eine DELETE-Anfrage von seinem eigenen Computer aus senden?
Sicher, aber eine solche Anfrage würde nicht die Cookies des Benutzers enthalten. Der Angriff, den dies verhindern soll, basiert darauf, dass der Browser Cookies (insbesondere Authentifizierungsinformationen für den Benutzer) für die andere Domain zusammen mit der Anfrage sendet.
_Das klingt nach Cross-Site Request Forgery, wo ein Formular auf der Seite B.com an A.com mit den Cookies des Benutzers gesendet und Schaden verursacht werden kann._
Das stimmt. Eine andere Möglichkeit, dies auszudrücken, ist, dass Vorfalldatenanfragen erstellt wurden, um die CSRF-Angriffsfläche für nicht-CORS-fähige Server nicht zu erhöhen.
Aber POST wird als Methode aufgelistet, sodass keine Vorfalldaten erforderlich sind. Das kann den Zustand ändern und Daten genauso wie ein DELETE löschen!
Das ist wahr! CORS schützt Ihre Seite nicht vor CSRF-Angriffen. Andererseits sind Sie auch ohne CORS nicht vor CSRF-Angriffen geschützt. Der Zweck von Vorfalldatenanfragen besteht nur darin, Ihre CSRF-Exposition auf das zu beschränken, was bereits in der Zeit vor CORS existierte.
Seufz. OK, ich akzeptiere widerstrebend die Notwendigkeit von Vorfalldatenanfragen. Aber warum müssen wir das für jede Ressource (URL) auf dem Server tun? Der Server handhabt CORS entweder oder nicht.
Bist du sicher? Es ist nicht ungewöhnlich, dass mehrere Server Anfragen für eine einzelne Domain bearbeiten. Beispielsweise könnte es der Fall sein, dass Anfragen an A.com/url1 von einem bestimmten Typ von Server behandelt werden und Anfragen an A.com/url2 von einem anderen Typ von Server behandelt werden. Im Allgemeinen kann der Server, der eine einzelne Ressource behandelt, keine Sicherheitsgarantien für alle Ressourcen auf dieser Domain geben.
Gut. Lassen Sie uns einen Kompromiss finden. Lassen Sie uns einen neuen CORS-Header erstellen, der es dem Server ermöglicht, genau anzugeben, für welche Ressourcen er sprechen kann, damit zusätzliche Vorfalldatenanfragen an diese URLs vermieden werden können.
Gute Idee! Tatsächlich wurde der Header Access-Control-Policy-Path für genau diesen Zweck vorgeschlagen. Letztendlich wurde er jedoch aus der Spezifikation herausgelassen, offensichtlich weil einige Server die URI-Spezifikation fehlerhaft implementiert hatten, sodass Anfragen an Pfade, die für den Browser sicher zu sein schienen, tatsächlich auf den fehlerhaften Servern unsicher waren.
War dies eine kluge Entscheidung, die Sicherheit vor Leistung priorisierte und es den Browsern ermöglichte, die CORS-Spezifikation sofort umzusetzen, ohne bestehende Server zu gefährden? Oder war es kurzsichtig, das Internet dazu zu verurteilen, Bandbreite und Latenzzeit zu verschwenden, nur um Fehler in einem bestimmten Server zu berücksichtigen zu einer bestimmten Zeit?
Die Meinungen dazu gehen auseinander.
Nun, zumindest werden Browser die Vorfalldienstanfrage für eine einzelne URL im Cache speichern, oder?
Ja. Aber wahrscheinlich nicht für sehr lange. In WebKit-Browsern beträgt die maximale Vorabcache-Zeit derzeit 10 Minuten.
Seufz. Nun, wenn ich weiß, dass meine Server CORS-fähig sind und daher nicht den Schutz von Vorfalldatenanfragen benötigen, gibt es eine Möglichkeit, sie zu umgehen?
Ihre einzige echte Option besteht darin sicherzustellen, dass Ihre Anfragen CORS-sichere Methoden und Header verwenden. Das könnte bedeuten, benutzerdefinierte Header auszulassen, die Sie sonst einschließen würden (wie X-Requested-With), den Content-Type zu ändern oder mehr.
Was auch immer Sie tun, müssen Sie sicherstellen, dass Sie angemessene CSRF-Schutzmaßnahmen haben, da CORS nicht alle unsicheren Anfragen blockiert. Wie es in der ursprünglichen Spezifikation heißt: "Ressourcen, für die einfache Anfragen eine Bedeutung haben andere als Abrufen, müssen sich vor Cross-Site Request Forgery schützen".
