Moyens de contourner la politique de même origine

La même politique d'origine

Je voulais créer un wiki communautaire concernant les politiques HTML / JS de même origine pour aider, espérons-le, tous ceux qui recherchent ce sujet. C'est l'un des sujets les plus recherchés sur SO et il n'y a pas de wiki consolidé pour cela, alors j'y vais :)

La même politique d'origine empêche un document ou un script chargé à partir d'une origine d'obtenir ou de définir les propriétés d'un document à partir d'une autre origine. Cette politique remonte à Netscape Navigator 2.0.

Quelles sont certaines de vos façons préférées de contourner les politiques de même origine?

Veuillez garder des exemples verbeux et de préférence également relier vos sources.

La document.domainméthode

• Type de méthode: iframe .

Notez qu'il s'agit d'une méthode iframe qui définit la valeur de document.domain sur un suffixe du domaine actuel. Si tel est le cas, le domaine le plus court est utilisé pour les contrôles d'origine ultérieurs. Par exemple, supposons qu'un script dans le document à http://store.company.com/dir/other.htmlexécute l'instruction suivante:

document.domain = "company.com";

Une fois cette instruction exécutée, la page passera la vérification d'origine avec http://company.com/dir/page.html. Cependant, par le même raisonnement, company.com ne pouvait pas mettre document.domain à othercompany.com.

Avec cette méthode, vous seriez autorisé à exécuter du javascript à partir d'une iframe provenant d'un sous-domaine sur une page provenant du domaine principal. Cette méthode n'est pas adaptée aux ressources inter-domaines car les navigateurs comme Firefox ne vous permettront pas de changer le document.domainen un domaine complètement étranger.

Source: https://developer.mozilla.org/en/Same_origin_policy_for_JavaScript

La méthode de partage de ressources cross-origin

• Type de méthode: AJAX .

Cross-Origin Resource Sharing (CORS) est une ébauche de travail du W3C qui définit la manière dont le navigateur et le serveur doivent communiquer lors de l'accès aux sources entre les origines. L'idée de base derrière CORS est d'utiliser des en-têtes HTTP personnalisés pour permettre au navigateur et au serveur de se connaître suffisamment pour déterminer si la demande ou la réponse doit réussir ou échouer.

Pour une requête simple, qui utilise soit GETou POSTsans en-têtes personnalisés et dont le corps est text/plain, la requête est envoyée avec un en-tête supplémentaire appelé Origin. L'en-tête Origin contient l'origine (protocole, nom de domaine et port) de la page demandeuse afin que le serveur puisse facilement déterminer s'il doit ou non servir une réponse. Un exemple d'en- Origintête pourrait ressembler à ceci:

Origin: http://www.stackoverflow.com

Si le serveur décide que la demande doit être autorisée, il envoie un en- Access-Control-Allow-Origintête faisant écho à la même origine qui a été envoyée ou *s'il s'agit d'une ressource publique. Par exemple:

Access-Control-Allow-Origin: http://www.stackoverflow.com

Si cet en-tête est manquant ou si les origines ne correspondent pas, le navigateur refuse la demande. Si tout va bien, le navigateur traite la demande. Notez que ni les demandes ni les réponses ne contiennent d'informations sur les cookies.

L'équipe Mozilla suggère dans son article sur CORS que vous devriez vérifier l'existence de la withCredentials propriété pour déterminer si le navigateur prend en charge CORS via XHR. Vous pouvez alors coupler avec l'existence de l' XDomainRequestobjet pour couvrir tous les navigateurs:

function createCORSRequest(method, url){
    var xhr = new XMLHttpRequest();
    if ("withCredentials" in xhr){
        xhr.open(method, url, true);
    } else if (typeof XDomainRequest != "undefined"){
        xhr = new XDomainRequest();
        xhr.open(method, url);
    } else {
        xhr = null;
    }
    return xhr;
}

var request = createCORSRequest("get", "http://www.stackoverflow.com/");
if (request){
    request.onload = function() {
        // ...
    };
    request.onreadystatechange = handler;
    request.send();
}

Notez que pour que la méthode CORS fonctionne, vous devez avoir accès à n'importe quel type de mécanisme d'en-tête de serveur et ne pouvez pas simplement accéder à une ressource tierce.

Source: http://www.nczonline.net/blog/2010/05/25/cross-domain-ajax-with-cross-origin-resource-sharing/

La window.postMessageméthode

• Type de méthode: iframe .

window.postMessage, lorsqu'il est appelé, provoque MessageEventl'envoi de a à la fenêtre cible lorsqu'un script en attente qui doit être exécuté se termine (par exemple, les gestionnaires d'événements restants s'il window.postMessageest appelé à partir d'un gestionnaire d'événements, les délais d'attente précédemment définis, etc.). Le MessageEventa le type message, une datapropriété qui est définie sur la valeur de chaîne du premier argument fourni à window.postMessage, une originpropriété correspondant à l'origine du document principal dans la fenêtre appelant window.postMessageau moment de l' window.postMessageappel, et une sourcepropriété qui est la fenêtre de qui window.postMessageest appelé.

Pour l'utiliser window.postMessage, un écouteur d'événement doit être attaché:

    // Internet Explorer
    window.attachEvent('onmessage',receiveMessage);

    // Opera/Mozilla/Webkit
    window.addEventListener("message", receiveMessage, false);

Et une receiveMessagefonction doit être déclarée:

function receiveMessage(event)
{
    // do something with event.data;
}

L'iframe hors site doit également envoyer correctement les événements via postMessage:

