Quelle est la même politique d'origine en javascript

En JavaScript, la politique de même origine est une mesure de sécurité importante pour les scripts côté client (en particulier Javascript), c'est-à-dire que deux pages avec le même protocole (protocole), port et hôte (nom de domaine) appartiennent au même source.

L'environnement d'exploitation de ce tutoriel : système Windows 7, JavaScript version 1.8.5, ordinateur Dell G3.

Qu'est-ce que la politique de même origine ?

La politique de même origine est une mesure de sécurité importante pour les scripts côté client, en particulier Javascript. Il est issu de Netscape Navigator 2.0 et son objectif était d'empêcher le chargement d'un document ou d'un script à partir de plusieurs sources différentes.

Même politique d'origine, c'est-à-dire que deux pages avec le même protocole, le même port (si spécifié) et l'hôte (nom de domaine) appartiennent à la même source.

Par exemple, pour l'URL http://www.example.com/dir/page.html, le protocole
est http:// et
le nom de domaine est www.exemple.com, le port
est 80 (le port par défaut peut être omis). Son homologie est la suivante. http://www.example.com/dir/page.html这个网址，
协议是http://，
域名是www.example.com，
端口是80（默认端口可以省略）。它的同源情况如下。

    http://www.example.com/dir2/other.html：同源
    http://example.com/dir/other.html：不同源（域名不同）
    http://v2.www.example.com/dir/other.html：不同源（域名不同）
    http://www.example.com:81/dir/other.html：不同源（端口不同）

精髓：

它的精髓很简单：它认为自任何站点装载的信赖内容是不安全的。当被浏览器半信半疑的脚本运行在沙箱时，它们应该只被允许访问来自同一站点的资源，而不是那些来自其它站点可能怀有恶意的资源。

为什么要有同源限制？

我们举例说明：比如一个黑客程序，他利用IFrame把真正的银行登录页面嵌到他的页面上，当你使用真实的用户名，密码登录时，他的页面就可以通过Javascript读取到你的表单中input中的内容，这样用户名，密码就轻松到手了。

同源政策的目的，是为了保证用户信息的安全，防止恶意的网站窃取数据。

设想这样一种情况：A网站是一家银行，用户登录以后，又去浏览其他网站。如果其他网站可以读取A网站的 Cookie，会发生什么？

很显然，如果 Cookie 包含隐私（比如存款总额），这些信息就会泄漏。更可怕的是，Cookie 往往用来保存用户的登录状态，如果用户没有退出登录，其他网站就可以冒充用户，为所欲为。因为浏览器同时还规定，提交表单不受同源政策的限制。

由此可见，”同源政策”是必需的，否则 Cookie 可以共享，互联网就毫无安全可言了。

限制范围

随着互联网的发展，”同源政策”越来越严格。目前，如果非同源，共有三种行为受到限制。

（1） Cookie、LocalStorage 和 IndexDB 无法读取。

（2） DOM 无法获得。

（3） Ajax 请求不能发送。

虽然这些限制是必要的，但是有时很不方便，合理的用途也受到影响。下面，我将详细介绍，如何规避上面三种限制。

规避方法

1、Cookie

Cookie 是服务器写入浏览器的一小段信息，只有同源的网页才能共享。但是，两个网页一级域名相同，只是二级域名不同，浏览器允许通过设置document.domain共享 Cookie。

举例来说，A网页是http://w1.example.com/a.html，B网页是http://w2.example.com/b.html，那么只要设置相同的document.domain，两个网页就可以共享Cookie。

document.domain = 'example.com';

现在，A网页通过脚本设置一个 Cookie

document.cookie = "test1=hello";

B网页就可以读到这个 Cookie。

var allCookie = document.cookie;

这种方法只适用于 Cookie 和 iframe 窗口，LocalStorage 和 IndexDB 无法通过这种方法，
规避同源政策，而要使用下文介绍的PostMessage API。

