41 vulnerabilidades comuns de aplicativos web explicadas

Views: 1202

As organizações continuam a “mudar para a esquerda”, abraçando as novas experiências de funcionários e clientes fornecidas por aplicativos baseados em nuvem. Simultaneamente, atores mal-intencionados continuam a revisar suas metodologias de ataque para lidar com essa mudança. Para manter a segurança e a privacidade dos dados, as organizações precisam se proteger contra essas 41 vulnerabilidades comuns de aplicativos web.

1. Controle de acesso quebrado

Os controles de acesso definem como os usuários interagem com dados e recursos, incluindo o que podem ler ou editar. Existe uma vulnerabilidade de controle de acesso quebrada quando um usuário tem a capacidade de interagir com os dados de uma maneira que eles não precisam. Por exemplo, se um usuário só deve ser capaz de ler detalhes de pagamento, mas pode realmente editá-los, este é um controle de acesso quebrado. Atores mal-intencionados usam essa vulnerabilidade para obter acesso não autorizado a sistemas, redes e software. Eles podem, então, aumentar os privilégios, dar ao ID do usuário acesso adicional dentro do ecossistema, para impactar negativamente a confidencialidade, integridade ou disponibilidade dos dados.

2. Autenticação quebrada

As vulnerabilidades de autenticação quebradas também se concentram no acesso do usuário. No entanto, neste caso, atores mal-intencionados comprometem as informações que confirmam a identidade de um usuário, como roubar senhas, chaves ou tokens de sessão. O ator mal-intencionado ganha acesso não autorizado aos sistemas, redes e software porque a empresa não definiu adequadamente os controles adequados de gerenciamento de identidade e acesso.

3. Injeção de retorno do transporte e alimentação da linha (CRLF)

O retorno do transporte é um comando que indica o início de uma linha de código, normalmente denotada como \r. O feed de linha é um comando que indica o fim de uma linha de código, normalmente denotada como \n. Como muitos outros softwares, cada sistema operacional usa uma combinação diferente de retorno de transporte e alimentação de linha. Quando atores mal-intencionados se envolvem em injeções de CRLF, o código inserido muda a maneira como o aplicativo web responde aos comandos. Isso pode ser usado para divulgar informações confidenciais ou executar código.

4. Transformação de cifra insegura

Cipher, um termo padrão para “algoritmo de criptografia”, é a matemática por trás de um processo de criptografia/descriptografia. Transformação é a lista de operações realizadas em uma entrada para fornecer a saída esperada. Assim, uma transformação cifrada é o conjunto de operações que transformam dados criptografados ilegíveis de volta a dados legíveis e descriptografados. Uma vulnerabilidade de transformação cifrada significa que o algoritmo de criptografia é fácil de quebrar, em última análise, minando o propósito da criptografia em primeiro lugar.

5. Componentes com vulnerabilidades conhecidas

Cada aplicativo web depende de outros componentes para funcionar. Por exemplo, se você estiver executando um aplicativo em um servidor web/aplicativo não recortado, o servidor será o componente com vulnerabilidades conhecidas. A lista De Vulnerabilidades e Exposições Comuns (CVE) inclui todas as vulnerabilidades de segurança conhecidas. Como os atores mal-intencionados estão cientes da lista, eles procuram regularmente componentes sem as atualizações de patch de segurança apropriadas. Uma vez que eles podem comprometer um componente do aplicativo web, eles podem obter acesso aos dados do aplicativo, também.

6. Política de compartilhamento de recursos entre origens (CORS)

Cada aplicativo baseado na Web usa uma URL como forma de conectar o navegador do usuário ao seu servidor. Uma proteção comum é chamada de Política da Mesma Origem. De acordo com isso, o servidor só responderá a uma URL que tenha o mesmo protocolo, nome de domínio de nível superior e esquema de caminho. Isso significa que você pode acessar http://company.com/page1 e http:/company.com/page2 porque ambos têm o seguinte em comum:

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

Embora segura, a Mesma Política de Origem torna-se restritiva ao trabalhar com aplicativos baseados na Web que precisam de acesso a recursos que se conectam a subdomínios ou terceiros.

Uma política CORS dá ao navegador permissão para acessar esses recursos compartilhados criando um conjunto de cabeçalhos HTTP permitidos considerados “confiáveis”. Por exemplo, um aplicativo pode precisar retirar dados de dois bancos de dados em diferentes servidores web. Criar uma lista específica de “permitido” torna-se muito trabalho à medida que você adiciona mais servidores. Como o aplicativo é “compartilhado” por ambos os servidores, a organização cria uma política CORS que permite que os navegadores se conectem a ambos. No entanto, se uma política CORS não estiver bem definida, a política pode permitir que os servidores forneçam acesso quando um ator mal-intencionado solicitar.

