22 Vulnerabilidades comuns de aplicativos da Web a serem conhecidas

As empresas estão constantemente “mudando para a esquerda” e aproveitando as experiências inovadoras de clientes e funcionários fornecidas por aplicativos orientados à nuvem. Ao mesmo tempo, criminosos mal-intencionados também revisam continuamente suas estratégias de ataque para se adequarem a essa mudança.

Para preservar a privacidade e a segurança dos dados, é imperativo que as empresas busquem proteção contra essas 22 vulnerabilidades comuns de aplicativos da Web .

1. Controle de acesso danificado

   Os controles de acesso são responsáveis ​​por como os usuários interagem com recursos e dados, bem como o que eles podem editar e/ou ler. Uma vulnerabilidade de controle de acesso defeituosa é possível quando o usuário é capaz de envolver os dados de uma maneira que é realmente desnecessária. Por exemplo, se o usuário for capaz apenas de ler detalhes de pagamento, mas na verdade tiver a capacidade de editá-los, tal situação exemplifica um controle de acesso quebrado. Os invasores mal-intencionados aproveitam essa vulnerabilidade para obter acesso não autorizado a software, redes e sistemas. Eles podem então explorar a situação, conceder ao ID do usuário mais acesso dentro da infraestrutura, para comprometer a disponibilidade, confidencialidade ou integridade dos dados.

2. Autenticação danificada

   Vulnerabilidades de aplicativos da Web associadas a autenticação danificada ou quebrada também se originam do acesso do usuário. Nesse caso, no entanto, invasores mal-intencionados afetam negativamente os dados que confirmam a identidade de um usuário, como por meio de tokens de sessão, chaves ou senhas de seqüestro. O invasor mal-intencionado obtém acesso não autorizado ao software, sistemas e redes porque a organização não conseguiu definir adequadamente os controles de gerenciamento de identidade e acesso adequados.

3. Injeção de retorno de carro e alimentação de linha (CRLF)

   O retorno de carro atua como um comando que denota o início de uma linha de código, normalmente indicada como /r. A alimentação de linha, por outro lado, é um comando que denota o fim de uma linha de código, normalmente indicada como /n. Como vários outros softwares, cada sistema operacional utiliza combinações variadas de retorno de carro e alimentação de linha. Quando invasores mal-intencionados estão envolvidos em injeções de CRLF, o código inserido altera a maneira como o aplicativo da Web reage aos comandos. Isso pode ser usado para divulgar dados confidenciais ou executar código.

4. Transformação de cifra insegura

   Cipher, que é um termo padrão para “algoritmo de criptografia”, é na verdade a matemática por trás de um processo de criptografia ou descriptografia. A transformação refere-se ao esboço das operações realizadas na entrada para entregar a saída esperada. Assim, uma transformação de cifra refere-se ao número de operações que convertem dados criptografados ilegíveis de volta para dados legíveis e descriptografados. Uma vulnerabilidade insegura de transformação de cifra descreve que o algoritmo de criptografia pode ser facilmente quebrado, sabotando a essência da criptografia em primeira instância.

5. Componentes com vulnerabilidades óbvias

   Cada aplicação web depende de outros componentes para funcionar. Por exemplo, se você estiver operando um aplicativo em um servidor de aplicativos ou da Web sem patches, o servidor é a parte com vulnerabilidades óbvias. A lista Common Vulnerabilities and Exposures (CVE) inclui todas as vulnerabilidades de segurança conhecidas. Como os invasores mal-intencionados têm conhecimento da lista, eles frequentemente procuram componentes sem atualizações de patches de segurança adequadas. No momento em que eles podem se infiltrar em um componente do aplicativo da Web, eles também podem obter acesso aos dados do aplicativo.

