Cross-Site Scripting (XSS): Entendendo o conceito e seus tipos

Transcrição

1 Cross-Site Scripting (XSS): Entendendo o conceito e seus tipos Talvez a vulnerabilidade de segurança de aplicações web mais comum e mais debatido é Cross-Site Scripting (XSS). Quando tais vulnerabilidades estão presentes, os atacantes podem injetar scripts maliciosos em um site inofensivo de forma que seja executado no navegador do usuário. Ataques XSS são geralmente divididos em duas categorias: persistente (ou armazenado) e não-persistente (refletido). Ataques XSS persistente são armazenados no servidor e executado sempre que um usuário visita a página onde o script está armazenado. Fóruns de usuários, comentários e outros locais onde os usuários podem salvar entrada que serão exibidas para outros usuários são locais ideais para esses tipos de ataques. Ataques XSS não-persistentes não são armazenados no servidor, mas são criados através do envio de solicitações com o próprio ataque XSS. Os ataques ocorrem quando o input do usuário é incluído na resposta do servidor, por exemplo, em mensagens de erro ou resultados de pesquisa. Ataques XSS não-persistentes dependem de um usuário enviar um pedido com o ataque XSS incluídos na solicitação, portanto, provavelmente haverá algum tipo de engenharia social para o ataque também. Na verdade, ter XSS pode realmente aumentar o sucesso de um ataque de engenharia social, porque você pode criar uma URL que faz parte de um site de verdade, o qual o usuário conhece e confia em usar, e o XSS será usado para, por exemplo, redirecionar o usuário para uma página maliciosa. Como os outros ataques discutidos nesta postagem, ataques XSS devem contar com uma falta de atenção no saneamento do input do usuário, o que nos permite criar e executar um script malicioso.

2 Verificando pela vulnerabilidade XSS nãopersistente (refletida) Devemos verificar qualquer campo de entrada de dados feita pelo usuário que tenha vulnerabilidade XSS. Vamos utilizar o site de teste ( Nós vamos descobrir que nossa aplicação tem uma vulnerabilidade de XSS refletido na funcionalidade de pesquisa. Tente pesquisar na caixa de busca usando a palavra XSS, como mostrado abaixo. XSS Campo de busca

3 XSS Resultado da busca Como mostrado na imagem, a página de resultados de pesquisa exibe a entrada do usuário original como parte dos resultados. Se a entrada do usuário não está devidamente higienizada pela aplicação, isto pode ser o lugar onde nós podemos usar XSS. Testando se é vulnerável a XSS O primeiro teste típico XSS para tentar executar é uma caixa de alerta JavaScript. O código a seguir tentará colocar um alerta JavaScript com um texto. Se a entrada do usuário não for devidamente filtrada, o script será executado como parte da página de resultados de busca. <script>alert('site vulnerável a XSS!');</script> Em alguns casos, o navegador do usuário bloqueia automaticamente ataques XSS óbvios como este. O resultado esperado será o script de alerta pop-up executado.

4 XSS Alerta XSS Confirmada a vulnerabilidade de XSS refletido, poderíamos tentar aproveitá-la para atacar usuários. Ataques comuns incluem roubo de cookies de sessão para enviar para um site controlado pelo invasor ou embutindo um frame (uma maneira de dividir uma página HTML em diferentes segmentos) para solicitar ao usuário suas credenciais de login. Um usuário pode pensar que o quadro é parte da página original e inserir suas credenciais, que são então enviados para o atacante. Aproveitando XSS com o Browser Exploitation Framework (BeEF) Vulnerabilidades XSS tendem a ser negligenciados. Quanto dano uma caixa de alerta que diz XSS pode fazer? Uma boa ferramenta para alavancar questões XSS e descobrindo o seu potencial ataque verdadeiro é o Browser Exploitation Framework (BeEF). Usando BeEF, nós podemos fazer um gancho no navegador, enganando o usuário a navegar para o nosso servidor do BeEF, ou melhor ainda usar gancho JavaScript do BeEF como

5 um payload na presença de uma vulnerabilidade de XSS como o discutido anteriormente. Agora inicie o servidor do BeEF como root: BeEF Iniciando como root Agora no Kali, navegue até para acessar a interface do BeEF web. Você deve ser apresentado com uma página de login, como o mostrado abaixo. BeEF Tela de login

6 As credenciais padrão para o BeEF são beef:beef. Depois de inseri-los na janela de autenticação, é mostrada a interface web. BeEF Tela de login Neste momento, não tem nenhum navegador que esteja no gancho do BeEF, por isso temos de enganar alguém para carregar e executar o script malicioso do BeEF chamado hook.js. Desta vez, em vez de usar uma caixa de diálogo de alerta, vamos influencia-lo a carregar o hook.js do BeEF no navegador da vítima. O BeEF tem uma página de teste que pode ser acessada através do Kali (

7 BeEF Demo BeEF Detalhes do alvo Desta vez não haverá nenhuma caixa de alerta ou outra indicação para o usuário o que sugere que nada está errado, mas se você voltar ao BeEF, você deve ver o endereço IP na lista on-line Browsers no lado esquerdo da tela,

8 como mostrado na imagem. No painel Details, com o endereço IP selecionado, você pode ver detalhes sobre o navegador que foi fisgado, bem como do sistema dele, tais como versões e software instalado. Na parte superior do painel tem guias adicionais, como logs e comandos. Clique Commands para ver módulos do BeEF adicionais que possam ser executadas no navegador fisgado. Por exemplo, vá até a opção Browser > Hooked Domain > Create Alert Dialog. No lado direito da tela, você tem a opção de mudar o texto do alerta. Quando finalizar, clique em Execute. BeEF Create Alert Dialog Volte a aba do navegador que está sendo o alvo e veja o alerta sendo exibido.

9 BeEF Resultado do Create Alert Dialog Nesta postagem vimos apenas um exemplo simples de influenciar um navegador a ser fisgado com BeEF. Há muito mais que podemos fazer. Por exemplo, podemos usar o navegador da vítima como um pivô para começar a reunir informações sobre a rede local com varreduras de ping ou mesmo varreduras de portas. Você pode até mesmo integrar o BeEF com Metasploit. Em seus pentests, você pode usar BeEF como parte de ataques de engenharia social. Se você pode encontrar uma vulnerabilidade XSS no servidor web do seu cliente, você pode melhorar os resultados de sua campanha, orientando os usuários não para um site de propriedade do atacante, mas sim para o site da empresa que eles confiam. Fonte: Penetration Testing A hands-on introduction to Hacking