7. Gerenciamento de credenciais

As credenciais do usuário consistem em um ID de usuário e senha. Para ter acesso a um aplicativo, o usuário deve inserir ambas as informações na página de login. O aplicativo compara esses dados com os armazenados em seu banco de dados. Se ambas as peças coincidirem, concede ao usuário acesso. No entanto, os bancos de dados geralmente armazenam essas informações em texto simples ou usam criptografia fraca. O gerenciamento de credenciais ruins torna mais fácil para os invasores roubar credenciais e usá-las para obter acesso a aplicativos web.

8. Falsificação de solicitação de local cruzado (CSRF)

Um ataque CSRF aproveita os métodos de engenharia social para fazer com que o usuário altere informações, como nome de usuário ou senha, em um aplicativo. Ao contrário dos ataques de malware ou scripting cross-site (XXS), um CSRF exige que um usuário esteja logado no aplicativo que usa apenas cookies de sessão para rastrear sessões ou validar solicitações do usuário. Uma vez que o usuário toma a ação pretendida, o invasor aproveita o navegador para realizar o resto do ataque, como a transferência de fundos, sem que o usuário perceba o que aconteceu. Por exemplo, como o OWASP explicou,o recurso “compre agora” em sites de varejo é fácil de explorar através de um ataque CSRF porque o invasor pode usar os cookies armazenados no navegador que salvam os dados de pagamento para completar o ataque.

9. Scripting cross-site (XSS)

Diferente de um CSRF que exige que um usuário conectado a um aplicativo seja enganado a fazer algo, um ataque XSS requer que o cibercriminoso insira código em uma página da Web, geralmente em algum elemento da página como uma imagem. Quando o usuário abre a página da Web em seu navegador, o código malicioso baixa e executa no navegador. Por exemplo, o código pode redirecionar os usuários de um site legítimo para um mal-intencionado.

10. Indexação de diretório

Os servidores web geralmente listam todos os arquivos armazenados neles em um único diretório. Se um usuário está tentando localizar um arquivo específico em um aplicativo da Web, ele normalmente inclui o nome do arquivo como parte da solicitação. Se esse arquivo não estiver disponível, o aplicativo retornará uma lista de todos os arquivos indexados, dando ao usuário uma maneira de escolher outra coisa.

No entanto, os servidores web indexam automaticamente os arquivos. Se o aplicativo retornar uma lista de todos os arquivos armazenados, um ator mal-intencionado que explora vulnerabilidades no índice de diretório pode ter acesso a informações que podem dizer-lhes mais sobre o sistema. Por exemplo, ele pode dizer-lhes sobre nomear convenções ou contas de usuários pessoais. Ambos os pontos de dados podem ser usados para localizar informações confidenciais ou se envolver em ataques de roubo de credenciais.

11. Travessia do diretório

Também chamado de escalada de diretório, ponto-ponto-barra e ataque de backtracking, o método de travessia do diretório aproveita a maneira como um aplicativo obtém dados do servidor web. Geralmente, as ACLs (Access Control Lists, listas de controle de acesso) limitam o acesso do usuário a arquivos específicos dentro de um diretório raiz.

Considere um conjunto de pastas aninhadas que seguem esta ordem:

• Diretório raiz: Meus dados muito sensíveis (MVSD)
• Dentro da pasta MVSD: Protegendo da pasta H@x0rs (PfH)
• Dentro da pasta PfH: Minha senha é ruim (MPiB) pasta
• Dentro da pasta MPiB: H@x0rs stole my info arquivo

Agora, você pode ter um conjunto adicional de pastas fora dessa pasta raiz, incluindo Imagens, Vídeos e Downloads. A menos que você tenha acesso a cada uma dessas outras pastas básicas, você não pode acessar as informações que elas contêm.

Os aplicativos da Web organizam as informações da mesma forma, mesmo que você não a veja. Em um ataque transversal do diretório, atores mal-intencionados descobrem a estrutura de URL que o aplicativo usa para solicitar arquivos. Usando a hipotética acima, essa URL pode ser:

www.myinsecurewebapp.com/MyPas… “.asp?item=” indica que essa URL puxou o arquivo “H@x0rsStoleMyInfo” da pasta “Minha senha é ruim”. Agora, eles conhecem a estrutura das pastas e como começar a obter arquivos diferentes.

