Was ist der Grund für AJAX Cross-Domain-Sicherheit?

Es verhindert, dass ein Browser als Reverse-Proxy fungiert . Angenommen, Sie durchsuchen Ссылка von einem PC in Ihrem Büro aus und nehmen an, dass in diesem Büro ein Intranet mit vertraulichen Informationen unter Ссылка , auf das nur vom lokalen Netzwerk zugegriffen werden kann. Wenn die Cross-Domain-Richtlinie nicht existiert, könnte www.evil.com Ajax-Anfragen an Csylcha stellen, wenn Sie Ihren Browser als Reverseproxy und senden Sie diese Informationen mit einer weiteren Ajax-Anfrage an www.evil.com.

Dies ist einer der Gründe für die Einschränkung, denke ich.

Wenn Sie der Autor von myblog.com sind und ein XHR auf facebook.com erstellen, sollte die Anfrage Ihre Facebook-Cookie-Anmeldedaten senden? Nein, das würde bedeuten, dass Sie die privaten Facebook-Informationen der Nutzer von Ihrem Blog anfordern können.

Wenn Sie einen Proxy-Service dafür erstellen, kann Ihr Proxy nicht auf die Facebook-Cookies zugreifen.

Sie können auch fragen, warum JSONP in Ordnung ist. Der Grund dafür ist, dass Sie ein Skript laden, das Sie nicht geschrieben haben. Wenn das Skript von Facebook also nicht beschließt, Ihnen die Informationen aus seinem JS-Code zu senden, haben Sie keinen Zugriff darauf

Der wichtigste Grund für dieses Limit ist ein Sicherheitsrisiko: Sollte die JSON-Anfrage den Browser dazu veranlassen, Cookies oder Sicherheitsinformationen mit einer Anfrage an eine andere Domäne zu akzeptieren? Es ist kein Problem mit dem serverseitigen Proxy, da es keinen direkten Zugriff auf die Clientumgebung hat. Es gab einen Vorschlag für sichere, bereinigte JSON-spezifische Anfrage-Methoden , aber es wurde noch nirgendwo implementiert.

Der Unterschied zwischen direktem Zugriff und einem Proxy sind Cookies und andere sicherheitsrelevante Identifizierungs- / Verifizierungsinformationen, die absolut auf einen Ursprung beschränkt sind.

Damit kann Ihr Browser auf sensible Daten zugreifen. Ihr Proxy wird dies nicht tun, da er die Anmeldedaten des Benutzers nicht kennt.

Daher gilt der Proxy nur für öffentliche Daten. wie auch CORS .

Ich weiß, dass Sie nach Antworten von Experten fragen, ich bin nur ein Neuling, und dies ist meine Meinung, warum der serverseitige Proxy keine richtige endgültige Lösung ist:

• Der Aufbau eines serverseitigen Proxys ist nicht so einfach wie überhaupt kein Build.
• Nicht immer ist es möglich, wie in einem Third-Party-JS-Widget . Sie werden nicht alle Ihre Publisher bitten, ein DNS-Register für die Integration Ihres Widgets zu deklarieren. Und ändern Sie die document.domain seiner Seiten mit den zusätzlichen Ausgaben.
• Wie ich im Buch Javascript von Drittanbietern gelesen habe, muss eine intermediäre Tunneldatei geladen werden, bevor domänenübergreifende Anfragen gestellt werden können ". Zumindest hast du JSONP mit etwas schwierigerem Jonglieren ins Spiel gebracht.
• Nicht von IE8 unterstützt, auch aus dem obigen Buch: "IE8 hat einen ziemlich seltsamen Fehler, der verhindert, dass eine Top-Level-Domain mit ihrer Subdomain kommuniziert, auch wenn sie beide in einen gemeinsamen Domain-Namespace" .
• Es gibt mehrere Sicherheitsaspekte, wie die Leute in anderen Antworten erklärt haben, sogar mehr als diese, Sie können das Kapitel 4.3.2 Nachrichtenaustausch mit Subdomain-Proxies des obigen Buches überprüfen.

Und das Wichtigste für mich:

• Es ist ein Hack. Wie bei der JSONP-Lösung ist es Zeit für eine standardmäßige, zuverlässige, sichere, saubere und komfortable Lösung.

Aber nachdem ich Ihre Frage erneut gelesen habe, glaube ich, dass ich sie immer noch nicht beantwortet habe. Warum diese AJAX-Sicherheit? , denke ich, die Antwort ist:

Sie möchten nicht, dass eine von Ihnen besuchte Webseite von Ihrem Desktop zu einem beliebigen Computer oder Server im Intranet Ihres Büros