Detaillierte Erläuterung der JavaScript-Fähigkeiten von js Same Origin Policy

In diesem Artikel wird die js-Same-Origin-Strategie detaillierter analysiert. Teilen Sie es als Referenz mit allen. Die Details lauten wie folgt:

Konzept: Die Same-Origin-Richtlinie ist eine wichtige Sicherheitsmetrik für clientseitige Skripte (insbesondere Javascript). Es entstand ursprünglich aus Netscape Navigator 2.0 und soll verhindern, dass ein Dokument oder Skript aus mehreren verschiedenen Quellen geladen wird.

Derselbe Ursprung bezieht sich hier auf: dasselbe Protokoll, denselben Domänennamen und denselben Port.

Essenz:

Das Wesentliche daran ist einfach: Es betrachtet vertrauenswürdige Inhalte, die von einer beliebigen Website geladen werden, als unsicher. Wenn Skripte, denen der Browser misstraut, in einer Sandbox ausgeführt werden, sollte ihnen nur der Zugriff auf Ressourcen derselben Site gestattet werden, nicht auf Ressourcen anderer Sites, die möglicherweise bösartig sind.

Warum gibt es eine Beschränkung auf die gleiche Herkunft?

Geben wir ein Beispiel: Ein Hackerprogramm verwendet beispielsweise IFrame, um die echte Bank-Anmeldeseite auf seiner Seite einzubetten. Wenn Sie sich mit Ihrem echten Benutzernamen und Passwort anmelden, kann der Inhalt seiner Seite gelesen werden Bitte geben Sie Ihre Eingaben in Ihr Formular ein, damit Sie den Benutzernamen und das Passwort leicht erhalten können.

Ajax-Anwendung:

Diese Sicherheitsbeschränkung wird in Ajax-Anwendungen verletzt.

In gewöhnlichen Javascript-Anwendungen können wir die href von Frame oder die src von IFrame ändern, um eine domänenübergreifende Übermittlung im GET-Modus zu erreichen, aber wir können nicht auf den Inhalt in domänenübergreifenden Frames/IFrames zugreifen.

Ajax verwendet XMLHTTP für die asynchrone Interaktion. Noch gefährlicher ist, dass XMLHTTP ein reines Javascript-Objekt ist, das vom Benutzer wahrgenommen wird. Daher hat XMLHTTP tatsächlich die ursprünglichen Sicherheitsbeschränkungen von Javascript durchbrochen.

Wenn wir die aktualisierungsfreien asynchronen Interaktionsmöglichkeiten von XMLHTTP nutzen möchten, aber nicht bereit sind, die Sicherheitsrichtlinien von Javascript offensichtlich zu brechen, besteht die Alternative darin, strenge Same-Origin-Einschränkungen zu XMLHTTP hinzuzufügen. Eine solche Sicherheitsrichtlinie ist der Sicherheitsrichtlinie von Applet sehr ähnlich. Die Einschränkung von IFrame besteht darin, dass es nicht auf Daten im domänenübergreifenden HTMLDOM zugreifen kann, während XMLHTTP die Übermittlung domänenübergreifender Anfragen grundsätzlich einschränkt .

Browser-Unterstützung: Der IE öffnet tatsächlich zwei Hintertüren für diese Sicherheitsrichtlinie: Er geht davon aus, dass Ihre lokalen Dateien natürlich wissen, auf welche Inhalte zugegriffen wird, sodass keine Ihrer lokalen Dateien auf externe Daten zugreift Warnung. Ein weiterer Grund: Wenn das Skript der von Ihnen besuchten Website beabsichtigt, auf domänenübergreifende Informationen zuzugreifen, wird lediglich ein Dialogfeld angezeigt, um Sie daran zu erinnern. Wenn eine betrügerische Website diese Methode verwendet, um Ihnen eine gefälschte Seite bereitzustellen, und Ihnen dann dabei hilft, sich über XMLHTTP aus der Ferne beim Server der echten Bank anzumelden. Nur einer der 10 Benutzer war verwirrt und klickte auf OK. Ihr Kontodiebstahl war erfolgreich! Denken Sie darüber nach, wie gefährlich das ist!