Usando essa estrutura, eles adicionam “.. No final. O “.. /” indica mover de uma pasta para uma logo acima dela na hierarquia. O novo pedido pode ser assim:

www.myinsecurewebapp.com/MyH@cking.asp?item=../

Eles continuam adicionando o .. / até que eles tenham acesso a outro arquivo. Se eles souberem o nome do arquivo, como um nome de arquivo do sistema operacional, eles podem fazer isso:

www.mywebsiteinfo.com/MyPasswordisBad.asp?item=../genericoperatingsystemfile

Neste ponto, eles continuam adicionando mais “.. /” após o sinal igual até que eles chegar ao nível da pasta e arquivar eles querem.

12. Encapsulamento

Ao contrário de algumas das outras vulnerabilidades que aproveitam o acesso do navegador da Web aos aplicativos, as explorações de vulnerabilidade de encapsulamento se concentram em fraquezas na maneira como um desenvolvedor codificava o aplicativo. O encapsulamento do termo de programação refere-se ao agrupamento de dados e ações que podem ser tomadas sobre esses dados em uma única unidade. O encapsulamento protege os dados escondendo detalhes sobre como o código funciona, o que cria uma melhor interface de usuário. Os usuários não precisam saber como o aplicativo lhes traz dados; eles só precisam de acesso a ele.

Por exemplo, um desenvolvedor pode agrupar controles de acesso, como permissões de leitura/gravação, na capacidade de um aplicativo de recuperar dados. Quando o usuário solicita informações no aplicativo, ele retorna apenas os dados que ele tem permissão para acessar.

No entanto, se os desenvolvedores não definirem claramente os limites entre os dados e as ações tomadas em diferentes áreas do aplicativo, o aplicativo tem uma vulnerabilidade de encapsulamento. Os atacantes exploram isso enviando ao aplicativo uma solicitação que eles sabem que resultará em uma mensagem de erro. A mensagem de erro fornece informações sobre como o aplicativo funciona, permitindo tipos adicionais de ataque, como uma negação de serviço.

13. Manipulação de erros

Vários métodos de ataque diferentes dependem de como um aplicativo responde a insumos ou condições anormais. Um exemplo de uma mensagem de erro é a mensagem “404 não encontrado” quando você tenta acessar um site. Para a maioria dos aplicativos e sistemas corporativos, as mensagens de erro fornecem informações valiosas sobre como corrigir um problema.

No entanto, para aplicativos web, muitas informações devolvidas através de uma mensagem de erro podem dar aos atores mal-intencionados essa mesma informação. Muitas vezes, os invasores enviam ao aplicativo da Web uma consulta que eles sabem que retornará uma mensagem de erro. Eles geralmente fazem isso durante a fase de reconhecimento, onde tentam obter o máximo de informações possível para que possam encontrar vulnerabilidades exploráveis.

14. Falha em restringir o acesso à URL

Como acontece com muitas outras vulnerabilidades de aplicativos da Web, esta também se alinha aos direitos de controle de acesso. Os aplicativos usam restrições de URL para impedir que usuários não privilegiados acessem dados e recursos privilegiados. Cada botão clicável em um aplicativo web direciona para uma URL. Uma falha em restringir a vulnerabilidade de acesso significa que, ao clicar no botão no aplicativo, impediria o acesso, o uso direto da URL no navegador permite o acesso. Quando um aplicativo falha em restringir o acesso à URL, atores mal-intencionados podem usar a “navegação forçada” para um ataque.

Por exemplo, um aplicativo web pode ter uma estrutura de URL que se pareça com isso:

www.insecurewebapp.com/failure… os invasores sabem que o último item nessa URL é o tipo de dados, eles podem tentar obter palpites na estrutura de URL para um tipo específico de informações confidenciais.

www.insecurewebapp.com/failure… o aplicativo tem uma falha em restringir a vulnerabilidade de acesso à URL, conectando essa URL diretamente no navegador dá acesso ao invasor.

15. Divisão de resposta HTTP

A divisão de resposta HTTP é um tipo de ataque de injeção de CRLF. HTTP é a maneira como um navegador envia consultas e um servidor envia respostas. Em um ataque de divisão de respostas HTTP, os atores mal-intencionados usam as notações DE CR e LF para manipular como o navegador e o servidor “conversam” entre si que envia uma solicitação, mas pede ao servidor para “dividir” a resposta em diferentes partes. Dividir a resposta em duas partes dá ao invasor controle sobre quais dados o servidor envia em resposta à segunda parte da solicitação. Quando esses dados solicitados são dados confidenciais ou de identificação do usuário, o invasor mal-intencionado completou o ataque.

