Phenquestions
Neste artigo, você obterá as informações necessárias do aplicativo para saber o que o site invasor deve fazer para enviar solicitações válidas ao servidor vulnerável. Em seguida, você criará uma página que simula as solicitações legítimas e induz o usuário a visitar essa página enquanto está autenticado. Você também fará algumas iterações na prova de conceito básica para torná-la mais parecida com um ataque do mundo real, onde a vítima não percebe. Observe que o arquivo de código deste 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 [email protegido] como a 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 do Burp Suite 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 alteração de senha. Veja a aparência da solicitação no proxy:
Então, é um
PUBLICARpedido parahttp: // 192.168.56.11 / bodgeit / senha.jsp,e possui apenas a senha e sua confirmação no corpo. - Tente fazer uma página HTML muito simples que replique esta solicitação. Crie um arquivo (nomeie-o
csrf-mudar-senha.html) com os seguintes conteúdos:
- Agora, carregue este arquivo no mesmo navegador da sua sessão de login:
- Clique em enviar e você será redirecionado para a página de perfil do usuário. Ele dirá que a senha foi atualizada com sucesso.
- Embora isso comprove 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 automatizar e ocultar os campos de entrada para que o conteúdo malicioso seja escondido. Agora, faça uma nova página com base na anterior; chame-o
com script csrf-change-password.html:Uma página completamente inofensiva
Você pode confiar nesta página.
Nada de ruim vai acontecer com você ou sua conta BodgeIt.
Desta vez, o formulário possui um parâmetro de ID e há um script na página que enviará seu conteúdo quando a página estiver totalmente carregada.
- Se você carregar esta página no mesmo navegador em que iniciou uma sessão BodgeIt, ele enviará automaticamente a solicitação e a página de perfil do usuário será exibida em seguida. Na captura de tela a seguir, o navegador Depuradordefina um ponto de interrupção pouco antes de a solicitação ser feita:
- Esta última tentativa parece melhor do ponto de vista de um invasor. Você só precisa que a vítima carregue 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 levantará um alerta.
- Você pode melhorar ainda mais a página de ataque, fazendo-a carregar 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 ficaria assim:
Uma página completamente inofensiva
Você pode confiar nesta página.
Nada de ruim vai acontecer com você ou sua conta BodgeIt.
Observe como a propriedade alvo do formulário é o iframe definido logo abaixo dele e que tal moldura tem 0% de altura e largura.
- Carregue a nova página no navegador onde a sessão foi iniciada. Esta captura de tela mostra a aparência da página ao ser inspecionada com o navegador Ferramentas de desenvolvimento:
Observe que o objeto iframe é apenas uma linha preta na página e, no Inspector, você pode ver que ele contém a página de perfil do usuário BodgeIt. - Se você analisar as comunicações de rede realizadas por sua página CSRF, poderá ver que ela 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 de destino armazenado, o navegador anexará o cookie à solicitação antes que ele seja enviado. Isso é o que torna os cookies tão convenientes como 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 irá 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 ao domínio onde a sessão é iniciada.
Se o servidor não verificar se as solicitações que recebe são realmente originadas do aplicativo, ele permite que um site malicioso faça chamadas em nome de usuários legítimos e ativos que visitam este site malicioso enquanto autenticados no domínio de destino.
Em um teste de penetração de aplicativo 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 ser parte de outro trabalho, como um exercício de engenharia social ou equipe vermelha. Neste caso, algum esforço extra será necessário para evitar que o usuário vítima suspeite que algo está acontecendo.
Neste artigo, você usou 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 alteração da senha, portanto, a vítima nunca vê a mensagem de que sua senha foi alterada.
Se você achou este artigo interessante, você pode explorar Livro de receitas de teste de penetração da Web do Kali Linux - segunda edição para descobrir as vulnerabilidades da web mais comuns e evitar que se tornem uma ameaça à segurança do seu site. Livro de receitas de teste de penetração da Web do Kali Linux - segunda edição oferece as habilidades de que você precisa para cobrir todas as fases de um teste de penetração - desde a coleta de informações sobre o sistema e o aplicativo até a identificação de vulnerabilidades por meio de testes manuais.
