Formas de contornar a política de mesma origem

A mesma política de origem

Eu queria criar um wiki de comunidade sobre políticas de mesma origem em HTML / JS para , com sorte, ajudar qualquer pessoa que pesquisar esse tópico. Este é um dos tópicos mais procurados em SO e não há um wiki consolidado para ele, então aqui vou 🙂

A mesma política de origem impede que um documento ou script carregado de uma origem obtenha ou defina propriedades de um documento de outra origem. Esta política data desde o Netscape Navigator 2.0.

Quais são algumas das suas formas favoritas de contornar as políticas de mesma origem?

Por favor, mantenha exemplos verbosos e de preferência também vincule suas fonts.

    O método document.domain

    • Tipo de método: iframe .

    Observe que esse é um método iframe que define o valor de document.domain como um sufixo do domínio atual. Se isso acontecer, o domínio mais curto será usado para verificações de origem subseqüentes. Por exemplo, suponha que um script no documento em http://store.company.com/dir/other.html execute a seguinte instrução:

     document.domain = "company.com"; 

    Depois que essa instrução for executada, a página passará a verificação de origem com http://company.com/dir/page.html . No entanto, pelo mesmo raciocínio, company.com não pôde definir document.domain como othercompany.com .

    Com esse método, você teria permissão para expor o JavaScript de um iframe originado em um subdomínio em uma página originada no domínio principal. Esse método não é adequado para resources entre domínios, pois navegadores como o Firefox não permitirão que você altere o document.domain para um domínio completamente alienígena.

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

    O método de compartilhamento de resources de origem cruzada

    • Tipo de método: AJAX .

    O CORS ( Cross-Origin Resource Sharing ) é um Rascunho de Trabalho do W3C que define como o navegador e o servidor devem se comunicar ao acessar fonts entre origens. A idéia básica por trás do CORS é usar headers HTTP personalizados para permitir que o navegador e o servidor saibam o suficiente um sobre o outro para determinar se a solicitação ou resposta deve ter êxito ou falhar.

    Para uma solicitação simples, que usa GET ou POST sem headers personalizados e cujo corpo é text/plain , a solicitação é enviada com um header extra chamado Origin . O header Origem contém a origem (protocolo, nome de domínio e porta) da página solicitante para que o servidor possa determinar com facilidade se deve ou não servir uma resposta. Um exemplo de header Origin pode ter esta aparência:

     Origin: http://www.stackoverflow.com 

    Se o servidor decidir que a solicitação deve ser permitida, ele envia um header Access-Control-Allow-Origin retornando a mesma origem que foi enviada ou * se for um recurso público. Por exemplo:

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

    Se esse header estiver faltando ou as origens não corresponderem, o navegador não permitirá a solicitação. Se tudo estiver bem, o navegador processará a solicitação. Observe que nem as solicitações nem as respostas incluem informações de cookies.

    A equipe do Mozilla sugere em seu post sobre o CORS que você deve verificar a existência da propriedade withCredentials para determinar se o navegador suporta o CORS via XHR. Você pode então XDomainRequest com a existência do object XDomainRequest para cobrir todos os navegadores:

     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(); } 

    Observe que, para o método CORS funcionar, você precisa ter access a qualquer tipo de mecanismo de header de servidor e não pode simplesmente acessar qualquer recurso de terceiros.

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

    O método window.postMessage

    • Tipo de método: iframe .

    window.postMessage , quando chamado, faz com que um MessageEvent seja despachado na janela de destino quando qualquer script pendente que deve ser executado é concluído (por exemplo, manipuladores de events restantes se window.postMessage for chamado de um manipulador de events, tempos limite pendentes previamente definidos, etc. ). O MessageEvent possui a mensagem type, uma propriedade de data que é configurada para o valor de string do primeiro argumento fornecido para window.postMessage , uma propriedade de origin correspondente à origem do documento principal na janela que chama window.postMessage na window.postMessage tempo window.postMessage foi chamado e uma propriedade de source que é a janela da qual window.postMessage é chamada.

    Para usar window.postMessage , um ouvinte de evento deve ser anexado:

      // Internet Explorer window.attachEvent('onmessage',receiveMessage); // Opera/Mozilla/Webkit window.addEventListener("message", receiveMessage, false); 

    E uma function receiveMessage deve ser declarada:

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

    O iframe fora do site também deve enviar events corretamente via postMessage :

      

    Qualquer janela pode acessar este método em qualquer outra janela, a qualquer momento, independentemente da localização do documento na janela, para enviar uma mensagem. Conseqüentemente, qualquer ouvinte de evento usado para receber mensagens deve primeiro verificar a identidade do remetente da mensagem, usando as propriedades de origem e possivelmente de origem. Isso não pode ser subestimado: a falha na verificação da origin e possivelmente das propriedades de source permite ataques de script entre sites.

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

    O método de proxy reverso

    • Tipo de método: Ajax

    A configuração de um proxy reverso simples no servidor permitirá que o navegador use caminhos relativos para as solicitações do Ajax, enquanto o servidor atuaria como um proxy para qualquer local remoto.

    Se estiver usando o mod_proxy no Apache, a diretiva de configuração fundamental para configurar um proxy reverso é o ProxyPass . Normalmente é usado da seguinte maneira:

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

    Nesse caso, o navegador poderia solicitar o /ajax/web_service.xml como uma URL relativa, mas o servidor serviria isso agindo como um proxy para http://other-domain.com/ajax/web_service.xml .

    Uma característica interessante deste método é que o proxy reverso pode facilmente distribuir solicitações para vários back-ends, agindo assim como um balanceador de carga .

    Eu uso o JSONP.

    Basicamente, você adiciona

      

    na sua página.

    some_func () deve ser chamado para que você seja notificado de que os dados estão dentro

    AnyOrigin não funcionou bem com alguns sites https, então eu acabei de escrever uma alternativa open source chamada whateverorigin.org que parece funcionar bem com https.

    Código no github .

    A maneira mais recente de superar a política de mesma origem que encontrei é http://anyorigin.com/

    O site feito para que você dê a ele qualquer url e ele gere código javascript / jquery para você que permite que você obtenha o html / data, independentemente de sua origem. Em outras palavras, isso torna qualquer URL ou página da Web uma solicitação JSONP.

    Eu achei muito útil 🙂

    Aqui está um exemplo de código javascript de anyorigin:

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

    Não posso reivindicar crédito por essa imagem, mas ela corresponde a tudo o que sei sobre esse assunto e oferece um pouco de humor ao mesmo tempo.

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

    O JSONP vem à mente:

    JSONP ou “JSON com preenchimento” é um complemento do formato de dados JSON de base, um padrão de uso que permite que uma página solicite e use de maneira mais significativa o JSON de um servidor diferente do servidor principal. O JSONP é uma alternativa para um método mais recente chamado compartilhamento de resources entre origens.

    Pessoalmente, window.postMessage é a maneira mais confiável que encontrei para navegadores modernos. Você precisa fazer um pouco mais de trabalho para se certificar de que não está se deixando aberto a ataques XSS, mas é uma troca razoável.

    Há também vários plug-ins para os kits de ferramentas Javascript mais conhecidos que envolvem window.postMessage que fornecem funcionalidade semelhante a navegadores mais antigos usando os outros methods discutidos acima.

    Bem, eu usei o curl em PHP para contornar isso. Eu tenho um webservice em execução na porta 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; ?> 

    Aqui está o javascript que faz a chamada para o arquivo 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(); } 

    Meu HTML é executado no WAMP na porta 80. Então lá vamos nós, a mesma política de origem foi contornada 🙂

    Aqui estão algumas soluções e explicações sobre a política de mesma origem:
    Blog do Thiru – Solução alternativa de política de origem do navegador