CORS einfach erklärt

Haben Sie das oben schon einmal gesehen? Wahrscheinlich… und wahrscheinlich eine ganze Menge… Es gibt Millionen von Artikeln, in denen erklärt wird, wie der obige Fehler behoben werden kann, aber was genau ist dieses „Cross-Origin Resource Sharing“ (CORS)-Ding und warum gibt es es überhaupt?

Warum?

Beginnen wir damit, zunächst die Frage nach dem Warum durch ein Szenario zu beantworten und wie es sich zu verschiedenen Zeitpunkten abspielen würde.

Stellen Sie sich Folgendes vor: Sie melden sich bei bank.com an, was Ihr Bankservice ist. Nach dem Einloggen wird ein „Session-Cookie“ in Ihrem Browser gespeichert. (Session-Cookies teilen dem dahinter liegenden Server bank.com grundsätzlich mit, dass Ihr Browser nun in Ihrem Konto angemeldet ist.) Alle zukünftigen Anfragen an bank.com enthalten nun dieses Cookie, und es kann ordnungsgemäß antworten, wenn Sie angemeldet sind.

Ok, jetzt entscheiden Sie sich also, Ihren Briefkasten zu überprüfen. Sie sehen eine verdächtige E-Mail und entscheiden sich natürlich, auf den darin enthaltenen Link zu klicken, der Sie zu attack.com weiterleitet. Als nächstes sendet diese Website eine Anfrage an bank.com, um Ihre Bankdaten zu erhalten. Denken Sie daran, dass bank.com immer noch denken, dass Sie wegen dieses Session-Cookies angemeldet sind… Dieses Cookie wird in Ihrem Browser gespeichert. Für die Server hinter bank.com sieht es nur so aus, als hätten Sie Ihre Bankdaten normal angefordert, also werden sie zurückgesendet. Attack.com hat nun Zugriff auf diese und speichert sie böswillig an anderer Stelle.

SOP

