10 vulnerabilidades de segurança da web mais comuns

Índice:

Anonim

OWASP ou Open Web Security Project é uma organização de caridade sem fins lucrativos focada em melhorar a segurança de software e aplicativos da web.

A organização publica uma lista das principais vulnerabilidades de segurança da web com base nos dados de várias organizações de segurança.

As vulnerabilidades de segurança da web são priorizadas dependendo da capacidade de exploração, detectabilidade e impacto no software.

  • Explorabilidade -

    O que é necessário para explorar a vulnerabilidade de segurança? Maior capacidade de exploração quando o ataque precisa apenas do navegador da web e a menor sendo programação e ferramentas avançadas.

  • Detectabilidade -

    É fácil detectar a ameaça? A mais alta é a informação exibida no URL, formulário ou mensagem de erro e a mais baixa é o código-fonte.

  • Impacto ou dano -

    Quanto dano será causado se a vulnerabilidade de segurança for exposta ou atacada? A mais alta sendo uma falha completa do sistema e a mais baixa sendo nada.

O principal objetivo do OWASP Top 10 é educar os desenvolvedores, designers, gerentes, arquitetos e organizações sobre as vulnerabilidades de segurança mais importantes.

As 10 principais vulnerabilidades de segurança de acordo com as 10 principais OWASP são:

  • Injeção SQL
  • Cross Site Scripting
  • Autenticação quebrada e gerenciamento de sessão
  • Referências inseguras de objetos diretos
  • Cross Site Request Forgery
  • Configuração incorreta de segurança
  • Armazenamento criptográfico inseguro
  • Falha ao restringir o acesso ao URL
  • Proteção de camada de transporte insuficiente
  • Redirecionamentos e encaminhamentos não validados

Injeção SQL

Descrição

A injeção é uma vulnerabilidade de segurança que permite que um invasor altere as instruções SQL de back-end manipulando os dados fornecidos pelo usuário.

A injeção ocorre quando a entrada do usuário é enviada a um intérprete como parte de um comando ou consulta e induz o intérprete a executar comandos não intencionais e dá acesso a dados não autorizados.

O comando SQL que, quando executado por um aplicativo da web, também pode expor o banco de dados back-end.

Implicação

  • Um invasor pode injetar conteúdo malicioso nos campos vulneráveis.
  • Dados confidenciais como nomes de usuário, senhas, etc. podem ser lidos do banco de dados.
  • Os dados do banco de dados podem ser modificados (Inserir / Atualizar / Excluir).
  • As operações de administração podem ser executadas no banco de dados

Objetos Vulneráveis

  • Campos de entrada
  • URLs interagindo com o banco de dados.

Exemplos:

  • Injeção de SQL na página de login

Login em um aplicativo sem ter credenciais válidas.

UserName válido está disponível e a senha não está disponível.

URL de teste: http://demo.testfire.net/default.aspx

Nome de usuário: sjones

Senha: 1 = 1 'ou senha123

Consulta SQL criada e enviada ao Interpreter conforme abaixo

SELECT * FROM Users WHERE User_Name = sjones AND Password = 1 = 1 'ou pass123;

Recomendações

  1. Lista branca dos campos de entrada
  2. Evite exibir mensagens de erro detalhadas que sejam úteis para um invasor.

Cross Site Scripting

Descrição

Cross Site Scripting também é conhecido como XSS.

As vulnerabilidades de XSS visam scripts embutidos em uma página que são executados no lado do cliente, ou seja, no navegador do usuário, em vez de no lado do servidor. Essas falhas podem ocorrer quando o aplicativo pega dados não confiáveis ​​e os envia ao navegador da web sem a validação adequada.

Os invasores podem usar XSS para executar scripts maliciosos nos navegadores dos usuários, neste caso. Como o navegador não pode saber se o script é confiável ou não, o script será executado e o invasor pode sequestrar cookies de sessão, desfigurar sites ou redirecionar o usuário para sites indesejados e maliciosos.

XSS é um ataque que permite ao invasor executar os scripts no navegador da vítima.

Implicação:

  • Fazendo uso desta vulnerabilidade de segurança, um invasor pode injetar scripts no aplicativo, pode roubar cookies de sessão, desfigurar sites e pode executar malware nas máquinas da vítima.

Objetos Vulneráveis

  • Campos de entrada
  • URLs

Exemplos

1. http://www.vulnerablesite.com/home?" < script > alert (" xss") script >

O script acima, quando executado em um navegador, uma caixa de mensagem será exibida se o site for vulnerável a XSS.

