Was ist das Motiv hinter der Einführung von Preflight-CORS-Anfragen?

Question

Cross-origin resource sharing ist ein Mechanismus, der es einer Webseite ermöglicht, XMLHttpRequests zu einer anderen Domain zu machen (von Wikipedia).

Ich habe mich in den letzten Tagen mit CORS beschäftigt und ich denke, ich verstehe ziemlich gut, wie alles funktioniert.

Also meine Frage bezieht sich nicht darauf, wie CORS / Preflights funktionieren, sondern auf den Grund, warum Preflights als neuer Anforderungstyp eingeführt wurden. Ich sehe keinen Grund, warum Server A an Server B eine Preflight-Anfrage senden muss, nur um herauszufinden, ob die eigentliche Anfrage akzeptiert wird oder nicht - es wäre sicherlich möglich für B, RR ohne PR zu akzeptieren/abzulehnen.

Nachdem ich ziemlich viel gesucht habe, habe ich diesen Abschnitt an www.w3.org (7.1.5) gefunden:

Um Ressourcen vor Cross-Origin-Anfragen zu schützen, die von bestimmten Benutzeragenten stammen könnten, bevor diese Spezifikation existierte, wird eine Preflight-Anfrage gestellt, um sicherzustellen, dass die Ressource sich dieser Spezifikation bewusst ist.

Ich finde dies ist der schwerste Satz überhaupt zu verstehen. Meine Interpretation (sollte es besser 'bester Schuss' nennen) ist, dass es darum geht, Server B vor Anfragen von Server C zu schützen, die sich nicht der Spezifikation bewusst sind.

Kann mir jemand bitte ein Szenario erklären / ein Problem zeigen, das PR + RR besser löst als nur RR allein?

Answer 1

Hier ist eine andere Möglichkeit, es zu betrachten, mit Code:

jQuery.ajax({
  method: "POST",
  url: "https://banking-website.example.com",
  data: JSON.stringify({
    sendMoneyTo: "Dr Evil",
    amount: 1000000
  }),
  contentType: "application/json",
  dataType: "json"
});

Vor CORS würde der obige Exploitversuch fehlschlagen, weil er gegen die Same-Origin Policy verstößt. Eine API, die so entworfen wurde, benötigte keinen XSRF-Schutz, da sie vom nativen Sicherheitsmodell des Browsers geschützt wurde. Es war für einen Browser vor CORS unmöglich, einen Cross-Origin-JSON-POST zu generieren.

Jetzt kommt CORS ins Spiel - wenn das Opt-in zu CORS über Pre-Flight nicht erforderlich war, hätte plötzlich diese Seite eine enorme Sicherheitslücke, ohne eigenes Verschulden.

Um zu erklären, warum einige Anfragen überspringen dürfen, dies wird in der Spezifikation beantwortet:

Eine einfache Cross-Origin-Anfrage wurde als kongruent mit denen definiert, die von derzeit verwendeten Browsern generiert werden können, die nicht dieser Spezifikation entsprechen.

Um das zu entwirren, wird GET nicht über Pre-Flight geschickt, weil es eine "einfache Methode" ist, wie in 7.1.5 definiert. (Die Header müssen auch "einfach" sein, um den Pre-Flight zu vermeiden). Die Begründung dafür ist, dass eine "einfache" Cross-Origin-GET-Anfrage bereits durch z.B. </code> durchgeführt werden könnte (so funktioniert JSONP). Da jedes Element mit einem <code>src</code>-Attribut ein Cross-Origin-GET auslösen kann, ohne Vorab-Flug, gäbe es keinen Sicherheitsvorteil, Pre-Flight bei "einfachen" XHRs zu erfordern.</p></x-turndown>

Answer 2

Zusätzlich für HTTP-Anforderungsmethoden, die Nebenwirkungen auf Benutzerdaten verursachen können (insbesondere für HTTP-Methoden außer GET oder für die POST-Nutzung mit bestimmten MIME-Typen), schreibt die Spezifikation vor, dass Browser die Anfrage "vorab prüfen"

Quelle

Answer 3

In einem Browser, der CORS unterstützt, sind Lese-Anfragen (wie GET) bereits durch die Same-Origin-Richtlinie geschützt: Eine bösartige Website, die versucht, eine authentifizierte plattformübergreifende Anfrage zu stellen (zum Beispiel an die Internetbanking-Website oder die Konfigurationsschnittstelle des Routers des Opfers), kann die zurückgegebenen Daten nicht lesen, da die Bank oder der Router den Access-Control-Allow-Origin-Header nicht setzen.

Jedoch ist bei Schreib-Anfragen (wie POST) der Schaden angerichtet, wenn die Anfrage beim Webserver ankommt.* Ein Webserver könnte den Origin-Header überprüfen, um festzustellen, ob die Anfrage legitim ist, aber diese Überprüfung wird oft nicht implementiert, weil entweder der Webserver keine Verwendung für CORS hat oder der Webserver älter als CORS ist und daher annimmt, dass plattformübergreifende POSTs vollständig durch die Same-Origin-Richtlinie untersagt sind.

Deshalb haben Webserver die Möglichkeit, sich dafür zu entscheiden, plattformübergreifende Schreibanfragen zu empfangen.

_{* Grundsätzlich die AJAX-Version von CSRF.}

Answer 4

Sind die vorab geprüften Anfragen nicht über Leistung? Mit den vorab geprüften Anfragen kann ein Client schnell herausfinden, ob die Operation erlaubt ist, bevor eine große Datenmenge, z. B. in JSON mit der PUT-Methode, gesendet wird. Oder bevor sensible Daten in Authentifizierungsheadern übertragen werden.

Die Tatsache, dass PUT, DELETE und andere Methoden neben benutzerdefinierten Headern standardmäßig nicht erlaubt sind (sie benötigen explizite Erlaubnis mit "Access-Control-Request-Methods" und "Access-Control-Request-Headers"), klingt wie eine doppelte Überprüfung, weil diese Operationen mehr Auswirkungen auf die Benutzerdaten haben könnten, im Gegensatz zu GET-Anfragen. Also klingt es wie:

"Ich habe gesehen, dass du Cross-Site-Anfragen von http://foo.example zulässt, ABER bist du SICHER, dass du DELETE-Anfragen zulassen wirst? Hast du die Auswirkungen bedacht, die diese Anfragen auf die Benutzerdaten haben könnten?"

Ich habe die zitierte Korrelation zwischen den vorab geprüften Anfragen und den Vorteilen alter Server nicht verstanden. Ein Webdienst, der vor CORS implementiert wurde oder ohne CORS-Bewusstsein vorhanden ist, wird niemals IRGENDEINE Cross-Site-Anfrage erhalten, weil zuerst die Antwort keinen "Access-Control-Allow-Origin"-Header haben wird.