另外，服务器也可以在设置Cookie的时候，指定Cookie的所属域名为一级域名，比如.example.com。

 Set-Cookie: key=value; domain=.example.com; path=/

这样的话，二级域名和三级域名不用做任何设置，都可以读取这个Cookie。

2、iframe

如果两个网页不同源，就无法拿到对方的DOM。典型的例子是iframe窗口和window.open方法打开的窗口，它们与父窗口无法通信。

比如，父窗口运行下面的命令，如果iframe窗口不是同源，就会报错

document.getElementById("myIFrame").contentWindow.document
 // Uncaught DOMException: Blocked a frame from accessing a cross-origin frame.

上面命令中，父窗口想获取子窗口的DOM，因为跨源导致报错。

反之亦然，子窗口获取主窗口的DOM也会报错。

 window.parent.document.body    // 报错

如果两个窗口一级域名相同，只是二级域名不同，那么设置上一节介绍的document.domain

var src = originURL + '#' + data;
document.getElementById('myIFrame').src = src;

L'essence :

• L'essence est simple : il considère que le contenu fiable chargé à partir de n'importe quel site est dangereux. Lorsque des scripts dont le navigateur n'a pas confiance sont exécutés dans un bac à sable, ils ne doivent être autorisés à accéder qu'aux ressources du même site, et non à celles d'autres sites susceptibles d'être malveillants.

Pourquoi y a-t-il une restriction de même origine ?

• Donnons un exemple : par exemple, un programme de hacker utilise IFrame pour intégrer la vraie page de connexion bancaire sur sa page. Lorsque vous vous connectez avec votre vrai nom d'utilisateur et votre mot de passe, sa page est accessible via Javascript. Lisez le. contenu de l'entrée dans votre formulaire, afin que le nom d'utilisateur et le mot de passe puissent être facilement obtenus.

Le but de la politique de même origine est d'assurer la sécurité des informations des utilisateurs et d'empêcher les sites Web malveillants de voler des données.

Imaginez une situation comme celle-ci : le site Web A est une banque. Une fois connecté, l'utilisateur navigue sur d'autres sites Web. Que se passe-t-il si d’autres sites Web peuvent lire les cookies du site Web A ?

Évidemment, si le cookie contient des informations confidentielles (comme le montant total du dépôt), ces informations seront divulguées. Ce qui est encore plus effrayant, c’est que les cookies sont souvent utilisés pour enregistrer le statut de connexion de l’utilisateur. Si l’utilisateur ne se déconnecte pas, d’autres sites Web peuvent usurper l’identité de l’utilisateur et faire ce qu’il veut. Parce que le navigateur stipule également que la soumission de formulaires n'est pas limitée par la même politique d'origine. 🎜🎜On voit que la « politique de même origine » est nécessaire, sinon les cookies peuvent être partagés et Internet ne sera pas du tout sécurisé. 🎜🎜🎜🎜Portée restreinte🎜🎜🎜🎜Avec le développement d'Internet, la « Same Origin Policy » devient de plus en plus stricte. Actuellement, trois comportements sont restreints s’ils ne sont pas de même origine. 🎜

window.onhashchange = checkMessage;

    function checkMessage() {
      var message = window.location.hash;
      // ...
    }