O ataque mais sério pode ser feito se o invasor quiser exibir ou armazenar o cookie da sessão.

2. http://demo.testfire.net/search.aspx?txtSearch > http://google.com width = 500 height 500>

O script acima quando executado, o navegador carregará um quadro invisível apontando para http://google.com .

O ataque pode se tornar sério executando um script malicioso no navegador.

Recomendações

  1. Campos de entrada da Lista Branca
  2. Codificação de entrada e saída

Autenticação quebrada e gerenciamento de sessão

Descrição

Os sites geralmente criam um cookie de sessão e um ID de sessão para cada sessão válida, e esses cookies contêm dados confidenciais como nome de usuário, senha, etc. Quando a sessão é encerrada por logout ou o navegador é fechado abruptamente, esses cookies devem ser invalidados, ou seja, para cada sessão deve haver um novo cookie.

Se os cookies não forem invalidados, os dados sensíveis existirão no sistema. Por exemplo, um usuário usando um computador público (Cyber ​​Cafe), os cookies do site vulnerável ficam no sistema e são expostos a um invasor. Um invasor usa o mesmo computador público depois de algum tempo, os dados confidenciais ficam comprometidos.

Da mesma forma, um usuário que usa um computador público, em vez de fazer logoff, fecha o navegador abruptamente. Um atacante usa o mesmo sistema, quando navega no mesmo site vulnerável, a sessão anterior da vítima será aberta. O invasor pode fazer o que quiser, desde roubar informações de perfil, informações de cartão de crédito etc.

Uma verificação deve ser feita para descobrir a força da autenticação e do gerenciamento de sessão. Chaves, tokens de sessão e cookies devem ser implementados corretamente, sem comprometer as senhas.

Objetos Vulneráveis

  • Os IDs de sessão expostos no URL podem levar a um ataque de fixação de sessão.
  • Os IDs de sessão são iguais antes e depois do logout e login.
  • Os tempos limite de sessão não foram implementados corretamente.
  • O aplicativo está atribuindo a mesma ID de sessão para cada nova sessão.
  • As partes autenticadas do aplicativo são protegidas por SSL e as senhas são armazenadas em formato hash ou criptografado.
  • A sessão pode ser reutilizada por um usuário com poucos privilégios.

Implicação

  • Fazendo uso desta vulnerabilidade, um invasor pode sequestrar uma sessão, obter acesso não autorizado ao sistema que permite a divulgação e modificação de informações não autorizadas.
  • As sessões podem ser roubadas usando cookies roubados ou sessões usando XSS.

Exemplos

  1. O aplicativo de reserva de companhia aérea oferece suporte à regravação de URL, colocando IDs de sessão no URL:

    http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Venda de ingressos para as Maldivas)

    Um usuário autenticado do site deseja que seus amigos saibam sobre a venda e envia um e-mail. Os amigos recebem o ID da sessão e podem ser usados ​​para fazer modificações não autorizadas ou usar indevidamente os detalhes do cartão de crédito salvos.

  2. Um aplicativo é vulnerável a XSS, pelo qual um invasor pode acessar o ID da sessão e pode ser usado para sequestrar a sessão.
  3. Os tempos limite dos aplicativos não estão definidos corretamente. O usuário usa um computador público e fecha o navegador em vez de fazer logoff e vai embora. O invasor usa o mesmo navegador algum tempo depois e a sessão é autenticada.

Recomendações

  1. Todos os requisitos de autenticação e gerenciamento de sessão devem ser definidos de acordo com o OWASP Application Security Verification Standard.
  2. Nunca exponha quaisquer credenciais em URLs ou Logs.
  3. Fortes esforços também devem ser feitos para evitar falhas de XSS que podem ser usadas para roubar IDs de sessão.

Referências inseguras de objetos diretos

Descrição

Ocorre quando um desenvolvedor expõe uma referência a um objeto de implementação interno, como um arquivo, diretório ou chave de banco de dados como em URL ou como um parâmetro FORM. O invasor pode usar essas informações para acessar outros objetos e pode criar um ataque futuro para acessar os dados não autorizados.

Implicação

  • Usando esta vulnerabilidade, um invasor pode obter acesso a objetos internos não autorizados, pode modificar dados ou comprometer o aplicativo.

Objetos Vulneráveis

  • No URL.

Exemplos:

Alterar o "ID do usuário" no seguinte URL pode fazer um invasor visualizar as informações de outro usuário.

http://www.vulnerablesite.com/userid=123 Modificado para http://www.vulnerablesite.com/userid=124