16. ADULTERação do verbo HTTP

HTTP é o protocolo que permite que os aplicativos respondam a solicitações e recuperem dados. Um verbo HTTP é uma das várias ações que o aplicativo pode usar ao consultar o servidor. Os verbos HTTP comuns incluem:

• GET: recupera dados de fonte especificada
• HEAD: solicita visualização de recurso especificado
• POST: envia entidade a recurso especificado, como edição de dados
• PUT: transmite novos dados para o recurso especificado substituindo as informações antigas
• DELETE: exclui o recurso especificado inteiramente

A maioria dos aplicativos da Web usa verbos HTTP para autenticar usuários e gerenciar privilégios de acesso. Atores mal-intencionados podem contornar controles de autenticação e acesso destinados a proteger informações privilegiadas.

17. Validação inadequada do certificado

Os certificados SSL vinculam um nome de domínio, nome do servidor ou nome de host a uma empresa e localização. Por exemplo, o GoodSecureCo instala os arquivos de dados do certificado SSL em seus servidores web dos EUA. Toda vez que um navegador pede dados do servidor web dos EUA, o certificado SSL verifica se o navegador do usuário se conecta com um proprietário aprovado. Os dois se conectam com segurança se a resposta for sim.

Quando o software se recusa a validar ou validar incorretamente o certificado, ele tem uma vulnerabilidade de validação de certificado inadequada. Na maioria das vezes, os invasores criam uma falsa entidade confiável que engana o servidor ou aplicativo para pensar que o certificado é válido para que ele aceite a transferência de dados como legítima. Muitas vezes, atores mal-intencionados usam vulnerabilidades de validação de certificados inadequados como uma maneira de instalar malware em pontos finais.

18. Falha de injeção

Uma falha de injeção permite uma variedade de diferentes métodos de ataque. Qualquer aplicativo que permita que os usuários atualizem um banco de dados, comando shell ou chamada do sistema operacional podem ter uma falha de injeção. Na computação, um intérprete é um programa que toma um comando, gera uma instrução e realiza a ação dentro do aplicativo.

Atores mal-intencionados usam falhas de injeção para mudar os comandos que levam a ações novas e não intencionais dentro do aplicativo. Aproveitando essas falhas, os invasores podem criar, ler, atualizar ou excluir dados.

19. Armazenamento criptográfico inseguro

Criptografar dados armazenados é uma prática recomendada comum para impedir o acesso não autorizado ou o uso de informações confidenciais. A criptografia leva informações armazenadas em um formato legível, como o PlainText, e depois usa algoritmos matemáticos para embaralhá-los, tornando-as ilegível. A criptografia normalmente requer uma chave de criptografia, que é a tecnologia que aplica o algoritmo que embaralha os dados e também é usada para tornar as informações legíveis novamente. No entanto, se alguém encontrar a chave de criptografia, a proteção não funciona mais.

A vulnerabilidade de armazenamento criptográfico inseguro significa que você tem um problema com um ou mais dos seguintes:

• Não criptografando todos os dados confidenciais
• Armazenamento e gerenciamento de chaves inadequados
• Algoritmos de criptografia fáceis de quebrar
• Algoritmo não testado internamente

20. Deserialização insegura

Os aplicativos lidam com estruturas de dados complexas. A serialização converte as estruturas em um objeto que pode ser armazenado e transmitido facilmente. Por exemplo, pense em diferentes ações que vão para fazer um sanduíche de manteiga de amendoim e geleia:

1. Obter placa
2. Pegue pão
3. Pão aberto
4. Tire o pão 1
5. Coloque pão 1 no prato
6. Tire o pão 2
7. Coloque pão 2 no prato
8. Pegue a faca
9. Pegue manteiga de amendoim
10. Manteiga de amendoim aberta
11. Pegue geleia
12. Geleia aberta
13. Obter manteiga de amendoim na faca
14. Coloque manteiga de amendoim no pão 1
15. Obter geleia na faca
16. Coloque geleia no pão 2
17. Smoosh pão 1 e pão 2 junto com lados cobertos voltados