Die Leute erkannten, dass dies schlecht war, also führten Browser eine SOP (Same-Origin Policy) ein, bei der Ihr Browser blockiert wird, wenn er bemerkt, dass Sie versuchen, Anfragen an einen anderen Ort als bank.com ihn zu stellen. Nun, das ist eine wichtige Sache, die es zu realisieren gilt – es handelt sich um eine browserbasierte Richtlinie. bank.com hat wirklich keine Möglichkeit zu sagen, woher eine Anfrage kommt, so dass es nicht viel vor Angriffen wie CSRF schützen kann. Der Browser, den Sie verwenden, tritt ein und sagt im Grunde, dass, wenn Sie anscheinend versuchen, Details für einen Ursprung anzufordern (Schema + Domainname + Port, https//foo.com:4000, http//bar.org:3000, etc… Im Grunde die URL), sendet es nur diese Anfragen für denselben Ursprung.

Nun, das war großartig und alles, aber es war unglaublich einschränkend. Ich meine, öffentliche APIs würden überhaupt nicht funktionieren. Sie konnten keine Daten von ihnen anfordern, es sei denn, Sie verwendeten eine Art Proxy-Lösung.

CSRF

Die Sache ist die: Server können irgendwie sagen, woher eine Anfrage kam. Es gibt den „Origin“-Header, den Anfragen haben sollten, und der zeigt, von welchem Ursprung aus eine Anfrage gestellt wurde. Im obigen Beispiel würde die Anforderung beispielsweise in etwa so aussehen.

Request to -----> bank.com
{
  Headers: { Origin: http://attack.com }
}

Theoretisch bank.com sollte dies überprüfen, um sicherzustellen, dass es nur auf Anfragen reagiert, bei denen der Ursprung sinnvoll ist. Und das tut es normalerweise, so dass SOP irgendwie einschränkend erscheint. Hier kommt CORS ins Spiel.

CORS

Wenn eine Webanwendung von examle.com versucht, Ressourcen von bank.com anzufordern, fügt der Browser automatisch einen Header in die Anforderung ein, der angibt, woher die Anforderung stammt (example.com). Hier ist der entscheidende Teil: Anstatt solche Cross-Origin-Anfragen im Rahmen der SOP direkt zu blockieren, kann der Server von bank.com diesen Header überprüfen und entscheiden, ob die Anfrage auf der Grundlage seiner eigenen CORS-Richtlinie zugelassen oder abgelehnt wird.

Wenn bank.com dies (example.com) als vertrauenswürdig einstuft oder die angeforderte Ressource öffentlich zugänglich sein soll, kann sie mit bestimmten CORS-Headern antworten, z. B. mit der Angabe Access-Control-Allow-Origin, welche Ursprünge auf die Ressource zugreifen dürfen. Dieser Header kann auf http://example.com festgelegt werden, wodurch dieser Ursprung explizit zugelassen wird, oder * für öffentliche Ressourcen, auf die jeder Ursprung zugreifen kann.

All dies erleichtert natürlich der Browser. Wenn irgendetwas davon falsch ist, erhalten Sie diesen bösen Fehler.

Jetzt… Was ist, wenn die Anforderung nicht über den Origin-Header verfügt? Was ist, wenn es eine Reihe anderer Header hat und keine der grundlegenden HTTP-Methoden verwendet?

In diesen Situationen wird die Handhabung von CORS etwas komplizierter, da es sich nicht mehr um eine „einfache Anfrage“ handelt. Hier kommt das Konzept der „Preflight“-Anfragen in CORS ins Spiel.

Preflight

Für bestimmte Arten von Anforderungen, die möglicherweise Daten auf dem Server ändern könnten – solche, die HTTP-Methoden wie PUT oder DELETE verwenden oder Header verwenden, die nicht automatisch in jeder Anforderung enthalten sind – senden Browser zuerst eine „Preflight“-Anforderung, bevor sie die eigentliche Anforderung stellen. Bei dieser Preflight-Anforderung handelt es sich um eine HTTP OPTIONS-Anforderung, die mit dem Server überprüft, ob das Senden der eigentlichen Anforderung sicher ist.

Die Preflight-Anforderung enthält Header, die die HTTP-Methode beschreiben, und Header der eigentlichen Anforderung. Und das passiert als nächstes:

1. Serverantwort: Wenn der Server die CORS-Richtlinie und die eigentliche Anforderung unterstützt, antwortet er auf die Preflight-Anforderung mit Headern, die angeben, welche Methoden und Header zulässig sind. Dies kann Überschriften wie Access-Control-Allow-Methods und Access-Control-Allow-Headers enthalten.
2. Browser-Entscheidung: Basierend auf der Antwort des Servers auf die Preflight-Anfrage entscheidet der Browser, ob er mit der eigentlichen Anfrage fortfährt. Wenn die Antwort des Servers anzeigt, dass die Anfrage zulässig ist, sendet der Browser sie. Ist dies nicht der Fall, blockiert der Browser die Anforderung, und es wird ein Fehler im Zusammenhang mit CORS angezeigt.

Fazit

Jetzt verstehen Sie hoffentlich ein wenig mehr über CORS. Ich denke, das Wichtigste ist, dass dies alles Browserrichtlinie ist und Ihr Server so codiert sein muss, dass er sie einhält. Es ist an Ort und Stelle, um Sie zu schützen. Wenn Sie Chrome verwenden, sollten Sie sich nicht so viele Sorgen machen, auf die falschen Links zu klicken. Dies ist jedoch keine narrensichere Politik. Wenn Sie einen Browser von Drittanbietern verwenden, der nicht den Standards entspricht, wird all dies weggeworfen. Deshalb muss man vorsichtig sein, welche Software sie verwenden!

Weiterer Beitrag: Warum Docker möglicherweise nicht die beste Wahl ist