CORS - Was motiviert die Einführung von Preflight-Anfragen?

Cross-origin resource sharing ist ein Mechanismus, der es erlaubt, eine web-Seite mit XMLHttpRequests auf eine andere domain (von wikipedia), und es ist ziemlich wichtig (von mir: -).

Ich habe schon hantieren mit CORS für die letzten paar Tage und ich denke, ich habe ein ziemlich gutes Verständnis davon, wie alles funktioniert.

Also meine Frage ist nicht, wie CORS /preflight-Arbeit, es geht um der Grund für Ihr kommen mit preflights als neue Art der Anfrage. Ich nicht sehen jeden Grund, warum server senden muss, um eine preflight-Prüfung (PR) auf server B, nur um herauszufinden, wenn die eigentliche Anfrage (RR) akzeptiert werden oder nicht - es wäre sicherlich möglich, für B annehmen/ablehnen RR ohne Vorherige PR.

Nach der Suche einiges fand ich dieses Stück von Informationen an www.w3.org (7.1.5):

Zum Schutz von Ressourcen vor cross-origin requests, die nicht stammen aus bestimmten user-agents, bevor Sie diese Spezifikation existiert ein
preflight-Anfrage gemacht wird, um sicherzustellen, dass die Ressource bekannt ist
- Spezifikation.

Ich finde das ist der am schwersten zu verstehende Satz, der jemals. Meine interpretation (sollte besser nennen es 'best guess') ist, dass es zum schützen von server B gegen Anfragen von server C, der nicht bewusst von der Skillung.

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

InformationsquelleAutor der Frage jan groth | 2013-03-13

226

Verbrachte ich einige Zeit verwirrt zu sein, als der Zweck der preflight-Anfrage, aber ich denke, ich habe es jetzt.

Die zentrale Erkenntnis ist, dass die preflight-Anfragen werden nicht Sicherheit Sache. Vielmehr sind Sie ein nicht-verändern-die-Regeln Sache.

Preflight-Anfragen haben nichts mit Sicherheit zu tun, und Sie haben keine Auswirkungen auf die Anwendungen, die derzeit entwickelt wird, mit dem Bewusstsein von CORS. Vielmehr ist die preflight-Mechanismus Vorteile Servern, die entwickelt wurden ohne ein Bewusstsein von CORS, und es Funktionen wie eine Plausibilitätsprüfung zwischen dem client und dem server, Sie sind beide CORS-bewusst. Die Entwickler von CORS gefühlt, dass es genügend Server gibt, die sich auf die Annahme, dass Sie nie erhalten, z.B. eine cross-domain-Anfrage LÖSCHEN, dass Sie erfunden, die preflight-Mechanismus auf beiden Seiten ermöglichen, zu einem opt-in. Sie fühlte, dass die alternative, die wäre gewesen, aktivieren Sie einfach die cross-domain Aufrufe, würde gebrochen haben, auch viele bestehende Anwendungen.

Gibt es drei Szenarien, hier:
1. Alten Server, nicht mehr in der Entwicklung, und entwickelt vor CORS. Diese Server können Annahmen, dass Sie nie erhalten, z.B. eine cross-domain-Anfrage LÖSCHEN. Diesem Szenario ist das primäre Empfänger der preflight-Mechanismus. Ja, diese Dienste konnte bereits missbraucht werden, die von einem böswilligen oder nicht-konforme Benutzer-agent (und CORS tut nichts um dies zu ändern), aber in einer Welt mit CORS, die preflight-Mechanismus bietet eine zusätzliche 'sanity check', so dass clients und Server brechen nicht, weil die zugrunde liegenden Regeln des web verändert haben.
2. Server, die sind noch in der Entwicklung, aber die enthalten viel alten code und für die es nicht machbar/wünschenswert zu überprüfen, die alt-code, um sicherzustellen, dass es ordnungsgemäß funktioniert in einem cross-domain-Welt. Dieses Szenario ermöglicht Servern, um schrittweise eine opt-in zu CORS, z.B. indem Sie sagen: "Jetzt werde ich es erlauben, diese bestimmte header", "Jetzt werde ich es erlauben, diese bestimmte HTTP-verb", "Jetzt werde ich cookies zulassen/auth-Daten werden gesendet", etc. Diesem Szenario profitiert von der preflight-Mechanismus.
3. Neuen Server geschrieben werden, mit dem Bewusstsein von CORS. Nach standard-Sicherheitsrichtlinien, die server zu schützen hat seine Ressourcen in das Gesicht von alle eingehende Anfrage -- Server nicht Vertrauen können clients nicht tun bösartige Dinge. Dieses Szenario nicht profitieren von der preflight-Mechanismus: die preflight-Mechanismus bringt keine zusätzliche Sicherheit, auf einen server, der hat richtig geschützt Ihre Ressourcen.
InformationsquelleAutor der Antwort Michael Iles
45