Você precisa que todas essas coisas aconteçam como parte da fabricação do sanduíche, mas eles não são necessariamente passo a passo nesta ordem. Ter que enviar todos esses 17 pontos de dados, como mensagens individuais, toda vez que alguém pede um sanduíche de manteiga de amendoim e geleia pode ser demorado para escrever e enviar. Provavelmente, você os agruparia em um documento como “Peanut Butter and Jelly Sandwich” que você envia quando alguém pergunta, semelhante à serialização. Quando a pessoa abre o documento, pode ver cada ponto de dados individual, semelhante à deserialização.

A deserialização é o processo de reconstrução da estrutura original de dados expandida. Com uma vulnerabilidade de desercionalização, atores mal-intencionados podem alterar a lógica do aplicativo ou executar código remotamente, um dos tipos de ataque mais graves.

21. Digestão insegura

Outra vulnerabilidade criptográfica, uma vulnerabilidade insegura de digestão de mensagens reduz a eficácia da criptografia. Um digestor de mensagens contém a função de hash criptográfico, que é o algoritmo que mapeia um comprimento arbitrário de dados para o conjunto de bits fixos, uma maneira de armazenar dados compactamente. Ao contrário da criptografia que exige que o remetente e o usuário tenham chaves, as funções hash não têm.

Atores mal-intencionados aproveitam vulnerabilidades de digestão inseguras para se envolver em um “ataque de colisões de hash”. O objetivo do ataque é ver se o envio de uma entrada resulta na geração de um hash duplicado. Se os atacantes forçarem um hash compartilhado, então eles podem oferecer um arquivo malicioso para download usando este hash, o que deixa o usuário final assumindo que o arquivo é válido.

22. Referências de objeto direto inseguras (IDOR)

Os URLs de aplicativos web podem expor o formato/padrão usado para orientar os usuários a retroacionar os locais de armazenamento. Por exemplo, uma URL pode indicar o formato/padrão de um identificador de registro em um sistema de armazenamento, como um banco de dados ou um sistema de arquivos.

Sozinho, o IDOR pode ser um problema de baixo risco. No entanto, um IDOR em combinação com uma verificação de controle de acesso falhada dá aos atacantes uma maneira de lançar com sucesso um ataque de enumeração.

23. Registro e monitoramento insuficientes

Vulnerabilidades insuficientes de registro e monitoramento ocorrem quando os registros de eventos de dados falham em capturar as informações necessárias que podem evitar um ataque. Cada usuário, dispositivo e recurso gera um registro de eventos que informa à sua equipe de segurança o que está acontecendo em seus sistemas, redes e aplicativos.

Uma vez que ataques bem-sucedidos geralmente usam sondagens de vulnerabilidade durante a fase de reconhecimento, coletar os dados certos de registro de eventos é uma maneira de mitigar o risco. As fraquezas comuns de registro e monitoramento incluem:

• Falha na coleta de logs para eventos auditáveis, como logins, logins com falhas e transações de alto valor
• Falha em gerar um aviso e registros de erros adequados e claros
• Falha no monitoramento de registros de aplicativos e API para atividade anormal
• Armazenando troncos localmente
• Falha em definir efetivamente limites de alerta e processos de escalonamento de resposta
• Falta de gatilhos de alerta durante testes de penetração e testes dinâmicos de segurança de aplicativos (DAST)
• Falta de funções de detecção, escalonamento e alerta de aplicativos em tempo real ou quase em tempo real

24. Expiração insuficiente da sessão

O tempo limite da sessão é quando um aplicativo registra automaticamente um usuário após ficar ocioso por um período de tempo especificado. Quando um aplicativo está ocioso e aberto, os atacantes procuram roubar as credenciais associadas à conta.

Alguns exemplos de fraquezas insuficientes de expiração de sessão incluem:

• Falta de tempo limite de sessão
• Intervalos de sessão mais longos do que o necessário
• Incapacidade de rastrear criação/destruição de sessões para analisar tendências

25. Proteção insuficiente da camada de transporte

A segurança da camada de transporte (TLS) é a maneira como os aplicativos de computador “conversam” uns com os outros na internet. Alguns aplicativos só usam TLS durante o processo de autenticação, deixando dados e informações de sessão de ID expostas quando alguém usa o aplicativo.

Os atacantes podem usar essa vulnerabilidade para interceptar dados à medida que viajam pela internet entre o dispositivo do usuário e o servidor de aplicativos.

26. Injeção de LDAP (Lightweight Directory Access Protocol, protocolo de acesso ao diretório leve)

O LDAP é um protocolo que permite que os aplicativos conversem com servidores de serviços de diretório que armazenam IDs de usuário, senhas e contas de computador. Quando os aplicativos aceitam a entrada do usuário e a executam, os invasores podem explorar o servidor LDAP enviando solicitações maliciosas.