<script>window.parent.postMessage('foo','*')</script>

Toute fenêtre peut accéder à cette méthode sur n'importe quelle autre fenêtre, à tout moment, quel que soit l'emplacement du document dans la fenêtre, pour lui envoyer un message. Par conséquent, tout écouteur d'événement utilisé pour recevoir des messages doit d'abord vérifier l'identité de l'expéditeur du message, en utilisant l'origine et éventuellement les propriétés source. Cela ne peut pas être sous- estimé : le fait de ne pas vérifier les propriétés originet éventuellement les sourcepropriétés permet des attaques de script intersite.

Source: https://developer.mozilla.org/en/DOM/window.postMessage

La méthode du proxy inverse

• Type de méthode: Ajax

La configuration d'un proxy inverse simple sur le serveur permettra au navigateur d'utiliser des chemins relatifs pour les requêtes Ajax, tandis que le serveur agirait en tant que proxy vers n'importe quel emplacement distant.

Si vous utilisez mod_proxy dans Apache, la directive de configuration fondamentale pour configurer un proxy inverse est le ProxyPass. Il est généralement utilisé comme suit:

ProxyPass     /ajax/     http://other-domain.com/ajax/

Dans ce cas, le navigateur pourrait demander en /ajax/web_service.xmltant qu'URL relative, mais le serveur le servirait en agissant en tant que proxy pour http://other-domain.com/ajax/web_service.xml.

Une caractéristique intéressante de cette méthode est que le proxy inverse peut facilement distribuer des requêtes vers plusieurs back-ends, agissant ainsi comme un équilibreur de charge .

J'utilise JSONP.

En gros, vous ajoutez

<script src="http://..../someData.js?callback=some_func"/>

sur ta page.

some_func () devrait être appelé afin que vous soyez averti que les données sont dans.

AnyOrigin ne fonctionnait pas bien avec certains sites https, je viens donc d'écrire une alternative open source appelée whatorigin.org qui semble bien fonctionner avec https.

Code sur github .

Le moyen le plus récent de surmonter la politique de même origine que j'ai trouvé est http://anyorigin.com/

Le site est conçu pour que vous lui donniez n'importe quelle URL et il génère pour vous du code javascript / jquery qui vous permet d'obtenir le html / data, quelle que soit son origine. En d'autres termes, toute URL ou page Web est une requête JSONP.

Je l'ai trouvé assez utile :)

Voici un exemple de code javascript de n'importe quelle origine:

$.getJSON('http://anyorigin.com/get?url=google.com&callback=?', function(data){
    $('#output').html(data.contents);
});

Je ne peux pas revendiquer le mérite de cette image, mais elle correspond à tout ce que je sais sur ce sujet et offre un peu d'humour en même temps.

http://www.flickr.com/photos/iluvrhinestones/5889370258/

Le JSONP vient à l'esprit:

JSONP ou "JSON with padding" est un complément au format de données JSON de base, un modèle d'utilisation qui permet à une page de demander et d'utiliser de manière plus significative JSON à partir d'un serveur autre que le serveur principal. JSONP est une alternative à une méthode plus récente appelée Partage de ressources inter-origines.

Personnellement, window.postMessagec'est le moyen le plus fiable que j'ai trouvé pour les navigateurs modernes. Vous devez faire un peu plus de travail pour vous assurer de ne pas vous exposer aux attaques XSS, mais c'est un compromis raisonnable.

Il existe également plusieurs plugins pour les boîtes à outils Javascript populaires window.postMessagequi fournissent des fonctionnalités similaires aux navigateurs plus anciens en utilisant les autres méthodes décrites ci-dessus.

Eh bien, j'ai utilisé curl en PHP pour contourner cela. J'ai un webservice fonctionnant dans le port 82.

<?php

$curl = curl_init();
$timeout = 30;
$ret = "";
$url="http://localhost:82/put_val?val=".$_GET["val"];
curl_setopt ($curl, CURLOPT_URL, $url);
curl_setopt ($curl, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt ($curl, CURLOPT_MAXREDIRS, 20);
curl_setopt ($curl, CURLOPT_RETURNTRANSFER, 1);
curl_setopt ($curl, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5");
curl_setopt ($curl, CURLOPT_CONNECTTIMEOUT, $timeout);
$text = curl_exec($curl);
echo $text;

?>

Voici le javascript qui fait l'appel au fichier PHP

function getdata(obj1, obj2) {

    var xmlhttp;

    if (window.XMLHttpRequest)
            xmlhttp=new XMLHttpRequest();
    else
            xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");

    xmlhttp.onreadystatechange=function()
    {
        if (xmlhttp.readyState==4 && xmlhttp.status==200)
        {
                document.getElementById("txtHint").innerHTML=xmlhttp.responseText;
        }
    }
    xmlhttp.open("GET","phpURLFile.php?eqp="+obj1+"&val="+obj2,true);
    xmlhttp.send();
}

Mon HTML fonctionne sur WAMP dans le port 80. Alors voilà, la même politique d'origine a été contournée :-)

Voici quelques solutions de contournement et explications de la même politique d'origine:
Blog de Thiru - Solution de contournement de la même politique d'origine du navigateur

Cette analyse à peu près ce qui est disponible là-bas: http://www.slideshare.net/SlexAxton/breaking-the-cross-domain-barrier

Pour la solution postMessage, jetez un œil à:

https://github.com/chrissrogers/jquery-postmessage/blob/master/jquery.ba-postmessage.js

et une version légèrement différente:

https://github.com/thomassturm/ender-postmessage/blob/master/ender-postmessage.js