A descrição das vulnerabilidades é uma coisa, mas tentar encontrar uma vulnerabilidade e trabalhar com ela é uma questão completamente diferente. É para esses fins que aplicativos especiais são criados e desenvolvidos nos quais as vulnerabilidades são deliberadamente deixadas para trás. Se você digitar no mecanismo de pesquisa a consulta "Aplicativo propositadamente vulnerável", não encontrará uma dúzia de links.
Nesta série, começaremos a analisar vulnerabilidades do Top 10 da OWASP, e usarei um aplicativo vulnerável intencionalmente como um campo de teste. No meu caso, será o OWASP Mutillidae II. Essa não é a melhor opção, mas as vulnerabilidades estão estruturadas exatamente conforme necessário para fins educacionais.
Dê sua mãoPortanto, a primeira vulnerabilidade são as injeções. OWASP Mutillidae II apresenta várias opções, e começaremos com o mais simples “SQLi extract Data”> “User Info (SQL)”.
Diante de nós está a janela de autenticação usual - com a qual você interage diariamente:
Não temos nome de usuário ou senha - nada. Bem, então, vamos registrar neste site. Vou criar um usuário com o nome abaixo de zero273 e a senha 123:
Ótimo! Criamos uma conta, a inscrição solene “1 linha inserida” indica que uma linha foi adicionada, aparentemente à tabela, porque um grande número de contas é mais fácil de armazenar no DBMS.
Agora faça login com nossa nova conta no sistema. Bem sucedido, ótimo.
Quando trabalhamos com uma página da web, devemos sempre lembrar que nossa interação não se limita ao conteúdo da página. Há também uma barra de endereço, por exemplo. Em que podemos notar muitas coisas interessantes:
http://127.0.0.1/mutillidae/index.php?page=user-info.php&username=belowzero273&password=123&user-info-php-submit-button=View+Account+Details
Por exemplo, vemos que a senha é transmitida em texto não criptografado. Isso é ruim, pois o tráfego pode ser interceptado. Mas talvez não seja um desastre - o tráfego será envolto em TLS.
Vamos tentar substituir a senha na linha, por exemplo, esta parte:
username=belowzero273&password=123
em
username=belowzero273&password=12345
A senha, é claro, agora está incorreta e recebemos o erro correspondente: e isso é ruim. É ruim, porque com a ajuda do THC-Hydra, sobre o qual falei
aqui , podemos pegar essa senha substituindo-a nesta linha sem qualquer forma. Mas isso nem sempre pode levar a um resultado positivo em um período de tempo aceitável.
Não temos muito tempo, então vamos tentar outra coisa. Adicione um sinal de apóstrofo à nossa senha incorreta:
username=belowzero273&password=123
em
username=belowzero273&password=12345'
Agora temos um erro completo:
Não há nada de errado com erros. De que outra forma diagnosticar um mau funcionamento se não recebermos comentários do aplicativo? Mas esses erros não devem ser visíveis para usuários e atacantes.
Agora vemos que, de fato, quando clicamos no botão "Enviar" em segundo plano, a seguinte solicitação é executada:
SELECT * FROM accounts WHERE username='belowzero273' AND password='12345'
Apóstrofos se destacam variáveis de string. Nosso aplicativo da web não filtra os dados inseridos pelo usuário e, com nosso apóstrofo adicional, violamos a solicitação. Agora que sabemos como é essa consulta em segundo plano, precisamos descobrir como alterá-la para obter as informações necessárias no banco de dados.
Observe que a solicitação contém a função e, ou seja, ambas as variáveis devem estar corretas, porque essa é uma combinação de login e senha. É lógico.
Vamos dar uma olhada rápida nesta consulta:
SELECT * FROM accounts WHERE (username='belowzero273' AND password='12345') OR 1='1
Adicionamos uma condição sempre satisfeita: 1 = 1. E a solicitação será executada em dois casos: adivinhámos a combinação de nome de usuário e senha ou 1 = 1. Ou seja, sempre será executado.
Acontece que o seguinte pode ser especificado como uma senha:
' or 1='1
O apóstrofo no final da linha não é mais necessário, a lógica do aplicativo da web o colocará para nós. Boom! E obtivemos uma seleção do banco de dados com todas as contas:
Legal, agora temos logins e senhas de todos os que estão registrados nesta aplicação. E ainda pior, as senhas aqui estão claras.
O que há de errado nisso? E o fato de a maioria das pessoas usar os mesmos nomes de usuário e senhas para todos os sites. E, ao se registrar dessa maneira em um site vulnerável, eles podem perder o acesso a todos os sites.
Você também pode experimentar essa vulnerabilidade, por exemplo, procure uma senha de administrador. Para fazer isso, substitua o login:
admin' or 1='1
Ou seja, estamos procurando uma entrada no banco de dados em que o nome de usuário seja admin e a senha seja qualquer.
!
As senhas nem sempre são armazenadas em texto não criptografado, mas isso não significa que a autenticação seja feita com segurança. Vejamos o segundo exemplo em OWASP Mutillidae II "SQLi Bypass Authentication"> "Login".
A autenticação pode ser ignorada gerando uma solicitação correspondente. Mais recentemente, criamos uma conta abaixo de zero273 e agora vamos especificar como login:
' or ('a' = 'a' and username='belowzero273')
Aqui, verificamos a condição obviamente correta - a = a e o login - abaixo de zero273, e também cortamos a parte da solicitação com a ajuda de "-".
Pressione Enter e efetue login no sistema, apesar de não termos especificado sua senha em nenhum lugar.
Tão fácilÀs vezes, os clientes perguntam: é realmente tão fácil ignorar a autenticação em nosso site? Normalmente, respondo à pergunta com a pergunta: "Você tem certeza de que isso ainda não aconteceu?" As injeções não estão acidentalmente no topo da classificação da OWASP, pois essas vulnerabilidades, em regra, têm conseqüências desastrosas se implementadas.
Na prática, é claro, tudo é um pouco mais complicado do que nesses exemplos. Mas é nesses exemplos básicos que a compreensão de problemas mais profundos começa a tomar forma. Continuaremos na próxima vez.
Leia o blog do autor
neste link .