E ae galera, resolvi trazer pra vocês as principais falhas em aplicações web.
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=1
Que 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