🎜Bien que ces restrictions soient nécessaires, elles sont parfois gênantes et affectent des objectifs raisonnables. Ci-dessous, je présenterai en détail comment contourner les trois limitations ci-dessus. 🎜🎜🎜🎜Méthodes à éviter 🎜🎜🎜🎜🎜 1. Cookie 🎜🎜🎜Le cookie est un petit élément d'information écrit par le serveur dans le navigateur. Seules les pages Web ayant la même origine peuvent être partagées. Cependant, les noms de domaine de premier niveau des deux pages Web sont les mêmes, mais les noms de domaine de deuxième niveau sont différents. Le navigateur permet le partage de cookies en définissant document.domain. 🎜🎜Par exemple, la page Web A est http://w1.example.com/a.html, la page Web B est http://w2.example.com/b.html < /code>, alors tant que le même document.domain est défini, les deux pages Web peuvent partager des cookies. 🎜<div class="code" style="position:relative; padding:0px; margin:0px;"><div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:js;toolbar:false;"> parent.location.href= target + &quot;#&quot; + hash;</pre><div class="contentsignin">Copier après la connexion</div></div><div class="contentsignin">Copier après la connexion</div></div>🎜Maintenant, la page Web A définit un cookie via un script🎜<div class="code" style="position:relative; padding:0px; margin:0px;"><div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:js;toolbar:false;">window.name = data;</pre><div class="contentsignin">Copier après la connexion</div></div><div class="contentsignin">Copier après la connexion</div></div>🎜La page Web B peut lire ce cookie. 🎜<div class="code" style="position:relative; padding:0px; margin:0px;"><div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:js;toolbar:false;">location = &amp;#39;http://parent.url.com/xxx.html&amp;#39;;</pre><div class="contentsignin">Copier après la connexion</div></div><div class="contentsignin">Copier après la connexion</div></div>🎜Cette méthode s'applique uniquement aux fenêtres Cookie et iframe. LocalStorage et IndexDB ne peuvent pas <br/> contourner la même politique d'origine via cette méthode et doivent utiliser l'API PostMessage présentée ci-dessous. 🎜🎜De plus, le serveur peut également spécifier le nom de domaine du cookie comme nom de domaine de premier niveau lors de la configuration du cookie, par exemple .example.com. 🎜<div class="code" style="position:relative; padding:0px; margin:0px;"><div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:js;toolbar:false;">var data = document.getElementById(&amp;#39;myFrame&amp;#39;).contentWindow.name;</pre><div class="contentsignin">Copier après la connexion</div></div><div class="contentsignin">Copier après la connexion</div></div>🎜Dans ce cas, le nom de domaine de deuxième niveau et le nom de domaine de troisième niveau peuvent lire ce cookie sans aucun paramétrage. 🎜🎜🎜2. iframe🎜🎜🎜Si les deux pages Web ont des sources différentes, elles ne peuvent pas obtenir le DOM de l'autre partie. Des exemples typiques sont les fenêtres iframe et les fenêtres ouvertes par la méthode window.open, qui ne peuvent pas communiquer avec la fenêtre parent. 🎜🎜Par exemple, si la fenêtre parent exécute la commande suivante, si la fenêtre iframe ne provient pas de la même source, une erreur sera signalée🎜<div class="code" style="position:relative; padding:0px; margin:0px;"><div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:js;toolbar:false;"> var popup = window.open(&amp;#39;http://bbb.com&amp;#39;, &amp;#39;title&amp;#39;); popup.postMessage(&amp;#39;Hello World!&amp;#39;, &amp;#39;http://bbb.com&amp;#39;);</pre><div class="contentsignin">Copier après la connexion</div></div><div class="contentsignin">Copier après la connexion</div></div>🎜Dans la commande ci-dessus, la fenêtre parent souhaite obtenir le DOM de la fenêtre enfant , et une erreur sera signalée en raison d'une origine croisée. 🎜🎜 Vice versa, une erreur sera également signalée lorsque la sous-fenêtre obtiendra le DOM de la fenêtre principale. 🎜<div class="code" style="position:relative; padding:0px; margin:0px;"><div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:js;toolbar:false;">window.opener.postMessage(&amp;#39;Nice to see you&amp;#39;, &amp;#39;http://aaa.com&amp;#39;);</pre><div class="contentsignin">Copier après la connexion</div></div><div class="contentsignin">Copier après la connexion</div></div>🎜Si les noms de domaine de premier niveau des deux fenêtres sont identiques, mais que les noms de domaine de deuxième niveau sont différents, alors la définition de l'attribut <code>document.domain introduit dans la section précédente peut contourner le politique de même origine et obtenez le DOM. 🎜🎜Pour les sites Web d'origines complètement différentes, il existe actuellement trois méthodes pour résoudre le problème de communication des fenêtres inter-domaines. 🎜🎜🎜identifiant de fragment🎜🎜window.name🎜🎜API de messagerie inter-documents (Messagerie cross-document)🎜🎜🎜🎜2.1 Identificateur de fragment🎜🎜

片段标识符（fragment identifier）指的是，URL的#号后面的部分，比如http://example.com/x.html#fragment的#fragment。如果只是改变片段标识符，页面不会重新刷新。

父窗口可以把信息写入子窗口的片段标识符。

var src = originURL + '#' + data;
document.getElementById('myIFrame').src = src;

子窗口通过监听hashchange事件得到通知。

window.onhashchange = checkMessage;

    function checkMessage() {
      var message = window.location.hash;
      // ...
    }

同样的，子窗口也可以改变父窗口的片段标识符。

 parent.location.href= target + "#" + hash;

2.2 window.name

浏览器窗口有window.name属性。这个属性的最大特点是，无论是否同源，只要在同一个窗口里，前一个网页设置了这个属性，后一个网页可以读取它。

父窗口先打开一个子窗口，载入一个不同源的网页，该网页将信息写入window.name属性。

window.name = data;

接着，子窗口跳回一个与主窗口同域的网址。

location = 'http://parent.url.com/xxx.html';

然后，主窗口就可以读取子窗口的window.name了。

var data = document.getElementById('myFrame').contentWindow.name;

这种方法的优点是，window.name容量很大，可以放置非常长的字符串；缺点是必须监听子窗口window.name属性的变化，影响网页性能。

2.3 window.postMessage

上面两种方法都属于破解，HTML5为了解决这个问题，引入了一个全新的API：跨文档通信 API（Cross-document messaging）。

这个API为window对象新增了一个window.postMessage方法，允许跨窗口通信，不论这两个窗口是否同源。

举例来说，父窗口http://aaa.com向子窗口http://bbb.com发消息，调用postMessage方法就可以了。

 var popup = window.open('http://bbb.com', 'title');
 popup.postMessage('Hello World!', 'http://bbb.com');

postMessage方法的第一个参数是具体的信息内容，第二个参数是接收消息的窗口的源（origin），即”协议 + 域名 + 端口”。也可以设为*，表示不限制域名，向所有窗口发送。

子窗口向父窗口发送消息的写法类似。

window.opener.postMessage('Nice to see you', 'http://aaa.com');

父窗口和子窗口都可以通过message事件，监听对方的消息。

window.addEventListener('message', function(e) {
  console.log(e.data);
},false);

message事件的事件对象event，提供以下三个属性。

    event.source：发送消息的窗口
    event.origin: 消息发向的网址
    event.data: 消息内容

下面的例子是，子窗口通过event.source属性引用父窗口，然后发送消息。

    window.addEventListener('message', receiveMessage);
    function receiveMessage(event) { 
       event.source.postMessage('Nice to see you!', '*');
    }

event.origin属性可以过滤不是发给本窗口的消息。

window.addEventListener('message', receiveMessage);
 function receiveMessage(event) {
   if (event.origin !== 'http://aaa.com') return;
   if (event.data === 'Hello World') {
       event.source.postMessage('Hello', event.origin);
   } else {
     console.log(event.data);
   }
 }

2.4 LocalStorage

通过window.postMessage，读写其他窗口的 LocalStorage 也成为了可能。

下面是一个例子，主窗口写入iframe子窗口的localStorage。

window.onmessage = function(e) {
   if (e.origin !== 'http://bbb.com') {
        return;
   }   
   var payload = JSON.parse(e.data);
   localStorage.setItem(payload.key, JSON.stringify(payload.data));
 };

上面代码中，子窗口将父窗口发来的消息，写入自己的LocalStorage。

父窗口发送消息的代码如下。

var win = document.getElementsByTagName('iframe')[0].contentWindow;
var obj = { name: 'Jack' };
win.postMessage(JSON.stringify({key: 'storage', data: obj}), 'http://bbb.com');

加强版的子窗口接收消息的代码如下。

window.onmessage = function(e) {
 if (e.origin !== 'http://bbb.com') return;
 var payload = JSON.parse(e.data);
 switch (payload.method) {
   case 'set':
     localStorage.setItem(payload.key, JSON.stringify(payload.data));
     break;
   case 'get':
     var parent = window.parent;
     var data = localStorage.getItem(payload.key);
     parent.postMessage(data, 'http://aaa.com');
     break;
   case 'remove':
     localStorage.removeItem(payload.key);
     break;
 }
};

加强版的父窗口发送消息代码如下。

var win = document.getElementsByTagName('iframe')[0].contentWindow;
 var obj = { name: 'Jack' };
 // 存入对象
 win.postMessage(JSON.stringify({key: 'storage', method: 'set', data: obj}), 'http://bbb.com');
 // 读取对象
 win.postMessage(JSON.stringify({key: 'storage', method: "get"}), "*");
 window.onmessage = function(e) {
   if (e.origin != 'http://aaa.com') return;
   // "Jack"
   console.log(JSON.parse(e.data).name);
 };

3、Ajax

同源政策规定，AJAX请求只能发给同源的网址，否则就报错。

除了架设服务器代理（浏览器请求同源服务器，再由后者请求外部服务），有三种方法规避这个限制。

    JSONP
    WebSocket
    CORS

3.1 JSONP

JSONP是服务器与客户端跨源通信的常用方法。最大特点就是简单适用，老式浏览器全部支持，服务器改造非常小。

它的基本思想是，网页通过添加一个<script>元素，向服务器请求JSON数据，这种做法不受同源政策限制；服务器收到请求后，将数据放在一个指定名字的回调函数里传回来。

首先，网页动态插入<script>元素，由它向跨源网址发出请求。

   function addScriptTag(src) {
      var script = document.createElement('script');
      script.setAttribute("type","text/javascript");
      script.src = src;
      document.body.appendChild(script);
    }

    window.onload = function () {
      addScriptTag('http://example.com/ip?callback=foo');
    }    function foo(data) {
      console.log('Your public IP address is: ' + data.ip);
    };

上面代码通过动态添加<script>元素，向服务器example.com发出请求。注意，该请求的查询字符串有一个callback参数，用来指定回调函数的名字，这对于JSONP是必需的。

服务器收到这个请求以后，会将数据放在回调函数的参数位置返回。

foo({
  "ip": "8.8.8.8"
});

由于<script>元素请求的脚本，直接作为代码运行。这时，只要浏览器定义了foo函数，该函数就会立即调用。作为参数的JSON数据被视为JavaScript对象，而不是字符串，因此避免了使用JSON.parse的步骤。

3.2 WebSocket

WebSocket是一种通信协议，使用ws://（非加密）和wss://（加密）作为协议前缀。该协议不实行同源政策，只要服务器支持，就可以通过它进行跨源通信。

下面是一个例子，浏览器发出的WebSocket请求的头信息（摘自维基百科）。

    GET /chat HTTP/1.1
    Host: server.example.com
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
    Sec-WebSocket-Protocol: chat, superchat
    Sec-WebSocket-Version: 13
    Origin: http://example.com

上面代码中，有一个字段是Origin，表示该请求的请求源（origin），即发自哪个域名。

正是因为有了Origin这个字段，所以WebSocket才没有实行同源政策。因为服务器可以根据这个字段，判断是否许可本次通信。如果该域名在白名单内，服务器就会做出如下回应。

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

3.3 CORS

CORS est l'abréviation de Cross-Origin Resource Sharing. Il s'agit d'une norme du W3C et constitue la solution fondamentale pour les requêtes AJAX d'origine croisée. Comparé à JSONP qui ne peut envoyer que des requêtes GET, CORS autorise tout type de requête.

【Recommandations associées : Tutoriel d'apprentissage Javascript】

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!