Alguns exemplos de problemas de codificação LDAP incluem:

• Acesso excessivo privilegiado atribuído às contas LDAP
• Falta de regulação da produção
• Incapacidade de realizar verificações dinâmicas
• Falta de análise de código fonte estático

27. Código malicioso

Tradicionalmente, o código que pretende causar danos é considerado código malicioso. Por exemplo, as pessoas normalmente consideram código malicioso em termos de vírus, malware e ransomware.

No entanto, ele também se refere ao código que pode fornecer um backdoor em um aplicativo que permite que as pessoas tenham acesso remoto a um computador. A falta de práticas seguras de codificação pode levar a backdoors de aplicativos. Embora não intencionais, esses erros de programação tornam o aplicativo web vulnerável. Além disso, uma vez que aplicativos modernos geralmente copiam e colam código de um lugar para outro, um erro em uma fonte pode levar ao mesmo código malicioso sendo usado em vários aplicativos.

28. Faltando controle de nível de função

Uma vez que os usuários autenticam em um aplicativo, os controles de acesso ao nível de função definem as ações que podem tomar dentro dele. por exemplo:

www.insecurewebapp.com/genericusername/read

www.insecurewebapp.com/SuperAd… neste exemplo, o nome de usuário genérico pode ler arquivos neste aplicativo, enquanto o Super Adminuser pode editar dentro deste aplicativo. Como os direitos de acesso estão incluídos na URL, ninguém precisa da autenticação que protege essas ações. Usuários não administrativos autenticados ou usuários não autenticados podem digitar uma URL na esperança de obter acesso administrativo. Por exemplo, os atores mal-intencionados podem tentar digitar:

www.insecurewebapp.com/SuperAd… faltar ao controle de nível de função significa que o ator mal-intencionado não precisa autenticar para o sistema e agora pode excluir dados.

29. PT_DENY_ATTACH desaparecida

Embora um pouco mais específico e técnico do que outras vulnerabilidades de aplicativos web, este é cada vez mais importante à medida que as empresas constroem mais aplicativos móveis. Um depurador é um programa que ajuda os desenvolvedores de aplicativos a encontrar erros em sua codificação. Eles geralmente usam depuração para manter o aplicativo para evitar erros de inatividade. No entanto, atores mal-intencionados podem aproveitar esses mesmos depurtores para aprender como o aplicativo funciona e encontrar maneiras de explorá-los.

O rastreamento de processo, mais comumente chamado de ptrace, é uma chamada de sistema que muitos depurantes e ferramentas de análise de código usam. No entanto, as chamadas ptrace dão às ferramentas uma maneira de controlar seus alvos. O PT_DENY_ATTACH é um comando para aplicativos móveis iOS que impede que os depurantes se conectem aos aplicativos. Um comando PT_DENY_ATTACH faltando deixa um aplicativo móvel iOS em risco porque atacantes mal-intencionados podem lançar ptrace, conectar-se ao aplicativo e infiltro-lo.

30. Injeção de comando do sistema operacional (OS)

Alguns aplicativos web fazem chamadas para sistemas operacionais para que possam se comunicar com o sistema operacional ou hardware. As chamadas do SISTEMA OPERACIONAL incluem funções como:

• Controle de processos: monitorar o que um aplicativo está fazendo e prever o término
• Gerenciamento de arquivos: dando ao aplicativo acesso para interagir com arquivos
• Gerenciamento de dispositivos: solicitando ou gerenciando hardware como poder de processamento
• Manutenção de informações: gerenciamento ou manutenção de informações como parte da manutenção dos dados atualizados
• Comunicação interprocessa: coordenação de processos para operação efetiva

Chamadas de comando do SISTEMA DE NÃO-alimentação inseguras permitem que os usuários forneçam entradas não validadas. Em outras palavras, os atores mal-intencionados podem pegar a chamada de comando do SISTEMA OPERACIONAL, adicionar uma notação de consulta adicional e obter informações valiosas sobre como explorar o aplicativo.

31. Condição da corrida

Os processos de aplicativos web geralmente dependem de uma série de ações, executadas a fim, para fazer uma tarefa. Por exemplo, considere o seguinte processo:

1. Clique no ícone Dom
2. Aguarde que o Word abra
3. Clique em “arquivo aberto”
4. Aguarde a lista de locais de armazenamento de arquivos
5. Procure o nome do arquivo que você deseja
6. Clique no arquivo com o nome certo
7. Aguarde que o arquivo abra no Word
8. Editar documento

