Executando um ataque de falsificação de solicitação entre sites
Neste artigo, você obterá as informações necessárias do aplicativo para saber o que o site de ataque deve fazer para enviar solicitações válidas ao servidor vulnerável. Em seguida, você criará uma página que simula os pedidos legítimos e trata o usuário a visitar essa página enquanto autenticado. Você também fará algumas iterações sobre a prova básica de conceito para fazer com que pareça mais um ataque do mundo real, onde a vítima não percebe. Observe que o arquivo de código para este artigo pode ser encontrado no Github do autor.
Preparando-se
Você precisará de uma conta de usuário válida no Bodgeit para este artigo. Este artigo usa usuá[email protected] Como vítima:
Como fazer isso…
Primeiro, você precisa analisar a solicitação que deseja forçar a vítima a fazer. Para fazer isso, você precisa de suíte de burp ou outro proxy configurado no navegador:
- Faça login no Bodgeit como qualquer usuário e clique no nome de usuário para ir para o perfil.
- Faça uma mudança de senha. Veja como é a solicitação no proxy:
Então, é um
PUBLICARsolicitação parahttp: // 192.168.56.11/bodgeit/senha.JSP,e tem apenas a senha e sua confirmação no corpo. - Tente fazer uma página HTML muito simples que replica esta solicitação. Crie um arquivo (Nomeie -o
CSRF-troca-passanha.html) com o seguinte conteúdo:
- Agora, carregue este arquivo no mesmo navegador que sua sessão conectada:
- Clique em Enviar e você será redirecionado para a página de perfil do usuário. Ele lhe dirá que a senha foi atualizada com sucesso.
- Embora isso prove o ponto, um site externo (ou uma página HTML local como neste caso) pode executar uma solicitação de alteração de senha no aplicativo. Ainda é improvável que um usuário clique no Enviar Você pode automatizá -lo e ocultar os campos de entrada para que o conteúdo malicioso esteja oculto. Agora, faça uma nova página com base na anterior; chame-o
CSRF-troca-password-script.html:Uma página completamente inofensiva
Você pode confiar nesta página.
Nada ruim vai acontecer com você ou sua conta do Bodgeit.
Desta vez, o formulário possui um parâmetro de identificação e há um script na página que enviará seu conteúdo quando a página for carregada completamente.
- Se você carregar esta página no mesmo navegador em que você iniciou uma sessão do Bodgeit, ela enviará automaticamente a solicitação e a página de perfil do usuário será exibida depois disso. Na captura de tela seguinte, o navegador DepuradorDefina um ponto de interrupção pouco antes da solicitação ser feita:
- Esta última tentativa parece melhor da perspectiva de um invasor. Você só precisa da vítima para carregar a página e a solicitação será enviada automaticamente, mas então a vítima verá o Sua senha foi mudadamensagem, e isso certamente aumentará um alerta.
- Você pode melhorar ainda mais a página de ataque, fazendo com que ela carregue a resposta em um quadro invisível dentro da mesma página. Existem muitas maneiras de fazer isso; um rápido e sujo é definir um tamanho 0 para o quadro. Seu arquivo seria assim:
Uma página completamente inofensiva
Você pode confiar nesta página.
Nada ruim vai acontecer com você ou sua conta do Bodgeit.
Observe como a propriedade alvo do formulário é o iframe definido logo abaixo dele e que esse quadro tem 0%de altura e largura.
- Carregue a nova página no navegador onde a sessão foi iniciada. Esta captura de tela mostra como a página fica ao ser inspecionada com o navegador Ferramentas de desenvolvimento: Observe que o objeto iframe é apenas uma linha preta na página e, no inspetor, você pode ver que ele contém a página de perfil do usuário do Bodgeit.
- Se você analisar as comunicações de rede realizadas pela sua página CSRF, poderá ver que ele realmente faz solicitações para alterar a senha do Bodgeit:
Como funciona…
Quando você envia uma solicitação de um navegador e já tem um cookie pertencente ao domínio alvo armazenado, o navegador anexará o cookie à solicitação antes de ser enviada. É isso que torna os cookies tão convenientes quanto os identificadores de sessão, mas essa característica de como o HTTP funciona também é o que o torna vulnerável a um ataque como o que você viu neste artigo.
Quando você carrega uma página no mesmo navegador, onde você tem uma sessão ativa em um aplicativo, o navegador anexará automaticamente o cookie de sessão a essa solicitação. Isso acontece mesmo se for uma guia ou janela diferente, e esta página faz uma solicitação para o domínio onde a sessão é iniciada.
Se o servidor não verificar se as solicitações que ele recebe realmente se originou dentro do aplicativo, ele permite que um site malicioso faça chamadas em nome de usuários ativos legítimos que visitam este site malicioso enquanto autenticados ao domínio de destino.
Em um teste de penetração de aplicativos da web, o primeiro código que você usou, aquele com os dois campos de texto e o Enviar Botão, pode ser suficiente para demonstrar a presença de uma falha de segurança. No entanto, o teste de penetração do aplicativo pode fazer parte de outro engajamento, como um exercício de engenharia social ou equipe vermelha. Nesse caso, será necessário algum esforço extra para impedir que o usuário da vítima suspeite que algo está acontecendo.
Neste artigo, você usou o JavaScript para automatizar o envio da solicitação, definindo o evento Onload na página e executando o método de envio do formulário na função de manipulador de eventos. Você também usou um iframe oculto para carregar a resposta da mudança de senha; portanto, a vítima nunca vê a mensagem de que sua senha alterou.
Se você achou este artigo interessante, pode explorar Kali Linux Web Penetration Testing Book - Segunda Edição Para descobrir as vulnerabilidades da web mais comuns e impedi -las de se tornarem uma ameaça à segurança do seu site. Kali Linux Web Penetration Testing Book - Segunda Edição fornece as habilidades necessárias para cobrir todas as etapas de um teste de penetração - desde a coleta de informações sobre o sistema e aplicação até a identificação de vulnerabilidades por meio de testes manuais.