6. Política de Compartilhamento de Recursos de Origem Cruzada (CORS)

   Todos os aplicativos baseados na web usam uma URL como meio de conectar o navegador do usuário ao seu servidor. A Política de Mesma Origem é uma proteção comum. De acordo com isso, o servidor responderá apenas a uma URL com o mesmo protocolo, esquema de caminho e nome de domínio de nível superior. Isso significa que você pode acessar http://organization.com/page1 e http://organization.com/page2 porque ambos compartilham o seguinte:

   • Protocolo: HTTP
   • Domínio: Company.com
   • Esquema de caminho: /page#

   Embora seja segura, a Política de Mesma Origem é restritiva ao lidar com aplicativos baseados na Web que exigem acesso a recursos que se conectam a terceiros ou subdomínios.

   Uma política CORS concede ao navegador permissão para visualizar esses recursos inter-relacionados, estabelecendo vários cabeçalhos HTTP permitidos considerados “confiáveis”. Por exemplo, um aplicativo pode ter que extrair dados de dois bancos de dados em servidores web separados. Elaborar uma lista específica de “permitidos” torna-se um trabalho excessivo à medida que você inclui servidores adicionais. Como ambos os servidores estão “compartilhando” o aplicativo, a empresa escreve uma política CORS que permite que os navegadores se conectem a ambos. No entanto, se uma política CORS não for definida corretamente, a política poderá permitir que os servidores concedam acesso quando solicitado por um invasor mal-intencionado.

7. Gerenciamento de credenciais

   As credenciais do usuário incluem um ID de usuário e uma chave de acesso. O usuário deve fornecer ambos os itens de informação na página de login antes que o acesso a um aplicativo seja obtido. No entanto, os bancos de dados tendem a usar criptografia fraca ou manter as informações em texto simples. O mau gerenciamento de credenciais permite que os invasores roubem facilmente credenciais e as explorem para obter acesso a aplicativos da web.

8. Falsificação de solicitação entre sites (CSRF)

   Um ataque CSRF usa metodologias de engenharia social para levar um usuário a modificar informações, como senhas ou nomes de usuário, em um aplicativo. Um CSRF, ao contrário de ataques de scripts entre sites (XXS) ou malware, exige que um usuário esteja conectado ao aplicativo que usa apenas cookies de sessão para validar solicitações de usuários ou acompanhar sessões. No momento em que o usuário realiza a ação prevista, o agente malicioso usa o navegador para executar a parte restante do ataque, como movimentar fundos, sem que o usuário saiba o que aconteceu.

9. Script entre sites (XXS)

   Ao contrário de um CSRF que exige que o usuário esteja logado em um aplicativo para ser enganado e alterar certas informações, um ataque XXS exige que o invasor malicioso insira código em uma página da Web, geralmente em alguns componentes da página, como uma imagem. Depois que um usuário inicia a página da Web em seu navegador, o código incorreto começa a ser baixado e executado no navegador. Por exemplo, o código malicioso pode redirecionar o usuário de um site confiável para um ilegítimo.

10. Indexação de diretório

    Normalmente, os servidores web descrevem todos os arquivos salvos neles em um único diretório. Quando um usuário deseja localizar um arquivo específico em um aplicativo da Web, ele geralmente adiciona o nome do arquivo na solicitação. Caso o arquivo esteja indisponível, o aplicativo apresentará ao usuário uma lista de todos os arquivos indexados, para que o usuário tenha a opção de selecionar outra coisa.

    No entanto, os arquivos são indexados automaticamente por servidores web. Quando o aplicativo apresenta uma lista de todos os arquivos armazenados, um invasor mal-intencionado aproveitando-se de vulnerabilidades no índice do diretório pode obter acesso a dados que podem fornecer mais informações sobre o sistema. Por exemplo, eles podem conhecer contas de usuários pessoais ou convenções de nomenclatura. Esses dois pontos de dados podem ser explorados para realizar ataques de roubo de credenciais ou desvendar informações confidenciais.

11. Travessia do diretório

    Também conhecida como ataque de retrocesso, ponto-ponto-barra e escalada de diretório, a vulnerabilidade de passagem de diretório explora a maneira pela qual um aplicativo recebe dados do servidor da web. As Listas de Controle de Acesso (ACLs) geralmente restringem o acesso do usuário a determinados arquivos dentro de um diretório raiz. Os invasores maliciosos que usam o modo de vulnerabilidade de travessia de diretório descobrem o formato de URL que o aplicativo usa na solicitação de arquivos.