You need to do these steps in that precise order so that you can write in a new Word document. Functionally, many applications rely on a similar approach, where each step relies on the completion of the previous one.

However, application tasks are often more complex and need to be faster. This means that they use multi-threaded and asynchronous order. For example, if you’re collaborating in real-time with a co-worker on a document in a shared drive, you’re both giving the application tasks. This is where the race condition vulnerability comes into play.

Aplicativos web codificados incorretamente podem ter ajuste lógico para ações assíncronsas, mas não possuem os controles apropriados. Quando isso acontece, atacantes mal-intencionados podem manipular o tempo das ações, o que afasta o sequenciamento e leva a comportamentos inesperados, muitas vezes maliciosamente pretendidos, de aplicativos.

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

As vulnerabilidades do RCE são erros de codificação em aplicativos web que permitem que atores mal-intencionados insirem código, independentemente de sua localização geográfica. Os RCEs são uma categoria maior de vulnerabilidades de injeção de aplicativos da Web onde atores mal-intencionados inserem seu próprio código em um aplicativo que não verifica as entradas do usuário para que o servidor o veja como código de aplicativo legítimo. Geralmente, os atacantes aproveitarão vulnerabilidades não reparadas comumente conhecidas e inserirão seu código no aplicativo.

33. Inclusão remota de arquivos (RFI)

Os desenvolvedores usam instruções “incluem” em seu código para conectar diretórios comuns a um aplicativo. Por exemplo, um aplicativo pode querer extrair informações de um banco de dados. Em vez de enc codificar manualmente para puxar cada arquivo, a instrução “incluir” pode ser usada para se conectar a todo o diretório de origem para que ele possa usar tudo armazenado lá.

Se um aplicativo web tiver uma vulnerabilidade RFI, atores mal-intencionados podem direcionar o aplicativo para carregar malware ou outro código malicioso para o site, servidor ou banco de dados.

34. Erro de configuração da segurança

Uma das vulnerabilidades mais prevalentes do aplicativo web é o potencial de uma configuração errada de segurança. Geralmente, essa vulnerabilidade ocorre quando uma organização falha em alterar as configurações de segurança padrão. Por exemplo, o software off-the-shelf geralmente é fornecido com um ID administrativo padrão e senha. A falha em alterá-las é considerada uma configuração errada de segurança.

As configurações típicas de segurança incluem:

• Uso de contas/senhas padrão
• Falta de política de senha segura
• Software não reparecido
• Falta de configurações adequadas de arquivos e diretórios
• Deixando recursos, componentes e outros recursos nãousados
• Falta de criptografia
• Políticas de firewall ruins

35. Exposição de dados sensíveis

Ao contrário de uma violação de dados onde um cibercriminoso rouba informações, vulnerabilidades confidenciais de exposição de dados deixam informações visíveis ao público.

Existem várias vulnerabilidades de exposição sensíveis, incluindo:

• Falta de protocolo SSL (Secure Sockets Layer, camada de soquete seguro) que autentica e criptografa dados
• Locais de armazenamento em nuvem mal configurados armazenando dados em plaintext
• Dados transmitidos em texto claro
• Algoritmos de criptografia desatualizados ou fracos
• Teclas de criptografia fracas ou padrão usadas

36. Vazamento de ID de sessão

Os IDs de sessão são os identificadores exclusivos que autenticam os usuários e rastreiam suas atividades quando usam um aplicativo web. As vulnerabilidades do aplicativo web que levam ao vazamento da sessão incluem:

• Armazenamento do ID de sessão na sequência de consulta. Ao armazenar o ID de sessão na parte da URL que pede ao aplicativo para recuperar informações do banco de dados, o compartilhamento dessa URL permite que o destinatário herde essa sessão sem nova autenticação.
• Armazenando o ID de sessão em cookies HTTP: Ao armazenar o ID de sessão nos pequenos arquivos de dados que permitem que um servidor da Web se lembre de um navegador da Web e usando o protocolo HTTP não criptografado, o aplicativo dá ao invasor a capacidade de roubar o ID da sessão e se passar pelo usuário.

37. Injeção SQL

O SqL (Structured Query Language) é uma linguagem de programação para bancos de dados que permite a recuperação e manipulação de dados relacionais para bancos de dados relacionais. Uma vulnerabilidade de injeção SQL está sob o maior grupo de entradas de usuário não validadas. Quando os cibercriminosos enviam solicitações que eles sabem que são falsas, o aplicativo da Web retorna uma mensagem de erro que lhes dá informações sobre como o banco de dados é organizado e protegido.