Was war die motivation für die Einführung von preflight requests?

Preflight-Anfragen wurden so eingeführt, dass der Browser sicher sein konnte, waren Sie Umgang mit einem CORS-fähigen server vor dem senden bestimmte Anfragen. Diese Anforderungen wurden definiert als diejenigen, die waren beide potentiell gefährlich (Status-änderung) und neue (zuvor nicht möglich CORS aufgrund der Same-Origin-Policy). Mit preflight requests bedeutet, dass die Server müssen opt-in (von richtig reagiert, um die preflight), um die neue, potenziell gefährliche Arten von Anfrage, CORS möglich macht.

Die Spezifikation stellt es so: "Zum Schutz der Ressourcen gegen cross-origin-requests, die nicht stammen aus bestimmten user-agents, bevor Sie diese Spezifikation existiert ein preflight-Anfrage gemacht wird, um sicherzustellen, dass die Ressource ist sich bewusst, von dieser Spezifikation."

Können Sie mir ein Beispiel nennen?

Nehmen wir an, ein Benutzer angemeldet ist Ihre banking-site A.com. Wenn Sie direkte Ihren browser auf meiner Seite unter B.com meine Seite enthält einige Javascript-Code, sendet ein böswilliger DELETE Anfrage A.com/account. Da der Benutzer angemeldet ist A.com in diesem browser-Sitzung, der Antrag umfasst die Authentifizierung des Benutzer-cookie für diese Domäne. Wenn preflights nicht existieren, der browser würde gehen Sie vor und senden Sie diese Aufforderung, da im Rahmen CORS, es liegt an den server, um zu bestimmen, ob eine Anfrage erlaubt werden sollte.

Aber was ist, wenn die banking-Website an A.com ist sich nicht bewusst CORS? Könnte es glücklich ausführen der DELETE. Es war nicht entworfen, um zu verhindern, dass dieser Angriff, weil vor CORS existierte der browser die same-Origin-Policy würde gehalten haben, von der übersendung einer Anfrage. Der server wird sich auf diese Annahme.

Dagegen, wenn der browser sendet zuerst einen preflight-request der server nicht in der Lage sein, um richtig reagieren. Das sagt dem browser, dass diese server nicht die Teilnahme an CORS, und es sollte daher nicht zu senden, die potentiell gefährliche DELETE.

Warum all diese Aufregung über den browser, nicht den Angreifer senden Sie einfach eine DELETE Anfrage von Ihrem eigenen computer?

Sicher, aber ein solcher Antrag wird nicht der Nutzer seine cookies. Der Angriff, den dieses ist entworfen, um zu verhindern, beruht auf der Tatsache, dass der browser sendet die cookies (insbesondere die Authentifizierungsinformationen für den Benutzer) für die andere Domäne zusammen mit der Anfrage.

Das klingt wie Cross-Site Request Forgery, wo ein Formular auf der Website B.com können POST zu A.com mit der Benutzer die cookies und Schaden anrichten.

Richtig. Ein anderer Weg, dies auszudrücken, ist, dass die preflight-Anfragen erstellt wurden, damit nicht die Erhöhung der CSRF-Angriff-Oberfläche für nicht-CORS-fähigen Server.

Aber ein Blick auf die Anforderungen für "einfache" Anfragen, die nicht brauchen, preflights, sehe ich, dass POST ist noch erlaubt. Das kann den Status ändern und löschen von Daten ebenso wie eine DELETE!

Stimmt! CORS nicht schützen Sie Ihre Website von CSRF-Angriffen. Dann wieder, ohne CORS Sie sind auch nicht geschützt vor CSRF-Angriffen. Der Zweck des preflight-Anfragen ist nur zur Begrenzung der CSRF-Angriff der Oberfläche zu dem, was bereits in der pre-CORS Welt.