12. Encapsulamento

    Diferente de algumas das outras vulnerabilidades comuns de aplicativos da Web na lista, a vulnerabilidade de encapsulamento aproveita as falhas na maneira como um desenvolvedor codificou o aplicativo. Encapsulamento é um termo de programação que se refere ao agrupamento de dados e ações que podem ser executados nesses dados em apenas uma unidade. O encapsulamento protege os dados ocultando informações sobre como o código é executado, o que oferece uma interface de usuário melhor. Os usuários não precisam saber como o aplicativo entrega os dados a eles; tudo o que eles precisam é ter acesso a ele.

    

    Por exemplo, um desenvolvedor de aplicativo pode incluir controles de acesso, como permissões de leitura ou gravação, na capacidade de um aplicativo de recuperar dados. Se o usuário solicitar informações no aplicativo, ele entregará apenas os dados aos quais ele tem permissão de acesso.

    Mas se os desenvolvedores não estabelecerem limites claramente definidos entre os dados e as ações executadas em vários aspectos do aplicativo, o aplicativo sofrerá uma vulnerabilidade de encapsulamento. Os invasores aproveitam isso enviando uma solicitação ao aplicativo, sabendo que tal ação resultaria em uma mensagem de erro. Esta mensagem de erro fornece então informações sobre a estrutura da aplicação, auxiliando mais estratégias de ataque como um DOS – negação de serviço.

13. Referências de objetos diretos inseguros (IDOR)

    As URLs de aplicativos da Web são capazes de expor o padrão ou formato empregado para direcionar os usuários aos locais de armazenamento de back-end. Por exemplo, uma URL pode mostrar o padrão/formato de um identificador de registro em um sistema de armazenamento como um sistema de arquivos ou banco de dados.

    O IDOR sozinho pode ser uma preocupação de baixo risco. No entanto, quando um IDOR é combinado com uma verificação de controle de acesso com falha, os invasores têm a chance de atacar com sucesso.

    Outras vulnerabilidades comuns de aplicativos da Web que você deve conhecer são:

14. Divisão de resposta HTTP

    Este é um tipo de ataque de injeção de CRLF. HTTP é o processo pelo qual os navegadores enviam consultas e os servidores enviam as respostas. Nesta vulnerabilidade de aplicativo da web, os invasores maliciosos fazem uso das notações CR e LR para manipular como os navegadores e servidores se comunicam entre si, o que entrega uma solicitação, mas informa ao servidor para “dividir” a resposta em várias partes. Dividir a resposta em duas partes diferentes permite que o agente mal-intencionado obtenha controle sobre as informações que o servidor fornece em resposta à outra parte da solicitação. Quando esses dados solicitados são dados de ID do usuário ou informações confidenciais, o agente mal-intencionado executou o ataque com êxito.

15. Falha de injeção

    Uma falha de injeção permite uma infinidade de várias técnicas de ataque. Qualquer aplicativo que permita aos usuários atualizar o comando do shell, a chamada do sistema operacional ou um banco de dados pode sofrer uma falha de injeção. Os invasores maliciosos aproveitam as falhas de injeção para alterar os comandos que se transformam em ações novas e inesperadas dentro do aplicativo. Ao aproveitar essas vulnerabilidades, os agentes mal-intencionados podem criar, atualizar, ler ou até mesmo excluir dados.

16. Vulnerabilidade de resumo de mensagens inseguras

    Esta é uma vulnerabilidade criptográfica que limita a eficácia da criptografia. Um resumo da mensagem deve incluir a função hash criptográfica. Ao contrário da criptografia, as funções de hash não exigem que o remetente e os usuários usem chaves.

    Os invasores maliciosos aproveitam as vulnerabilidades de resumo inseguro para perpetuar o “ataque de colisões de hash”. O objetivo do ataque é descobrir se o envio de uma entrada leva à geração de um hash duplicado. Se a ação maliciosa gerar forçosamente um hash compartilhado, eles poderão usar esse hash para apresentar um arquivo maligno para download. Isso, por sua vez, deixa o usuário final com a suposição de que o arquivo é legítimo.

