Injeção
As falhas de injeção, como SQL, OS, XXE e LDAP, ocorrem quando dados não confiáveis são enviados para um intérprete como parte de um comando ou consulta. Por exemplo, na tela de administração do seu sistema, você tem que digitar um usuário e senha para acessar, por trás desse formulário de acesso, o seu sistema normalmente realiza uma consulta ao banco de dados, para verificar se o usuário existe e a senha digitada está correta, o comando para a execução é basicamente o seguinte:
SELECT id FROM USUARIOS WHERE usuário = ‘textoDigitado’ && senha = ‘textoDigitado2’Esse código seleciona o número de identificação do usuário, que tem o mesmo nome e senha digitado no formulário, retornando o resultado ele libera o acesso ao sistema, o grande problema é que utilizando injeção, poderíamos no textoDigitado informar o seguinte:
‘ OR 1=1Que ao ser processado pelo sistema, iria influenciar diretamente no contexto, agora o sistema verifica se o usuário é igual a vazio ou 1 é igual a 1, caso verdadeiro, ele pega o primeiro usuário do sistema e libera o acesso.
Gerenciamento de sessão e quebras de autenticação
Um dos pontos principais de uma aplicação é como ela lida com a sessão e a autenticação do usuário, explicando um pouco o funcionamento, o seu formulário de acesso verifica se os dados estão corretos e cria uma sessão, informando que o seu acesso foi autorizado, se essa função for implementada de maneira incorreta, pode permitir que invasores comprometam senhas, chaves ou tokens de sessão, e até mesmo explorem falhas de implementação para assumir identidades de outros usuários no sistema.
Por exemplo, se no seu formulário de acesso, é adicionado o código do usuário através do método POST (método padrão de envio de formulário), pode ser utilizado o Tamper Data ou outro aplicativo similar para realizar a manipulação da informação que será inserida na seção, nesse ponto ao invés de inserir o código do usuário “João” na sessão, podemos alterar e passar o código do usuário “José”.
Cross-Site Scripting (XSS)
Uma falha XSS ocorre sempre que um aplicativo inclui dados não confiáveis em uma nova página da web sem validar ou escapar adequadamente. O XSS permite que os invasores executem scripts no navegador da vítima, por sua vez, esses scripts podem redirecionar a vítima para um site malicioso ou até mesmo sequestrar sessões de usuários.
Por exemplo, se você tem uma conta no banco Digital30 que utiliza o método GET para realizar transferências sem proteção contra CSRF (8), e você acessa o blog do “João”, e o blog tem uma falha de XSS que permitiu um invasor inserir um código malicioso na área de comentários, não havia nenhum filtro de código no comentário, agora todos que acessam a página de comentários têm um script executado no computador. Esse script em específico acessa a página digital30.com/transfer.php?value=500&to=0200, como você estava autenticado no banco, ao acessar o blog, a falha fez com que executasse uma ação dentro do banco, que transferiu R$ 500,00 para a conta 0200.
Quebras no controle de acesso
Uma aplicação normalmente atua com sistema de permissões, que define o que cada usuário pode fazer no sistema, outro ponto é que as páginas do seu sistema precisam que o usuário esteja autenticado para serem acessadas, no entanto, essa vulnerabilidade ocorre quando essa verificação ou não foi feita da maneira correta, ou simplesmente não foi feita.
Por exemplo, dentro de um sistema, se o desenvolvedor se esquecer de verificar na página de cadastro de usuários se o usuário atual está autenticado, é possível que um invasor utilize essa falha para acessar a página diretamente através de scripts de força bruta, que testa várias possibilidades, como por exemplo seusite.com.br/a, seusite.com.br/aa, até testar todas as possibilidades, caso durante esse teste o invasor encontre a página seusite.com.br/usuarios/cadastro e a mesma não tiver uma verificação de autenticação, mesmo sem ter um usuário e senha do sistema é possível cadastrar um usuário e obter acesso total.
Configuração incorreta de segurança
A segurança da informação vai muito além de um script bem configurado, precisamos ter um conceito de segurança amplamente aplicado, com uma configuração de segurança bem definida e implantada para o servidor web, servidor de banco de dados, plataforma e etc. Como citamos no início do artigo, precisamos manter as aplicações do nosso servidor atualizadas, para que vulnerabilidades de terceiros, já descobertas e corrigidas não possam prejudicar a segurança do nosso servidor, a padronização e normatização dos modelos de segurança do negócio, alinhados a políticas rigorosas de segurança são fundamentais para a continuidade do negócio.
Por exemplo, se você tem um código robusto, amplamente testado, mas hospeda-o em um serviço de hospedagem de baixa qualidade, aonde sua aplicação não tem nenhum tipo de proteção contra ataques de negação de serviço, um atacante mal intencionado pode colocar o seu sistema fora do ar por tempo indeterminado, através de ataques, trazendo um prejuízo enorme para o seu negócio.
Exposição de dados sensíveis
Muitas aplicações web não protegem de forma adequada os dados confidenciais, como dados financeiros. Os atacantes podem roubar ou modificar esses dados deficientemente protegidos, para conduzir fraudes em cartões de créditos, roubar identidades ou outros crimes. Dados sensíveis devem possuir uma proteção extra, como uma criptografia.
Por exemplo, se você está dentro de um restaurante utilizando um sistema de pagamentos que não possui criptografia (HTTPS), e digitou as informações do seu cartão de crédito para realizar uma compra, um atacante mal intencionado, utilizando aplicações de análise de tráfego pode capturar as informações, outro ponto bastante comum é que um invasor obtendo acesso ao mesmo sistema, pode obter todas as informações dos cartões de créditos já utilizados no sistema, caso não possua um tipo de criptografia.
Proteção de ataque insuficiente
A maioria dos aplicativos não possui capacidade básica para detectar, prevenir e responder a ataques manuais e automatizados. A proteção de ataques vai muito além da validação de entrada básica e envolve a detecção, resposta e até bloqueio de tentativa de exploração.
Cross-Site Request Forgery (CSRF)
Um ataque CSRF força o navegador da vítima autenticada a enviar uma solicitação forjada para uma aplicação vulnerável, dessa forma a aplicação vulnerável pensa ser solicitações legítimas da vítima.
Por exemplo, o invasor pode colocar dentro do site isca, um script que simula o acesso ao link meusite.com.br/conta/alterar/senha?novasenha=123456, caso o usuário esteja autenticado no site alvo(meusite.com.br) a sua senha será alterada para 123456, apenas por acessar o site do invasor. Ou seja, ao acessar outro site é possível que ele execute ações no site vulnerável sem o teu consentimento, também é comum a utilização dessa falha enviando o link encurtado (goo.gl, bit.ly), que executa a ação para a vítima, sendo assim, ao clicar a ação é executada e algumas vezes a vítima nem percebe o golpe.
Utilizar componentes com vulnerabilidades conhecidas
Aplicativos, APIs, bibliotecas, frameworks e outros módulos de softwares possuem vulnerabilidades, como eles são executados com os mesmos privilégios que a aplicação, se um componente vulnerável for explorado, toda a aplicação pode ser colocada em risco. Por isso é fundamental que seja documentado todos os módulos de terceiros utilizados no projeto e que seja acompanhado a atualização desses projetos, para que a aplicação tenha sempre a versão mais atual dos módulos de terceiros, para aumentar ao máximo o nível da segurança do mesmo.
Por exemplo, uma aplicação que utiliza o plug-in ComentsEasy, pode estar vulnerável a injeção, caso o ComentsEasy não trate esse item, ou seja, é possível que exista vulnerabilidades, por isso é fundamental verificar a real necessidade de utilizar módulos de terceiros, e quando for utilizar, acompanhar as atualizações para que não utilize versões desatualizadas e com falhas conhecidas.
APIs desprotegidas
Aplicações modernas geralmente utilizam APIs, por exemplo, aplicativos móveis se comunicam com APIs (SOAP, XML, Rest, JSON e afins), para realizar consultas e demais transações com o banco de dados, esse tipo de prática é recomendado, pois adiciona um nível extra de proteção na comunicação. O grande problema é quando essas APIs são desprotegidas ou contém várias vulnerabilidades.
Por exemplo, uma API de consulta ao banco de dados de um sistema financeiro, caso não esteja protegida, pode ser acessada diretamente e liberar a consulta de dados sigilosos a qualquer pessoa, mesmo que não esteja utilizando a aplicação.
Artigo retirado do site: inovedados.com.br
Nenhum comentário:
Postar um comentário