Seufzer. OK, ich widerwillig akzeptieren die Notwendigkeit, für die preflight-Anfragen. Aber warum tun wir es zu tun haben für jede Ressource (URL) auf dem server? Der server verarbeitet entweder CORS oder nicht.

Sind Sie sich da sicher? Es ist nicht ungewöhnlich für mehrere Server-Anfragen für eine einzelne domain. Insbesondere kann es der Fall sein, dass die Anfragen für A.com/url1 behandelt werden, durch eine Art von server und fordert für A.com/url2 behandelt werden, durch eine andere Art von server. Es ist nicht generell der Fall, dass der server die Verarbeitung einer einzelnen Ressource kann die Sicherheit garantiert, über alle Ressourcen in dieser Domäne.

In Ordnung. Lassen Sie uns den Kompromiss. Lassen Sie uns erstellen Sie ein neues CORS-header erlaubt dem server genau angeben, welche Ressourcen es sprechen kann, so dass zusätzliche preflight-Anfragen, die URLs vermieden werden können.

Gute Idee! In der Tat, der header Access-Control-Policy-Path vorgeschlagen wurde, für eben diesen Zweck. Letztlich, obwohl, es wurde in der Spezifikation, offenbar da einige Server falsch implementiert, die URI-Spezifikation in einer Weise, dass Anträge auf Pfade, schien sicher, der browser würde in der Tat nicht sicher auf dem kaputten Server.

War dies eine umsichtige Entscheidung, priorisiert Sicherheit über Leistung, so dass Browser sofort zu implementieren, die CORS-Spezifikation, ohne dabei die vorhandenen Server in Gefahr? Oder war es kurzsichtig von doom das internet, um Verschwendung von Bandbreite und Latenz verdoppelt, nur um Platz für bugs in einem bestimmten server zu einer bestimmten Zeit?

Unterscheiden sich die Meinungen.

Gut, zumindest Browser-cache-der preflight für eine einzelne URL?

Ja. Wenn auch wahrscheinlich nicht für lange. In WebKit-Browsern die maximale preflight-cache-Zeit ist aktuell 10 Minuten.

Pfui. Gut, wenn ich weiß, dass mein Server mit CORS-bewusst, und deshalb brauchen Sie nicht den Schutz, den preflight-Anfragen, ist es eine Möglichkeit für mich, um Sie zu vermeiden?

Ihre einzige wirkliche option ist, um sicherzustellen, dass Sie erfüllen die Anforderungen für "einfache" Anfragen. Das kann bedeuten, dass das weglassen benutzerdefinierte Kopfzeilen, die Sie sonst enthalten (wie X-Requested-With), Lügen über die Content-Type oder mehr.

In jedem Fall, werden Sie wollen, stellen Sie sicher, dass Sie korrekte CSRF-Schutz, da die CORS-Spezifikation adressiert nicht die Ablehnung der "einfachen" Anforderungen, einschließlich der unsicheren POST. Wie die Spezifikation formuliert es: "Ressourcen, für die einfache Anforderungen haben andere Bedeutung als Abruf müssen schützen Sie sich vor Cross-Site Request Forgery".

InformationsquelleAutor der Antwort Kevin Christopher Henry
44

Betrachten Sie die Welt von cross-domain-Anfragen, bevor CORS. Könnten Sie tun, ein standard-Formular, POST, oder verwenden Sie eine script oder eine image - tag zur Ausgabe einer GET-Anfrage. Sie konnten nicht bewirken, dass jede andere Anfrage geben Sie anderen als GET/POST, und man konnte nicht jeden custom-Header auf diese Anfragen.

Mit dem Aufkommen von CORS, dem spec-Autoren waren mit der Herausforderung konfrontiert, dass die Einführung einer neuen cross-domain-Mechanismus ohne die vorhandenen Semantik des web. Sie entschied sich, dies zu tun, indem Sie Server eine Möglichkeit zum opt-in für jeden neuen request-Typ. Dieses opt-in ist die preflight-Anfrage.

