Was ist der Grund für die Verwendung der OPTION-Anfrage vor dem POST bei CORS-Anfragen?

Question

Was ist der Grund für das Senden einer OPTION Anfrage vor dem eigentlichen POST, UPDATE, PUT oder Anfrage löschen, wenn eine andere Domäne genannt wird? (Also auf CORS-Anfragen) Ich weiß es sollte überprüfen, ob der Server die echte Anfrage bearbeiten kann, aber warum nicht einfach die echte Anfrage sofort senden?

1. , wenn die Methode
2. die reale Anfrage Senden unterstützt wird Siehe den gleichen Status Code wird wiederkommen, so keine Notwendigkeit erste Option Anfrage zu senden:

   Einige der Gründe habe ich darüber nachgedacht, .

3. Überprüfen Sie, ob der Benutzer die Anforderung senden darf
   • keinen Sinn machen, da keine Auth-Header mit der OPTION
   Anfragen gesendet werden
4. Prevent schwere Last auf dem Server
   • Sinnlos, da die Auth-Regeln vor der Verarbeitung der Daten überprüft werden.
5. Um zu überprüfen, ob die angeforderte Header und Herkunft dürfen
   • Dies ist, wie es jetzt funktioniert, aber wieder, warum nicht nur die Anfrage senden, und wir den Fehler aus der realen Anforderung lesen kann.
6. verhindern, dass die Post-Daten zu senden, wenn es
   • verarbeitet werden wont Dies ist der einzige Grund, was gültig ist. Die Verwendung der Optionsanfrage verhindert das unnötige Senden der Postdaten an den Server. Ich denke jedoch, dass dies in 99% der Fälle kein Problem ist, da nur ein kleiner Teil der Daten gesendet wird.

Kann jemand etwas Licht auf die Gründe, warum Schuppen Anbieter Browser OPTION Anfragen implementiert, wenn eine andere Domain aufrufen?

Answer 1

CORS ist im Grunde eine Browser-Sicherheitsfunktion nicht Server-Seite.

Standardmäßig wird der Browser bestimmte Cross-Origin-Anfragen NICHT zulassen. Der Server, mit dem Sie sprechen, kann veröffentlichen, ob Cross-Ursprungsanforderungen sicher verwendet werden können, aber es ist der Client, der diese Informationen versteht und verwendet und daher den Schutz bietet, nicht den Server.

Also für eine GET-Anfrage können Sie die Ressource erhalten, überprüfen Sie die CORS-Header und dann entscheiden, ob Sie es verarbeiten oder nicht basierend auf der Kopfzeile. Schön und einfach.

Für einen POST (oder anderen ändernden) Ereignis ist es nicht so einfach. Sie machen die POST-Anfrage, der Server verarbeitet sie (denken Sie daran, der Server kümmert sich nicht um CORS, nur der Browser) und sendet die Antwort zurück. Der Browser sieht CORS nicht aktiviert und ignoriert die Antwort, aber zu diesem Zeitpunkt ist es zu spät - die POST-Anfrage wurde auf der Server-Seite verarbeitet und alles, was verhindert wird, ist die Anzeige der Ergebnisse, dass es verarbeitet wurde. Für eine Online-Banking-Anwendung bedeutet beispielsweise eine böswillige Anfrage, Geld zu überweisen, dass das Geld überwiesen wird, aber Ihr Browser die Antwort "Mittel erfolgreich überwiesen" ignoriert - große Schäden, wenn das Geld weg ist und die böswillige Anfrage hätte die Antwort sowieso ignoriert!

So können Sie die Anfrage nicht senden, bis Sie wissen, was der CORS-Header in der Antwort sein wird - das erfordert das Senden der Anfrage! Hühner- und Eissituation.

So sendet der Browser einen OPTIONS an die gleiche Adresse anfordern, die nicht Änderung etwas wie eine POST-Anfrage könnte, aber tut die CORS-Header zurück. Danach weiß der Browser, ob es sicher ist, die echte Anfrage zu senden.

Und der Grund, warum ein Server keine CORS-Sicherheit implementiert, ist, dass es unglaublich einfach ist, den Referrer-Header so zu ändern, dass er sowieso keinen Schutz bietet. Der Server wird über andere Sicherheitsfunktionen verfügen (z. B. ist die Sitzungsüberprüfung gültig und berechtigt, die Anfrage zu stellen), aber ein Angriff, den CORS verhindern soll, ist nicht hilfreich (zB Benutzer ist bei seinem Online-Banking angemeldet) ein weiterer Tab).