10 principais tipos de vulnerabilidades de segurança
Índice
- Injeção de banco de dados
- Autenticação quebrada
- Exposição de dados sensíveis
- Entidades externas XML (XEE)
- Controle de acesso quebrado
- Segurança equivocada
- Scripts de sites cruzados (XSS)
- Deserialização insegura
- Usando componentes com vulnerabilidades conhecidas
- Montagem e monitoramento insuficientes
Injeção de banco de dados:
No caso de enviar dados não confiáveis para o intérprete como parte do comando através de qualquer área que leve a entrada do usuário i.e entrada de formulário ou qualquer outra área de envio de dados, ocorrem falhas de injeção. As consultas maliciosas do invasor podem enganar o intérprete a executar comandos que podem mostrar dados confidenciais que o usuário não tem autorização para dar uma olhada. Por exemplo, em um ataque de injeção de SQL, quando a entrada do formulário não é adequadamente higienizada, o invasor pode entrar no banco de dados SQL e acessar seu conteúdo sem autorização, apenas inserindo o código de banco de dados SQL malicioso em um formulário que espera um texto simples. Qualquer tipo de campo que toma a entrada do usuário é injetável i.e parâmetros, variáveis de ambiente, todos os serviços da web, etc.
O aplicativo é vulnerável ao ataque de injeção quando os dados fornecidos pelo usuário não são higienizados e validados, pelo uso de consultas dinâmicas sem escape com reconhecimento de contexto e o uso de dados hostis diretamente. As falhas de injeção podem ser facilmente descobertas através do exame de código e pelo uso de ferramentas automatizadas, como scanners e fuzzhers. Para evitar ataques de injeção, há alguma medida que pode ser tomada como separar os dados dos comandos e consultas, o uso de uma API segura que fornece uma interface parametrizada, o uso da validação de entrada do lado do servidor "da lista branca" através de ferramentas como Snort, Escaping de caracteres especiais usando sintaxe de fuga específica, etc.
Um ataque de injeção pode levar a uma enorme perda de dados, divulgação de informações confidenciais, negação de acesso e pode até levar a uma aquisição completa do aplicativo. Alguns controles SQL como limite podem ser usados para controlar grandes quantidades de perda de dados em caso de ataque. Alguns tipos de ataques de injeção são SQL, OS, NOSQL, ataques de injeção de LDAP.
Autenticação quebrada:
Os invasores podem acessar contas de usuário e podem até comprometer todo o sistema host através de contas administrativas, usando as vulnerabilidades em sistemas de autenticação. As falhas de autenticação permitem que o invasor comprometa senhas, tokens de sessão, chaves de autenticação e pode ser acorrentado com outros ataques que podem levar ao acesso não autorizado de qualquer outra conta de usuário ou sessão temporariamente e, em alguns casos, permanentemente. Digamos que um usuário tenha uma lista de palavras ou um dicionário de milhões de nomes de usuário e senhas válidas obtidas durante uma violação. Ele pode usá -los um por um em um tempo extremamente menor usando ferramentas e scripts automatizados no sistema de login para ver se alguém funciona. Má implementação de gerenciamento de identidade e controles de acesso leva a vulnerabilidades como autenticação quebrada.
O aplicativo é vulnerável ao ataque de autenticação quando permite tentar diferentes nomes de usuário e senhas, permite ataques de dicionário ou ataques de força bruta sem qualquer estratégia de defesa, use senhas ou senhas fáceis e padrão que vazam em qualquer violação, expõe IDs de sessão em URL, usa Esquema de recuperação de senha ruim, usa um padrão de cookies. A autenticação quebrada pode ser explorada facilmente usando ferramentas simples para ataques brutos e dicionários com um bom dicionário. Esses tipos de ataques podem ser evitados usando sistemas de autenticação de vários fatores, implementando verificações de senha fracas executando uma senha através de um banco de dados de uma senhas ruins, por não usar credenciais padrão, alinhando a política de complexidade de senha, pelo uso do bom servidor do lado do servidor Gerenciador de sessão que gera um novo ID de sessão aleatória após o login, etc.
A vulnerabilidade de autenticação quebrada pode resultar em comprometer algumas contas de usuário e uma conta de administrador, que é tudo um invasor para comprometer um sistema. Esses tipos de ataques levam a roubo de identidade, fraude da seguridade social, lavagem de dinheiro e divulgação de informações altamente classificadas. Os ataques incluem ataques de dicionário, forçando bruto, seqüestro de sessão e ataques de gerenciamento de sessão.
Exposição de dados sensíveis:
Às vezes, os aplicativos da Web não protegem dados confidenciais e informações como senhas, credenciais de banco de dados, etc. Um invasor pode facilmente roubar ou modificar essas credenciais fracamente protegidas e usá -lo para fins ilegítimos. Dados sensíveis devem ser criptografados enquanto estiver em repouso ou em trânsito e ter uma camada extra de segurança, caso contrário, os atacantes podem roubá -lo. Os atacantes podem colocar as mãos em dados expostos sensíveis e roubar hash ou limpar usuários e credenciais de banco de dados do servidor ou um navegador da web. Por exemplo, se um banco de dados de senha usa hashes simples ou sem sal para armazenar senhas, uma falha de upload de arquivos pode permitir que um invasor recupere o banco de dados de senhas que levará à exposição de todas as senhas com uma tabela de arco-íris de hashes pré-calculados.
A falha principal não é apenas que os dados não são criptografados, mesmo que sejam criptografados, mas a geração chave fraca, algoritmos fracos de hash, o uso fraco da cifra também pode resultar nesses tipos de um dos ataques mais comuns. Para evitar esses tipos de ataques, primeiro, classifique qual tipo de dados pode ser considerado sensível de acordo com as leis de privacidade e aplicar controles conforme a classificação. Tente não armazenar nenhum dado classificado que você não precise, lave -os assim que o usar. Para os dados em trânsito, criptografi -os com protocolos seguros i.e tls com cifras de PFS, etc.
Esses tipos de vulnerabilidades podem resultar na exposição de informações altamente sensíveis, como credenciais de cartão de crédito, registros de saúde, senhas e quaisquer outros dados pessoais que possam levar a roubo de identidade e fraude bancária, etc.
Entidades externas XML (XEE):
Os processadores XML mal configurados processam referências de entidade externa dentro de documentos XML. Essas entidades externas podem ser usadas para recuperar os dados dos arquivos internos como /etc/passwd arquivo ou para executar outras tarefas maliciosas. Os processadores XML vulneráveis podem ser facilmente explorados se um invasor puder fazer upload de um documento XML ou incluir xml etc. Essas entidades XML vulneráveis podem ser descobertas usando ferramentas SAST e DAST ou manualmente, inspecionando dependências e configurações.
Um aplicativo da Web é vulnerável ao ataque XEE devido a muitas razões, como se o aplicativo aceitar a entrada XML direta de fontes não confiáveis, as definições de tipo de documento (DTDs) no aplicativo são ativadas, o aplicativo usa SAML para processamento de identidade como SAML usa XML para identidade inserções, etc. Os ataques XEE podem ser atenuados, evitando a serialização de dados sensíveis, usando formatos de dados menos complicados i.E JSON, Patching XML Processores O aplicativo está usando e até mesmo as bibliotecas, desativando DTDs em todos os analisadores XML, validação da funcionalidade de upload de arquivos XML usando verificação XSD, etc.
O aplicativo vulnerável a esses tipos de ataques pode levar ao ataque de DOS, bilhões de risadas, varredura de sistemas internos, varredura interna da porta, execução de um comando remoto que resulta em afetar todos os dados do aplicativo.
Controle de acesso quebrado:
O controle de acesso está dando aos usuários privilégios para realizar tarefas específicas. Vulnerabilidade de controle de acesso quebrado ocorre quando os usuários não são devidamente restritos nas tarefas que podem executar. Os atacantes podem explorar essa vulnerabilidade que pode acabar acessar a funcionalidade ou informação não autorizada. Digamos que um aplicativo da web permita ao usuário alterar a conta que ele está conectado apenas alterando o URL para a conta de outro usuário sem mais verificação. Explorando a vulnerabilidade de controle de acesso é um ataque de qualquer atacante, essa vulnerabilidade pode ser encontrada manualmente, bem como usando as ferramentas SAFT e Daft. Essas vulnerabilidades existem devido à falta de teste e detecção automatizada de aplicativos da Web, embora a melhor maneira de encontrá -los seja fazê -lo manualmente.
Vulnerabilidades contêm privilégios escalados i.E atuando como usuário que você não está ou atuando como administrador enquanto é um usuário, ignorando verificações de controle de acesso apenas modificando o URL ou alterando o estado do aplicativo, manipulação de metadados, permitindo que a chave primária seja alterada como a chave primária de outro usuário, etc. Para evitar esses tipos de ataques, os mecanismos de controle de acesso devem ser implementados no código do lado do servidor, onde os invasores não podem modificar os controles de acesso. Execução de limites de negócios de aplicativos exclusivos por modelos de domínio, desativando os diretórios de servidores, alertar o Admin sobre as repetidas tentativas de login com falha, a invalidação dos tokens JWT após o logout deve ser garantido para mitigar esses tipos de ataques.
Os atacantes podem atuar como outro usuário ou administrador usando essa vulnerabilidade para executar tarefas maliciosas, como criar, excluir e modificar registros, etc. Perda de dados maciça pode ocorrer se os dados não estiverem protegidos mesmo após uma violação.
Segurança equivocada:
A vulnerabilidade mais comum é a segurança da segurança. O principal motivo da vulnerabilidade é o uso da configuração padrão, configuração incompleta, configurações de ADHOC, cabeçalhos HTTP mal configurados e mensagens de erro detalhadas contendo mais informações do que o usuário realmente deveria saber. Em qualquer nível de um aplicativo da web, as equívocas de segurança podem ocorrer i.e banco de dados, servidor da web, servidor de aplicativos, serviços de rede, etc. Os atacantes podem explorar sistemas não patches ou acessar arquivos e diretórios desprotegidos para ter uma retenção não autorizada no sistema. Por exemplo, um aplicativo excessivamente detalhado mensagens de erro que ajudam o invasor a conhecer vulnerabilidades no sistema de aplicativos e a maneira como ele funciona. Ferramentas e scanners automatizados podem ser usados para detectar esses tipos de falhas de segurança.
Um aplicativo da Web contém essa vulnerabilidade de tipo, se estiver faltando as medidas de endurecimento da segurança em qualquer parte do aplicativo, portas desnecessárias estão abertas ou permite recursos desnecessários, senhas padrão são usadas, o tratamento de erros revela erros informativos ao atacante, ele está usando software de segurança não atingido ou desatualizado, etc. Pode ser evitado removendo recursos desnecessários do código, eu.e uma plataforma mínima sem recursos, documentação, etc. É fácil implantar outro ambiente que esteja travado adequadamente.
Esses tipos de vulnerabilidades ou falhas permitem que o invasor obtenha acesso não autorizado aos dados do sistema, o que leva à comprometimento completo do sistema.
Script de câmara cruzada (XSS):
As vulnerabilidades do XSS acontecem no ponto em que um aplicativo da Web incorpora dados não confiáveis em uma nova página do site sem aprovação ou escape legítimo, ou atualiza uma página atual do site com dados fornecidos pelo cliente, utilizando uma API do navegador que pode fazer HTML ou JavaScript. Falhas XSS ocorrem caso o site permita que um usuário adicione código personalizado a um caminho de URL que pode ser visto por outros usuários. Essas falhas são usadas para executar o código JavaScript malicioso no navegador do alvo. Digamos que um atacante pode enviar um link para a vítima que contém um link para o site de qualquer empresa. Essa conexão pode ter algum código JavaScript malicioso incorporado, caso a página do banco não esteja adequadamente garantida contra ataques XSS, ao clicar no link, o código malicioso será executado no navegador da vítima.
O script entre sites é uma vulnerabilidade de segurança que está presente em quase ⅔ dos aplicativos da web. Um aplicativo é vulnerável ao XSS se o aplicativo armazenar uma entrada do usuário não sedorizada que pode ser vista por outro usuário, pelo uso de estruturas JavaScript, aplicativos de página única e APIs que incorporam poderosamente informações controláveis do invasor a uma página são impotentes contra o DOM XSS. Os ataques XSS podem ser atenuados pelo uso de estruturas que escapam e higienizam a entrada XSS por natureza como reagir JS etc, aprendendo as limitações das estruturas e cobrindo -as usando os próprios casos, escapar.e em atributos HTML, URI, JavaScript, etc, uso da codificação sensível ao contexto em caso de modificar o documento no lado do cliente, etc.
Os ataques baseados em XSS são de três tipos i.e refletiu XSS, DOM XSS e XSS armazenados. Todos os tipos desses ataques têm uma quantidade significativa de impacto, mas no caso de xss armazenados, o impacto é ainda maior.E roubar credenciais, enviando malware para a vítima, etc.
Deserialização insegura:
A serialização dos dados significa levar objetos e convertê -los em qualquer formato para que esses dados possam ser usados para outros propósitos mais tarde, enquanto a deserialização de dados significa o oposto disso. A desserialização está descompactando esses dados serializados para o uso de aplicativos. A desertalização insegura significa tempear os dados que foram serializados pouco antes que isso esteja prestes a ser descompactado ou desserializado. A desertalização insegura leva à execução do código remoto e é usado para executar outras tarefas para fins maliciosos, como escalada de privilégios, ataques de injeção, ataques de reprodução, etc. Existem algumas ferramentas disponíveis para descobrir esses tipos de falhas, mas a assistência humana é necessária frequentemente para validar o problema. Explorar a deseralização é um pouco difícil, pois as façanhas não funcionam sem algumas mudanças manuais.
Quando o aplicativo desaperializa objetos maliciosos fornecidos pela entidade de ataque. Isso pode levar a dois tipos de ataques eu.E ataques relacionados à estrutura de dados e objetos nos quais o invasor modifica a lógica do aplicativo ou executa o código remoto e os ataques típicos de adulteração de dados nos quais as estruturas de dados existentes são usadas com conteúdo modificado, por exemplo, ataques relacionados ao controle de acesso. A serialização pode ser usada na comunicação do processo remoto (RPC) ou em uma comunicação entre processos (IPC), cache de dados, serviços da web, servidor de cache de bancos de dados, sistemas de arquivos, tokens de autenticação da API, cookies html, parâmetros de formulário HTML, etc. Os ataques de deserialização podem ser atenuados por não usar objetos serializados de fontes não confiáveis, implementando verificações de integridade, isolando o código em execução em um ambiente de baixo privilégio, monitorando as conexões de rede de entrada e saída de servidores que serializam frequentemente.
Usando componentes com vulnerabilidades conhecidas:
Componentes diferentes, como bibliotecas, estruturas e módulos de software, são usados pela maioria dos desenvolvedores no aplicativo da web. Essas bibliotecas ajudam o desenvolvedor a evitar trabalhos desnecessários e fornecer a funcionalidade necessária. Os atacantes procuram falhas e vulnerabilidades nesses componentes para coordenar um ataque. No caso de encontrar uma brecha de segurança em um componente pode fazer todos os sites usando o mesmo componente, vulnerável. As façanhas dessas vulnerabilidades já estão disponíveis enquanto escreve uma exploração personalizada do zero exige muito esforço. Esta é uma questão muito comum e generalizada, o uso de grandes quantidades de componentes no desenvolvimento de um aplicativo da web pode levar a nem mesmo conhecer e entender todos os componentes usados, corrigir e atualizar todos os componentes é uma longa viagem.
Um aplicativo é vulnerável se o desenvolvedor não souber a versão de um componente usado, o software está desatualizado i.e o sistema operacional, DBMS, execução de software, ambientes de tempo de execução e bibliotecas, a varredura de vulnerabilidades não é feita regularmente, a compatibilidade do software corrigida não é testada pelos desenvolvedores. Pode ser impedido pela remoção de dependências, arquivos, documentação e bibliotecas não utilizados, verificando a versão dos componentes do cliente e do servidor regularmente, obtendo componentes e bibliotecas de fontes seguras oficiais e confiáveis, monitorando as bibliotecas e componentes não patches Para atualizar e corrigir componentes vulneráveis regularmente.
Essas vulnerabilidades levam a pequenos impactos, mas também podem levar à comprometimento do servidor e do sistema. Muitas grandes violações se basearam em vulnerabilidades conhecidas dos componentes. O uso de componentes vulneráveis mina as defesas do aplicativo e pode ser um ponto de partida para um grande ataque.
Montagem e monitoramento insuficientes:
A maioria dos sistemas não toma medidas e etapas suficientes para detectar violações de dados. O tempo médio de resposta de um incidente é 200 dias após o que aconteceu, é muito tempo para fazer todas as coisas desagradáveis para uma entidade atacante. A extração e o monitoramento insuficientes permitem ao invasor atacar ainda mais o sistema, manter sua retenção no sistema, adulterar, reter e extrair dados de acordo com a necessidade. Os atacantes usam a falta de monitoramento e resposta a seu favor para atacar o aplicativo da web.
A extração e o monitoramento insuficientes ocorrem a qualquer momento eu.e registros de aplicativos que não estão sendo monitorados quanto a atividades incomuns, eventos auditáveis como tentativas de login com falha e altos valores de transação não são devidamente registrados, avisos e erros geram mensagens de erro pouco claras, sem alerta de gatilho no caso de pentesting usando ferramentas de DAST automatizadas, sendo incapazes de detectar ou alerta ataques ativos rapidamente, etc. Isso pode ser mitigado, garantindo que todas as falhas de login, controle de acesso e validação de entrada do lado do servidor possam ser registradas para identificar uma conta de usuário maliciosa e mantida por um tempo suficiente para uma investigação forense atrasada, garantindo que os logs gerados estejam em um formato Compatível com soluções centralizadas de gerenciamento de logs, garantindo verificações de integridade em transações de alto valor, estabelecendo um sistema para alertas oportunos de atividades suspeitas, etc.
A maioria dos ataques bem -sucedidos começa com a verificação e a sondagem de vulnerabilidades em um sistema, permitindo que essas investigações de vulnerabilidade podem resultar em comprometer todo o sistema.
Conclusão:
As vulnerabilidades de segurança em um aplicativo da web afetam todas as entidades relacionadas a esse aplicativo. Essas vulnerabilidades devem ser resolvidas para fornecer um ambiente seguro para os usuários. Os atacantes podem usar essas vulnerabilidades para comprometer um sistema, se apossar e escalar privilégios. O impacto de um aplicativo da Web comprometido pode ser visualizado a partir de credenciais roubadas de cartão de crédito e roubo de identidade para o vazamento de informações altamente confidenciais etc. Dependendo das necessidades e vetores de ataque de entidades maliciosas.