Also GET/POST-requests ohne benutzerdefinierte Header nicht, müssen Sie eine preflight, da diese Anträge wurden bereits möglich, bevor CORS. Aber jede Anforderung mit benutzerdefinierten Kopfzeilen, oder PUT/DELETE requests tun müssen Sie eine preflight, da diese neu sind die CORS-Spezifikation. Wenn der server weiß nichts über CORS, antwortet Sie ohne CORS-spezifischen Header, und die eigentliche Anfrage wird nicht gemacht.

Ohne den preflight-Anfrage, Server könnten beginnen zu sehen, unerwartete Anfragen von Browsern. Dies könnte zu einem Sicherheitsproblem werden, wenn die Server waren nicht bereit für diese Art von Anfragen. Die CORS-preflight ermöglicht cross-domain-requests eingeführt werden, um das web in einer sicheren Weise.

InformationsquelleAutor der Antwort monsur
27

CORS können Sie angeben, mehr Kopf-und Methode Arten, als bisher möglich war mit cross-origin - <img src> oder <form action>.

Einige Server hätte (schlecht) geschützt, mit der Annahme, dass ein browser nicht machen kann, z.B. cross-origin - DELETE Anfrage oder cross-origin-Anfrage mit X-Requested-With header, also solche Anfragen sind "vertrauenswürdig".

Sicherstellen, dass die server wirklich-wirklich unterstützt CORS und nicht nur passiert, zu reagieren, um zufällige Anfragen, die preflight ausgeführt wird.

InformationsquelleAutor der Antwort Kornel
12

Hier ist ein weiterer Weg, es zu betrachten, mit code:
```


<script>
jQuery.ajax({
  method: "POST",
  url: "https://banking-website.example.com",
  data: JSON.stringify({
    sendMoneyTo: "Dr Evil",
    amount: 1000000
  }),
  contentType: "application/json",
  dataType: "json"
});
</script>
```
Pre-CORS, die exploit-Versuch würde fehlschlagen, weil es gegen die same-origin-policy. Eine API entwickelt, auf diese Weise haben Sie nicht brauchen, XSRF-Schutz, denn es war geschützt durch den browser-nativen Sicherheits-Modell. Es war unmöglich, für eine pre-CORS-browser zu erzeugen, einen cross-origin-JSON-POST.

Nun CORS kommt auf die Szene – wenn opting-in zu CORS via pre-flight nicht erforderlich war, plötzlich dieser Website wäre eine riesige Sicherheitslücke, durch keine Störung von Ihren selbst.

Zu erklären, warum manche Anfragen sind erlaubt, überspringen Sie die pre-flight -, dieser beantwortet die Skillung:

Einer einfachen cross-origin-Anforderung wurde definiert als kongruent mit denen
die können erzeugt werden, die derzeit im Einsatz sind user-agents, die nicht
konform zu dieser Spezifikation.

Zu entwirren, der, BEKOMMEN ist nicht pre-flighted, weil es eine "einfache Methode", wie definiert durch 7.1.5. (Der Header muss auch "einfach" um zu vermeiden, dass die "pre-flight").
Die Begründung dafür ist, dass "einfache" cross-origin-GET-Anforderung konnte bereits durchgeführt werden, indem z.B. <script src=""> (dies ist, wie JSONP funktioniert). Da jedes element mit einer src Attribut auslösen kann zu einem cross-origin BEKOMMEN, mit keine pre-flight, es wäre keine Sicherheit profitieren, um die pre-fight auf "einfache" XHRs.

InformationsquelleAutor der Antwort Dylan Tack
8

Ich das Gefühl, dass die anderen Antworten sind nicht die Konzentration auf die Grund-pre-Kampf erhöht die Sicherheit.

Szenarien:

1) Mit "pre-flight". Ein Angreifer fälscht eine Anfrage von der Seite dummy-forums.com während der Benutzer authentifiziert ist, safe-bank.com

Wenn der Server nicht überprüfen Sie für den Ursprung, und hat irgendwie ein Fehler, der browser wird die Ausgabe einer pre-flight-Anfrage, OPTION-Methode. Der server weiß nichts davon CORS, dass der browser erwartet als Antwort, so die browser wird nicht gehen (kein Schaden auch immer)