17. Proteção insuficiente da camada de transporte

    A segurança da camada de transporte (TLS) refere-se ao processo pelo qual os aplicativos de computador podem se “comunicar” com segurança uns com os outros na Internet. Vários aplicativos utilizam apenas o TLS durante o processo de autenticação, o que deixa os dados e as informações da sessão de ID vulneráveis ​​quando uma pessoa usa o aplicativo.

    Os invasores podem aproveitar essa vulnerabilidade para desviar dados à medida que se movem pela Internet entre o dispositivo do usuário e o servidor de aplicativos.

18. Execução remota de código (RCE)

    As vulnerabilidades de execução remota de código são erros de codificação em aplicativos da Web que permitem que invasores mal-intencionados insiram código independentemente de sua localização geográfica. Os RCEs se enquadram em uma categoria mais ampla de vulnerabilidades de injeção de aplicativos da Web, nas quais os invasores inserem seu próprio código em um aplicativo que não confirma as entradas do usuário, fazendo com que o servidor o veja como um código de aplicativo genuíno. Normalmente, os invasores mal-intencionados aproveitam as vulnerabilidades comumente conhecidas não corrigidas e inserem seu código no aplicativo.

19. Inclusão de arquivo remoto (RFI)

    Para vincular diretórios comuns a um aplicativo, os desenvolvedores adicionam instruções “incluir” em seu código. Por exemplo, um aplicativo pode ter que extrair dados de um banco de dados. Em vez de codificá-lo manualmente para obter cada arquivo, a instrução “include” ajuda a vincular todo o diretório de origem para que tudo armazenado nele possa ser usado.

    Quando um aplicativo da Web sofre uma vulnerabilidade de RFI, os invasores podem manipular o aplicativo para carregar código malicioso ou malware no banco de dados, servidor ou site.

20. Configuração incorreta de segurança

    A probabilidade de uma configuração incorreta de segurança é, de fato, uma das vulnerabilidades de aplicativos da Web mais comuns atualmente. Essa vulnerabilidade geralmente ocorre devido à falha de uma organização em modificar as configurações de segurança padrão. As configurações incorretas de segurança comuns são:

    • Fazendo uso de senhas ou contas padrão
    • Software sem patch
    • Sem criptografia
    • Políticas de firewall inadequadas
    • Negligenciar recursos, recursos e outros componentes não utilizados

21. injeção SQL

    SQL, que significa Structured Query Language, é uma linguagem de programação usada para bancos de dados. Ele permite a recuperação e manipulação de dados para bancos de dados relacionais. Uma vulnerabilidade de injeção de SQL está em um grupo maior de entradas de usuário não verificadas. Quando agentes mal-intencionados enviam deliberadamente solicitações falsas, o aplicativo da Web responde com uma mensagem de erro que fornece informações sobre a estrutura e a proteção do banco de dados.

22. Ativação automática de biblioteca não validada

    Para economizar tempo na codificação, os desenvolvedores tendem a usar bibliotecas de terceiros. Na maioria dos casos, isso permite que eles façam uso de código pré-testado que acelera o processo de desenvolvimento de aplicativos. O uso de código aberto e disponível publicamente, no entanto, aumenta os riscos de segurança, incluindo:

    • A ausência de propriedade documentada aumenta o risco de código maligno adicionado
    • Projetos negligenciados que não são mais atualizados

    Essa vulnerabilidade específica é cada vez mais prevalente, considerando que vários aplicativos envolvem dependências de bibliotecas de terceiros.

Esperamos que o conteúdo desta postagem do blog tenha sido realmente útil e esclarecedor para você. Certificar-se de encontrar uma solução para qualquer vulnerabilidade de aplicativo da Web que se aplique ao seu caso será um divisor de águas nas experiências de seus funcionários e clientes.