10 vulnerabilidades de segurança da Web mais comuns

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 explorabilidade, 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 de navegador da web e menor sendo programação e ferramentas avançadas.
  • Detectabilidade - Quão fácil é detectar a ameaça? Maior sendo a informação exibida em URL, Formulário ou Mensagem de Erro e menor sendo o código fonte.
  • Impacto ou Dano –Quanto dano será causado se a vulnerabilidade de segurança for exposta ou atacada? O mais alto é uma falha completa do sistema e o mais baixo é nada.

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

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

Injeção de SQL

Injeção de SQL

Descrição

A injeção é uma vulnerabilidade de segurança que permite que um invasor altere o back-end SQL declarações 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 aplicação 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 no 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:

Fazer 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 pass123

Consulta SQL criada e enviada ao Interpretador conforme abaixo

SELECT * FROM Usuários WHERE Nome_usuário = sjones AND Senha = 1=1′ ou pass123;

Recomendações

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

Script entre sites

Descrição

Cross Site Scripting também é conhecido como XSS.

As vulnerabilidades XSS têm como alvo scripts incorporados em uma página que são executados no lado do cliente, ou seja, no navegador do usuário, e não no lado do servidor. Essas falhas podem ocorrer quando o aplicativo pega dados não confiáveis ​​e os envia para o navegador da web sem a devida validação.

Os invasores podem usar XSS para executar scripts maliciosos nos usuários, neste caso, nos navegadores das vítimas. Como o navegador não pode saber se o script é confiável ou não, o script será executado e o invasor poderá 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 scripts no navegador da vítima.

Implicação:

  • Fazendo uso dessa vulnerabilidade de segurança, um invasor pode injetar scripts no aplicativo, roubar cookies de sessão, desfigurar sites e 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 mensagem box será exibido se o site for vulnerável ao XSS.

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

2. http://demo.testfire.net/search.aspx?txtSearch <iframe> http://google.com largura = 500 altura 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 ao executar 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ões

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 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 que usa um computador público (Cyber ​​Café), os cookies do site vulnerável ficam no sistema e ficam expostos a um invasor. Um invasor usa o mesmo computador público depois de algum tempo, os dados confidenciais são comprometidos.

Da mesma forma, um usuário que utiliza um computador público, em vez de fazer logoff, fecha o navegador abruptamente. Um invasor utiliza o mesmo sistema, ao navegar 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

  • IDs de sessão expostos em URL podem levar a ataques de fixação de sessão.
  • Os IDs de sessão são iguais antes e depois do logout e do login.
  • Os tempos limite da sessão não foram implementados corretamente.
  • O aplicativo está atribuindo o mesmo 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, o 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 à reescrita de URL, colocando IDs de sessão na URL:http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Venda de ingressos para Maldivas)Um usuário autenticado do site deseja avisar seus amigos sobre a venda e envia um e-mailmail entre. Os amigos recebem o ID da sessão e podem ser usados ​​para fazer modificações não autorizadas ou usar indevidamente os dados do cartão de crédito salvos.tails.
  2. Um aplicativo é vulnerável ao XSS, pelo qual um invasor pode acessar o ID da sessão e ser usado para sequestrar a sessão.
  3. Applications timeouts are not set properly. The user uses a public computer and closes the browser instead of logging off and walks away. The attacker uses the same browser some time later, and the session is authenticated.

Recomendações

  1. Todos os requisitos de autenticação e gerenciamento de sessão devem ser definidos conforme OWASP Padrão de verificação de segurança de aplicativos.
  2. Nunca exponha quaisquer credenciais em URLs ou logs.
  3. Também devem ser feitos grandes esforços 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 uma URL ou um parâmetro FORM. O invasor pode usar essas informações para acessar outros objetos e criar um ataque futuro para acessar dados não autorizados.

Implicação

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

Objetos Vulneráveis

  • Na URL.

Exemplos:

Alterando “userid” no seguintewing O URL pode fazer com que um invasor visualize as informações de outro usuário.

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

Um invasor pode visualizar 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 objetos em URLs.
  3. Verifique a autorização para todos os objetos de referência.

Falsificação de solicitação entre sites

Descrição

Cross Site Request Forgery é uma solicitação forjada proveniente de cross site.

O ataque CSRF é um ataque que ocorre quando um site malicioso, email, ou programa faz com que o navegador do usuário execute uma ação indesejada em um site confiável para o qual o usuário está atualmente autenticado.

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 uma aplicação web vulnerável.

Um link será enviado pelo invasor à vítima quando o usuário clicar na URL ao estar 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 no site de um banco usando credenciais válidas. Ele recebe mail de um invasor dizendo “Clique aqui para doar US$ 1 para a causa”.

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

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

O invasor captura essa solicitação e cria a solicitação abaixo e a incorpora em um botão que diz “Eu apoio a causa”.

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

Como a sessão é autenticada e a solicitação vem do site do banco, o servidor transferiria US$ 1000 para o invasor.

Recomendação

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

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 web, servidor de banco de dados e plataforma. Se estes estiverem configurados corretamente, um invasor poderá 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 de formulário
  • Campos de entrada

Exemplos

  1. O console administrativo 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 diretórios para encontrar qualquer arquivo.

Recomendações

  1. Uma aplicação forte archiestrutura que proporciona boa separação e segurança entre os componentes.
  2. Altere nomes de usuário e senhas padrão.
  3. Desative listagens de diretórios 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 com segurança.

As credenciais do usuário, informações de perfil, dados de saúdetails, informações de cartão de crédito, etc. estão incluídas nas informações de dados confidenciais de um site.

Esses dados serão armazenados no banco de dados do aplicativo. Quando esses dados são armazenados de forma inadequada, sem uso de criptografia ou hashing*, ficarão 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 utilizar esta vulnerabilidade, um invasor pode roubar e modificar esses dados fracamente protegidos para realizar roubo de identidade, fraude de cartão de crédito ou outros crimes.

Objetos vulneráveis

  • Banco de dados de aplicativos.

Exemplos

Em um dos aplicativos bancários, o banco de dados de senhas 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 submetidos à força bruta rapidamente, 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 padrão fortes e 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 em backup 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 das aplicações, as páginas, locais e recursos privilegiados não são apresentados aos usuários privilegiados.

Por meio de uma suposição inteligente, um invasor pode acessar páginas privilegiadas. Um invasor pode acessar páginas confidenciais, invocar funções e visualizar informações confidenciais.

Implicação

  • Fazendo uso desta vulnerabilidade, o invasor 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 anexar uma função ao URL.

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

Recomendações

  1. Implemente verificações fortes de controle de acesso.
  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

Lida com a troca de informações entre o usuário (cliente) e o servidor (aplicação). Os aplicativos frequentemente transmitem informações confidenciais, como autenticaçãotails, 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 uma aplicação web e/ou roubar informações confidenciais.

Implicação

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

Objetos vulneráveis

  • Dados enviados pela rede.

Recomendações

  1. Habilite o HTTP seguro e imponha a transferência de credenciais somente por HTTPS.
  2. Certifique-se de que seu certificado seja válido e não tenha expirado.

Exemplos:

1. Em um aplicativo que não usa SSL, o invasor simplesmente monitorará o tráfego de rede e observará um cookie de sessão da 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 alguns métodos para redirecionar e encaminhar usuários para outras páginas para uma finalidade pretendida.

Se não houver validação adequada ao redirecionar 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 uma URL que contém uma URL genuína anexada a uma URL maliciosa codificada. Um usuário, apenas vendo a parte genuína do URL enviado pelo invasor, pode navegar por ele 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.