Was ist der Unterschied zwischen CORS und CSPs?
Aus meiner Sicht scheinen die als Cross-Origin Resource Sharing (CORS) und Content Security Policies (CSPs) bezeichneten Technologien in Zweck und Implementierung sehr ähnlich zu sein.
Beides scheint es Ihnen zu ermöglichen, die Ursprünge von Ressourcen, die eine kompromisslose Version Ihrer Webseite enthält, über HTTP-Antwortheader auf eine Whitelist zu setzen. Der einzige Unterschied, den ich feststellen kann, besteht darin, dass CSPs in Bezug auf das, was Sie in Ihrer HTTP-Antwort genehmigen können, differenzierter zu sein scheinen.
Mit CORS kann die Same Origin Policy für eine Domain gelockert werden.
z.B. Wenn sich der Benutzer sowohl bei example.com als auch bei example.org anmeldet, verhindert die Richtlinie für denselben Ursprung normalerweise, dass example.com eine AJAX Anfrage an example.org/current_user/full_user_details Und Zugriff auf die Antwort erhalten.
Dies ist die Standardrichtlinie des Webs und verhindert, dass die Daten des Benutzers verloren gehen, wenn er gleichzeitig an mehreren Standorten angemeldet ist.
Mit CORS könnte nun example.org Eine Richtlinie festlegen, die besagt, dass Origin https://example.com Antworten von AJAX lesen kann. Dies würde geschehen, wenn sowohl example.com Als auch example.org Von derselben Firma betrieben werden und der Datenaustausch zwischen den Ursprüngen im Browser des Benutzers zugelassen werden soll. Es betrifft nur die Client-Seite der Dinge, nicht die Server-Seite.
CSPs legen dagegen eine Richtlinie fest, welche Inhalte auf der aktuellen Site ausgeführt werden können. Zum Beispiel, wenn JavaScript inline ausgeführt werden kann oder aus welchen Domains .js Dateien geladen werden können. Dies kann nützlich sein, um eine weitere Verteidigungslinie gegen XSS -Angriffe zu bilden, bei denen der Angreifer versucht, ein Skript in die HTML-Seite einzufügen. Normalerweise Ausgabe wäre verschlüsselt , allerdings soll der Entwickler nur auf ein Ausgabefeld vergessen haben. Da die Ausführung von Inline-Skripten durch die Richtlinie verhindert wird, wird der Angriff vereitelt.
Mit CORS kann Site A Site B die Erlaubnis erteilen, (potenziell private) Daten von Site A zu lesen (mithilfe des Browsers und der Anmeldeinformationen des Besuchers).
Mit CSP kann eine Site verhindern, dass selbst (potenziell böswillige) Inhalte aus unerwarteten Quellen geladen werden (z. B. zur Verteidigung gegen XSS).
Keine der obigen Antworten gibt einen klaren und prägnanten Unterschied zwischen CSP und CORS. Hier ist meine Art, über sie nachzudenken:
Angenommen, wir haben abc.com eine Website, die eine Anfrage an def.net senden möchte.
- Wenn der Benutzer abc.com im Browser besucht, gibt der abc.com-Server abc.com-HTTP-Antwort zurück. Die CSP-Einschränkung in dieser Antwort kann abc.com im Browser daran hindern, eine Anfrage an zu senden def.net.
- Wenn abc.com HTTP response keine CSP-Einschränkung enthält, kann abc.com in browser eine Anfrage an def.net senden.
- Nach Erhalt der Anfrage antwortet der def.net-Server mit def.net-HTTP-Antwort. Eine CORS-Einschränkung innerhalb dieser Antwort kann verhindern, dass abc.com im Browser diese lädt. (Beachten Sie, dass die Richtlinie von Same-Origin standardmäßig das Laden von Antworten einschränkt, sofern von CORS nicht anders angegeben.)
CSP schützt also abc.com und die Same-Origin-Richtlinie (das Fehlen von CORS) schützt def.net im obigen Beispiel.
CORS erkundigt sich beim Dritten nach der Berechtigung zur Nutzung seiner Dienste. Daher stellt der Dritte die Autorisierung bereit oder verweigert sie.
Wenn zum Beispiel eine Seite in www.example.com eine Anfrage an www.example.org stellen muss, müssen wir eine OPTIONS-Anfrage an www.example.org senden, wobei Origin: www.example.com der Vorläufer der Anfrage ist zur Genehmigung. Jetzt bietet www.example.org die Autorisierung an oder verweigert sie.
CSP verhindert, dass eine Webseite versehentlich schädliche Inhalte von Dritten lädt, indem angegeben wird, von wo ein bestimmter Inhaltstyp geladen werden kann. So können Sie beispielsweise mithilfe von Direktiven eine gültige Quelle für jedes der folgenden Skripte, CSS, Medien usw. bereitstellen
Beispiel:
Inhaltssicherheitsrichtlinie: default-src 'none'; script-src 'self' www.google-analytics.com ajax.googleapis.com; connect-src 'self'; img-src 'self'; style-src 'self';