FireFox unterstützt dies nicht. Standardmäßig unterstützt FireFox überhaupt keine domänenübergreifenden XMLHTTP-Anfragen und bietet Hackern keine solche Möglichkeit.

Same-Origin-Strategie vermeiden:

JSON und dynamische Skript-Tags

src="http://yoursiteweb.com/findItinerary?username=sachiko&
reservierungNum=1234&output=json&callback=showItinerary" />

Wenn JavaScript-Code dynamisch ein <script>-Tag einfügt, greift der Browser auf die URL im src-Attribut zu. Dadurch werden die Informationen in der Abfragezeichenfolge an den Server gesendet. In Listing 1 werden Benutzername und Reservierung als Name-Wert-Paare übergeben. Darüber hinaus enthält die Abfragezeichenfolge das vom Server angeforderte Ausgabeformat und den Namen der Rückruffunktion (d. h. showItinerary). Nachdem das <script>-Tag geladen wurde, wird die Callback-Funktion ausgeführt und die vom Dienst zurückgegebenen Informationen werden über seine Parameter an die Callback-Funktion übergeben. </script>

Ajax-Proxy

Ajax-Proxy ist ein Proxyserver auf Anwendungsebene, der HTTP-Anfragen und -Antworten zwischen einem Webbrowser und einem Server vermittelt. Ajax-Proxys ermöglichen es Webbrowsern, die Same Origin Policy zu umgehen, sodass über XMLHttpRequest auf Server von Drittanbietern zugegriffen werden kann. Um diese Umgehung zu erreichen, stehen zwei Methoden zur Auswahl:
Die Client-Webanwendung kennt die URL des Drittanbieters und übergibt die URL als Anforderungsparameter in der HTTP-Anfrage an den Ajax-Proxy. Der Proxy leitet die Anfrage dann an [url]www.jb51.net[/url] weiter. Beachten Sie, dass die Verwendung von Proxyservern in der Implementierung der von Webanwendungsentwicklern verwendeten Ajax-Bibliothek verborgen sein kann. Für einen Webanwendungsentwickler könnte es so aussehen, als gäbe es überhaupt keine Same-Origin-Richtlinie.
Die Client-Webanwendung kennt die URL des Drittanbieters nicht und versucht, über HTTP auf Ressourcen auf dem Ajax-Proxyserver zuzugreifen. Mithilfe einer vordefinierten Codierungsregel wandelt der Ajax-Proxy die angeforderte URL in die URL des Drittanbieterservers um und ruft den Inhalt im Namen des Clients ab. Dadurch entsteht für den Webanwendungsentwickler der Eindruck, dass er direkt mit dem Proxyserver kommuniziert.

Greasemonkey

Greasemonkey ist eine Firefox-Erweiterung, die es Benutzern ermöglicht, den Stil und Inhalt von Webseiten dynamisch zu ändern. Greasemonkey-Benutzer können Benutzerskriptdateien mit einer Sammlung von URLs verknüpfen. Diese Skripte werden ausgeführt, wenn der Browser eine Seite von dieser Gruppe von URLs lädt. Greasemonkey bietet der API zusätzliche Berechtigungen für Benutzerskripte (im Vergleich zu den Berechtigungen für Skripte, die in der Browser-Sandbox ausgeführt werden).

GM_XMLHttpRequest ist eine dieser APIs, bei der es sich im Wesentlichen um eine XMLHttpRequest ohne dieselbe Ursprungsrichtlinie handelt. Benutzerskripte können das integrierte XMLHttpRequest des Browsers mit GM_XMLHttpRequest überschreiben, sodass XMLHttpRequest einen domänenübergreifenden Zugriff durchführen kann.

Die Nutzung von GM_XMLHttpRequest kann nur durch Zustimmung des Benutzers geschützt werden. Das heißt, Greasemonkey erfordert nur eine Benutzerkonfiguration, wenn eine Zuordnung zwischen einem neuen Benutzerskript und einer bestimmten Sammlung von URLs hergestellt wird. Es ist jedoch nicht schwer vorstellbar, dass einige Benutzer dazu verleitet werden könnten, die Installation zu akzeptieren, ohne die Konsequenzen vollständig zu verstehen.

Ich hoffe, dass dieser Artikel für das JavaScript-Programmierdesign aller hilfreich sein wird.