Um invasor pode ver as informações de outras pessoas alterando o valor do ID do usuário.

Recomendações:

  1. Implementar verificações de controle de acesso.
  2. Evite expor referências de objeto em URLs.
  3. Verifique a autorização para todos os objetos de referência.

Cross Site Request Forgery

Descrição

Cross Site Request Forgery é uma solicitação forjada proveniente do site cruzado.

O ataque CSRF é um ataque que ocorre quando um site, e-mail ou programa mal-intencionado faz com que o navegador de um usuário execute uma ação indesejada em um site confiável para o qual o usuário está autenticado no momento.

Um ataque CSRF força o navegador da vítima conectada a enviar uma solicitação HTTP forjada, incluindo o cookie de sessão da vítima e qualquer outra informação de autenticação incluída automaticamente, para um aplicativo da Web vulnerável.

Um link será enviado pelo atacante para a vítima quando o usuário clicar na URL quando estiver logado no site original, os dados serão roubados do site.

Implicação

  • Usar esta vulnerabilidade como um invasor pode alterar as informações do perfil do usuário, alterar o status, criar um novo usuário em nome do administrador, etc.

Objetos Vulneráveis

  • Página de perfil de usuário
  • Formulários de conta de usuário
  • Página de transação comercial

Exemplos

A vítima está logada em um site de banco usando credenciais válidas. Ele recebe uma correspondência de um atacante dizendo "Clique aqui para doar $ 1 para a causa."

Quando a vítima clica nele, uma solicitação válida é criada para doar $ 1 para uma conta específica.

http://www.vulnerablebank.com/transfer.do?account=cause&amount=1

O invasor captura essa solicitação, cria a solicitação abaixo e incorpora um botão que diz "Apoio a causa".

http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000

Como a sessão é autenticada e a solicitação está vindo do site do banco, o servidor transfere $ 1000 dólares para o invasor.

Recomendação

  1. Obrigue a presença do usuário ao executar ações confidenciais.
  2. Implemente mecanismos como CAPTCHA, Reautenticação e Tokens de Solicitação Única.

Configuração incorreta de segurança

Descrição

A configuração de segurança deve ser definida e implementada para o aplicativo, estruturas, servidor de aplicativos, servidor da web, servidor de banco de dados e plataforma. Se eles estiverem configurados corretamente, um invasor pode ter acesso não autorizado a dados ou funcionalidades confidenciais.

Às vezes, essas falhas resultam no comprometimento total do sistema. Manter o software atualizado também é uma boa segurança.

Implicação

  • Fazendo uso dessa vulnerabilidade, o invasor pode enumerar a tecnologia subjacente e as informações da versão do servidor de aplicativos, informações do banco de dados e obter informações sobre o aplicativo para montar mais alguns ataques.

Objetos vulneráveis

  • URL
  • Campos do Formulário
  • Campos de entrada

Exemplos

  1. O console de administração do servidor de aplicativos é instalado automaticamente e não removido. As contas padrão não são alteradas. O invasor pode fazer login com senhas padrão e obter acesso não autorizado.
  2. A listagem de diretórios não está desabilitada em seu servidor. O invasor descobre e pode simplesmente listar os diretórios para localizar qualquer arquivo.

Recomendações

  1. Uma arquitetura de aplicativo forte que fornece boa separação e segurança entre os componentes.
  2. Altere nomes de usuário e senhas padrão.
  3. Desative as listagens de diretório e implemente verificações de controle de acesso.

Armazenamento criptográfico inseguro

Descrição

O armazenamento criptográfico inseguro é uma vulnerabilidade comum que existe quando os dados confidenciais não são armazenados de forma segura.

As credenciais do usuário, informações de perfil, detalhes de saúde, informações de cartão de crédito, etc. vêm sob informações de dados confidenciais em um site.

Esses dados serão armazenados no banco de dados do aplicativo. Quando esses dados são armazenados incorretamente por não usar criptografia ou hashing *, eles ficam vulneráveis ​​aos invasores.

(* Hashing é a transformação dos caracteres da string em strings mais curtas de comprimento fixo ou uma chave. Para descriptografar a string, o algoritmo usado para formar a chave deve estar disponível)

Implicação

  • Ao usar essa vulnerabilidade, um invasor pode roubar, modificar esses dados fracamente protegidos para conduzir roubo de identidade, fraude de cartão de crédito ou outros crimes.

Objetos vulneráveis

  • Banco de dados do aplicativo.

Exemplos