38. Upload de arquivo irrestrito

Aplicativos web geralmente incorporam recursos de upload de arquivos. Por exemplo, se você quiser inserir dados em massa, você pode carregar um arquivo CSV em um banco de dados. Uma vulnerabilidade irrestrita de upload de arquivos pode ser a falta de autenticação/autorização quando alguém tenta carregar um arquivo. Isso significa que o aplicativo não consegue verificar o usuário, dando aos atores mal-intencionados a capacidade de carregar arquivos comprometidos. Além disso, o aplicativo pode não higienizar arquivos antes do upload, dando aos invasores uma maneira de deixar conteúdo malicioso nos arquivos, como macros que ocultam malware.

Vulnerabilidades adicionais de upload de arquivos incluem:

• Permite todas as extensões de arquivo
• Falha em autorizar ou autenticar usuários
• Falha em digitalizar o conteúdo para garantir que o tipo de arquivo seja esperado
• Permite que o servidor web busque arquivos
• Armazena arquivos em um diretório acessível ao público

39. Ativação automática não validada da biblioteca

Os desenvolvedores usam bibliotecas de terceiros para economizar tempo na codificação. Muitas vezes, isso permite que eles usem código pré-testado que acelere o processo de desenvolvimento de aplicativos. No entanto, o uso de código aberto disponível publicamente aumenta os riscos de segurança, incluindo:

• Projetos abandonados que não são mais atualizados
• A falta de propriedade documentada aumenta o risco de código malicioso adicionado
• Monitoramento de atualizações de bibliotecas para corrigir vulnerabilidades

Como muitos aplicativos envolvem dependências de bibliotecas de terceiros, essa vulnerabilidade está se tornando mais comum.

40. Redirecionamentos e encaminhamentos não validados

Web applications can use redirects or forwards after a user submits a form. For example, if your marketing website has a form so that visitors can download a whitepaper, the page redirects or forwards them to the “thank you” page when they submit the form. However, malicious actors can impersonate these redirected or forwarded page URLs to steal user information.

Exemplos dessa vulnerabilidade incluem aplicativos web com:

• Um grande número de páginas de destino
• Não armazene URLs completos
• Falta de identificadores para esses redirecionamentos/encaminhamentos
• Falta de identificadores utilizados como parâmetros de solicitação
• Falha em filtrar entradas de URL não confiáveis

41.XML Entidades Externas (XXE)

O XML (Extensible Markup Language, linguagem de marcação extensível) descreve dados, como o conteúdo de uma página da Web ou arquivo de banco de dados. A formatação XML permite que os aplicativos compreendam informações e compartilhem dados de forma consistente. Para ler esses dados, você precisa ter um processador XML. Também referido como um analisador XML, essas ferramentas automatizadas leem arquivos, transformam o conteúdo, atualizam bancos de dados e entregam esse conteúdo para que o programa possa acessá-lo.

No entanto, quando os aplicativos da Web usam o formato XML para transmitir dados entre o navegador e o servidor, eles geralmente usam APIs para processar os dados. Dentro do padrão XML, as unidades de armazenamento são chamadas de “entidades”. A entidade externa refere-se a uma unidade de armazenamento que pode acessar conteúdo local ou remoto.

Uma vulnerabilidade XXE pode surgir da falha em:

• Conheça a fonte antes de aceitar ou carregar dados XML
• Desativar definições de tipo de documento (DTDs)
• Use formatos de dados menos complexos como o JSON
• Patch XML processadores ou sistema operacional subjacente
• Detectar XXE em código-fonte

SecurityScorecard mitiga riscos de aplicativos web

A plataforma de classificações de segurança do SecurityScorecard permite que as organizações monitorem continuamente a eficácia de seus controles de aplicativos web. Nossa plataforma oferece uma visão externa da sua postura de segurança de aplicativos web. Aproveitamos a inteligência de ameaças recebidas de condições exploráveis conhecidas, como bancos de dados CVE, bancos de dados de exploração e pesquisa na internet.

Nosso módulo ingere dados de vários conjuntos de dados públicos e usa nosso mecanismo proprietário de indexação e agregação para fornecer sua pontuação de classificação de segurança. Essa pontuação dá visibilidade à probabilidade de uma violação de dados usando um sistema A-F fácil de ler.

Com as sugestões de remediação acionáveis do SecurityScorecard, você pode priorizar sua estratégia para obter uma postura de segurança de aplicativos web mais robusta.

FONTE: SECURITYSCORECARD