2) Ohne pre-flight -. Ein Angreifer fälscht die Anfrage unter dem gleichen Szenario wie oben, in der browser-Ausgabe der POST-oder PUT-Anfrage sofort, der server akzeptiert es und verarbeiten könnte, dies wird möglicherweise dazu führen, einige Schäden.

Wenn der Angreifer sendet eine Anfrage direkt, cross-origin, von einigen zufälligen host handelt es sich wahrscheinlich denken über eine Anfrage mit keine - Authentifizierung. Das ist eine gefälschte Anfrage, aber nicht ein xsrf. also der server wird, überprüfen Sie die Anmeldeinformationen und scheitern.
CORS versucht nicht, zu verhindern, dass ein Angreifer, der die Anmeldeinformationen, um die Ausgabe von Anfragen, obwohl eine whitelist könnte helfen, verringern Sie diesen Vektor von Angriff.

Den pre-flight-Mechanismus, der fügt die Sicherheit und Konsistenz zwischen clients und Servern.
Ich weiß nicht, ob sich das lohnt das extra-handshake für jede Anfrage, da caching ist winterhart Verwendung-in der Lage dort, aber das ist, wie es funktioniert.

InformationsquelleAutor der Antwort Hirako
3

Darüber hinaus für die HTTP-request-Methoden, die verursachen können, Nebenwirkungen auf
user-Daten (insbesondere für die anderen HTTP-Methoden als GET oder POST
Verwendung mit bestimmten MIME-Typen), die Spezifikation Mandate,
Browser "preflight" die Anfrage

Quelle

InformationsquelleAutor der Antwort Oliver Weichhold
1

Sind nicht die Preflight-Anfragen über Leistung? Mit der Preflight Anfragen, die ein client können schnell wissen, ob die operation zulässig ist, bevor Sie senden, eine große Menge von Daten, z.B. in JSON mit PUT-Methode. Oder vor der Reise sensible Daten, die in authentication-Header über den Draht.

Die Tatsache, PUT, DELETE und andere Methoden, außer benutzerdefinierte Header sind, dürfen nicht standardmäßig(Sie brauchen die ausdrückliche Erlaubnis, mit "Access-Control-Request-Methoden" und "Access-Control-Request-Header"), das klingt nur wie ein Doppel-check, da diese Vorgänge hätte mehr Auswirkungen auf die Benutzer-Daten, anstelle von GET-Anforderungen.
Also, es klingt wie:

"Ich sah, dass Sie ermöglichen cross-site-Anfragen von http://foo.example, ABER sind Sie SICHER, dass Sie erlauben das LÖSCHEN von requests? Haben Sie berücksichtigen die Auswirkungen, die diese Anforderungen führen könnte, die in der Benutzer-Daten?"

Ich nicht verstehe ist die zitierte Korrelation zwischen den Preflight-Anfragen und die alten Server nutzen. Ein Web Service implementiert wurde, bevor CORS, oder ohne CORS Bewusstsein, wird nie erhalten JEDE cross-site request, weil Ihre erste Reaktion nicht die "Access-Control-Allow-Origin" - header.

InformationsquelleAutor der Antwort Nipo
1

In einem browser mit Unterstützung von CORS, Lesen Anforderungen (wie BEKOMMEN) bereits geschützt sind, die gleichen Ursprungs-Politik: Eine schädliche website versucht, um eine authentifizierte cross-domain-Anfrage (zum Beispiel, um dem Opfer das internet-banking-website oder die Konfiguration des Routers Schnittstelle) werden nicht in der Lage zu Lesen, die zurückgegeben Daten, da die bank oder der router nicht die Access-Control-Allow-Origin header.

Jedoch mit schreiben Anforderungen (wie POST) der Schaden ist getan, wenn die Anfrage kommt auf dem webserver.* Ein webserver könnte prüfen, die Origin header zu bestimmen, ob die Anfrage echt ist, aber diese Prüfung wird oft nicht umgesetzt, weil entweder der Server hat keine Notwendigkeit für CORS oder der webserver ist älter als CORS und ist daher unter der Annahme, dass cross-domain-Beiträge sind absolut verboten, die von den gleichen-origin policy.

Deshalb Webserver die chance gegeben zu opt-in in die cross-domain-Anfragen schreiben.

_{* Im wesentlichen die AJAX-version von CSRF.}

InformationsquelleAutor der Antwort AndreKR

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.