Em um dos aplicativos bancários, o banco de dados de senha usa hashes * sem sal para armazenar as senhas de todos. Uma falha de injeção de SQL permite que o invasor recupere o arquivo de senha. Todos os hashes sem sal podem ser forçados de forma bruta em nenhum momento, enquanto as senhas com sal levariam milhares de anos.

(* Hashes sem sal - Salt é um dado aleatório anexado aos dados originais. Salt é anexado à senha antes do hash)

Recomendações

  1. Garanta algoritmos de padrão forte apropriados. Não crie algoritmos criptográficos próprios. Use apenas algoritmos públicos aprovados, como AES, criptografia de chave pública RSA e SHA-256, etc.
  2. Certifique-se de que os backups externos sejam criptografados, mas as chaves sejam gerenciadas e armazenadas separadamente.

Falha ao restringir o acesso ao URL

Descrição

Os aplicativos da Web verificam os direitos de acesso à URL antes de renderizar links e botões protegidos. Os aplicativos precisam realizar verificações de controle de acesso semelhantes sempre que essas páginas são acessadas.

Na maioria dos aplicativos, as páginas, locais e recursos privilegiados não são apresentados aos usuários privilegiados.

Por um palpite inteligente, um invasor pode acessar páginas de privilégios. Um invasor pode acessar páginas confidenciais, invocar funções e visualizar informações confidenciais.

Implicação

  • Fazendo uso desta vulnerabilidade, o atacante pode obter acesso a URLs não autorizados, sem fazer login no aplicativo e explorar a vulnerabilidade. Um invasor pode acessar páginas confidenciais, invocar funções e visualizar informações confidenciais.

Objetos vulneráveis:

  • URLs

Exemplos

  1. O invasor percebe que o URL indica a função como "/ user / getaccounts." Ele modifica como "/ admin / getaccounts".
  2. Um invasor pode acrescentar uma função ao URL.

http://www.vulnerablsite.com pode ser modificado como http://www.vulnerablesite.com/admin

Recomendações

  1. Implemente verificações de controle de acesso rigorosas.
  2. As políticas de autenticação e autorização devem ser baseadas em funções.
  3. Restrinja o acesso a URLs indesejados.

Proteção de camada de transporte insuficiente

Descrição

Trata da troca de informações entre o usuário (cliente) e o servidor (aplicação). Os aplicativos freqüentemente transmitem informações confidenciais, como detalhes de autenticação, informações de cartão de crédito e tokens de sessão em uma rede.

Usar algoritmos fracos ou usar certificados expirados ou inválidos ou não usar SSL pode permitir que a comunicação seja exposta a usuários não confiáveis, o que pode comprometer um aplicativo da web e / ou roubar informações confidenciais.

Implicação

  • Fazendo uso dessa vulnerabilidade de segurança da Web, um invasor pode farejar as credenciais legítimas do usuário e obter acesso ao aplicativo.
  • Pode roubar informações do cartão de crédito.

Objetos vulneráveis

  • Dados enviados pela rede.

Recomendações

  1. Ative o HTTP seguro e reforce a transferência de credenciais apenas por HTTPS.
  2. Certifique-se de que seu certificado é válido e não expirou.

Exemplos:

1. Um aplicativo que não usa SSL, um invasor simplesmente monitora o tráfego de rede e observa um cookie de sessão de vítima autenticado. Um invasor pode roubar esse cookie e realizar um ataque man-in-the-middle.

Redirecionamentos e encaminhamentos não validados

Descrição

O aplicativo da web usa poucos métodos para redirecionar e encaminhar usuários para outras páginas para um propósito pretendido.

Se não houver validação adequada durante o redirecionamento para outras páginas, os invasores podem fazer uso disso e redirecionar as vítimas para sites de phishing ou malware, ou usar encaminhamentos para acessar páginas não autorizadas.

Implicação

  • Um invasor pode enviar ao usuário um URL que contém um URL genuíno anexado a um URL malicioso codificado. Um usuário, apenas vendo a parte genuína do URL enviado pelo invasor, pode navegar nele e se tornar uma vítima.

Exemplos

1. http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com

Modificado para

http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com

Recomendações

  1. Simplesmente evite usar redirecionamentos e encaminhamentos no aplicativo. Se usado, não envolva o uso de parâmetros do usuário no cálculo do destino.
  2. Se os parâmetros de destino não puderem ser evitados, certifique-se de que o valor fornecido seja válido e autorizado para o usuário.

Este artigo é uma contribuição de Prasanthi Eati