Vulnerabilidades do lado do servidor

Além dos ataques de phishing e relacionados aos administradores, os hackers frequentemente tentam determinar o tipo de servidor da web (por exemplo, Tomcat), o software do servidor da web (por exemplo, node.js) e o sistema operacional do servidor. Isso pode ser alcançado examinando fatores como inteligência geral (por exemplo, comentários em mídias sociais e sites de tecnologia), nomes de cookies de sessão, código-fonte da página da web e muito mais.

Depois que a tecnologia de back-end é determinada, os hackers podem usar uma variedade de métodos para explorar vulnerabilidades não corrigidas. A configuração insegura do servidor, como configurações padrão inseguras do servidor, acesso irrestrito às pastas do servidor e portas abertas, foram todos explorados para invadir sites.

Configurações de servidor padrão inseguras são frequentemente testadas por hackers, como deixar credenciais padrão ativas. Ferramentas de verificação como o Grayhat Warfare são frequentemente usadas por hackers para encontrar conteúdo de bucket do Amazon S3 configurado de maneira insegura.

As portas abertas são fáceis de serem detectadas pelos hackers usando as ferramentas de verificação de portas e, uma vez detectadas, uma variedade de vulnerabilidades pode ser explorada.

Da mesma forma, as ferramentas para verificar arquivos podem encontrar ferramentas administrativas que podem ser acessadas com senhas fracas - ou nenhuma senha. Restrições inadequadas ao upload de arquivos para pastas do servidor também são um presente para os hackers, permitindo que eles carreguem e executem malware.

Vulnerabilidades do lado do cliente

No lado do cliente, as vulnerabilidades comuns incluem:

• Injeção de SQL: inserindo comandos SQL em solicitações, resultando em liberação não autorizada de dados ou modificação de entradas do banco de dados
• XSS: Injeção de código malicioso
• CSRF: assumindo a sessão de um usuário

O projeto dos dez principais aplicativos da Web da OWASP descobriu que os ataques por injeção eram o tipo de ameaça número um.

Os hackers têm à sua disposição ferramentas prontamente disponíveis para testar automaticamente os sites em busca dessas vulnerabilidades, da mesma maneira que o pentesting legítimo é realizado. Hoje em dia, porém, seria muito surpreendente e negligente para um site ter proteção insuficiente contra injeção de SQL e ataques de CSRF. O XSS, no entanto, continua a representar ameaças à medida que novas vulnerabilidades aparecem, especialmente quando as páginas da Web (incluindo aquelas incorporadas em aplicativos móveis) se tornam mais complexas e ricas em recursos. Depois que uma vulnerabilidade é encontrada, ela pode ser explorada rapidamente em sites que não a corrigiram.

Estruturas e ameaças cibernéticas

A prática contemporânea de desenvolvimento da Web, com sua forte dependência de bibliotecas, plugins e estruturas de código aberto, é uma fonte rica de vulnerabilidades que os hackers podem utilizar. Os hackers se esforçarão muito mais para examinar as bibliotecas em busca de vulnerabilidades do que o desenvolvedor típico da Web jamais fará, e essas falhas geralmente surgem apenas depois de serem usadas para hacks bem-sucedidos.

O aumento do JavaScript no servidor e a crescente complexidade de bibliotecas e estruturas significa que esses tipos de explorações estão aumentando. Esse é geralmente o caso do código-fonte aberto que teve seu desenvolvimento abandonado; isso significa que não há atualizações disponíveis e as vulnerabilidades são expostas para sites que continuam a usá-las.

APIs e ameaças cibernéticas

Os sites que usam APIs para se comunicar com sistemas de back-end podem ter as APIs direcionadas por hackers. Nesse caso, os hackers procurarão uma segurança de API fraca, como credenciais ou códigos de acesso ou tokens acessíveis a partir de strings de consulta, variáveis ​​e outras fontes.

Os hackers também tentarão obter informações sobre a arquitetura interna de um sistema baseado em API chamando deliberadamente as APIs com parâmetros inválidos e verificando se as mensagens de erro resultantes vazam informações sobre o sistema. Essas informações podem ser praticamente qualquer coisa, como tipo e configuração do banco de dados. Todos esses trechos de informações podem ser úteis posteriormente, à medida que surgem novas vulnerabilidades.

Ciberataques diretos e ataques de token

Além de tentativas gerais de hackers nos sistemas do cliente e do servidor, são comuns ataques diretos às contas de usuário e administrador. Atualmente, os hackers estão focados no uso de credenciais (senha), mais do que ataques de força bruta na autenticação de nome de usuário + senha, bem como tentativas de manipular ou reutilizar tokens de acesso.

Com 61 bilhões de tentativas de preenchimento de credenciais nos 18 meses a junho de 2019, esse método de ataque está se mostrando popular. O preenchimento de credenciais envolve tentativas automatizadas de login usando nomes de usuário (ou endereços de email) e senhas coletadas de violações no servidor para tentar obter acesso a contas de usuário ou administrador.

Geralmente emitidos por meio dos protocolos OAuth2 ou OpenID Connect (OIDC), os tokens de acesso são necessários no ambiente da web atual, autorizando solicitações de recursos, como dados da conta do usuário, APIs e outros recursos. Essa onipresença oferece outro alvo principal para hackers - como vimos, por exemplo, na violação do Facebook de 2018.

Esses tokens são mais comumente na forma de tokens da web JSON (JWT). Os hackers procurarão vulnerabilidades como o XSS, que permitem que os tokens sejam roubados de cookies, armazenamento local e variáveis JavaScript. Como a maioria desses tokens é do tipo portador, é trivial que eles sejam usados pelo hacker uma vez roubados, pelo menos até que expirem.

Da mesma forma, os hackers também tentarão explorar o manuseio inseguro de assinaturas de token, para que possam alterar os direitos de acesso ao token, os prazos de validade e assim por diante, sem invalidar a assinatura. Um método simples que os hackers tentam é alterar o valor do algoritmo de assinatura armazenado no cabeçalho JWT para "none". Em uma implementação insegura, o código de verificação da assinatura ignorará a assinatura do token, o que significa que as alterações no conteúdo do token serão perdidas.

Um pensamento final

As modernas táticas de desenvolvimento e phishing da Web abriram tanto a superfície de ataque que os sites e aplicativos da Web são altamente vulneráveis em vários pontos de entrada.

Mas um pensamento final: como esquilos, os hackers não pensam como você e não têm limites no que tentarão. Se as tentativas deles travarem um site ou destruírem um banco de dados, isso não será um problema para eles. Quando você acha que testou seu site em busca de vulnerabilidades, ainda precisa ter cuidado.

Fonte infosecinstitute.com