Falhas de segurança no TabNews · lengo

Oi, olá! Esse é meu segundo artigo aqui no TabNews. Eu sinceramente gostaria de dizer que estou gostando muito da forma em que o site está crescendo e sempre melhorando, graças ao Filipinho e a turma :) O artigo de hoje vai ser sobre falhas de segurança que achei no TabNews.

Gostaria de reforçar que o intuito desse artigo não é promover ataques de segurança ou algo do tipo, mas sim conscientizar e educar pessoas em relação a segurança da informação e melhorar o TabNews em si, e qualquer coisa, posso remover esse post se necessário ou migrar para alguma issue no GitHub.

A ideia

Eu estava scrollando pelo YouTube e me deparei com uma postagem do Filipe sobre um ataque DDOS controlado que o TabNews sofreu e aguentou numa boa.

Foi ai que tive a ideia: "E se eu testasse a segurança do TabNews usando algum algoritmo automátizado para detectar falhas?" Foi ai que resolvi fazer alguns testes usando o Acunetix, apenas com o intuito educacional e informacional, como disse anteriormente.

O que é o Acunetix?

Acunetix é um dos melhores scanners de segurança do mercado e que pode detectar mais de 7000 tipos diferentes de falhas de segurança que estão catalogadas, usado para detectar falhas por empresas como: AWS, NASA, American Express e até a Força Aérea dos EUA.

O Acunetix separa as falhas em 4 niveis de categorias, sendo elas:

Nivél 0 - Falhas informativas
Nível 1 - Falhas leves
Nível 2 - Falhas medianas
Nível 3 - Falhas graves.

Todas as falhas são listadas com a descrição da falha encontrada, como explorar a falha, o quão grave ela é e como arrumar ela. O que vai ser bem útil para os nossos testes e nos dar algumas ideias.

Testando a segurança do TabNews

O teste que fiz levou cerca de 3 horas e 19 minutos para concluir, foram realizados 68.990 requests nesse meio tempo e o Acunetix indentificou cerca de 8 falhas de segurança no TabNews, sendo elas: 5 falhas informativas, 2 falhas leves e 1 falha mediana.

Então vamos começar por partes:

Falhas informativas

Falhas informativas podem não ser classsificadas como vulnerabilidades em si, mas são falhas que caso o invasor saiba, ele pode usar elas para criar um ataque com mais precisão.

Vamos ver algumas dessas falhas achadas no TabNews:

Entrada do tipo de senha com auto-preenchimento habilitado

Descrição:

Quando um novo nome e senha é inserido em um formulário e o formulário é enviado, o navegador pergunta se a senha deve ser salva. Depois disso, quando o formulário é exibido, o nome e a senha são preenchidos automaticamente ou são preenchidos à medida que o nome é inserido. Um invasor com acesso local poderia obter a senha do texto claro do cache do navegador.

O impacto dessa vulnerabilidade:

Possível divulgação de informações confidenciais

Como corrigir essa vulnerabilidade:

O auto-preenchimento de senhas pode ser desativado facilmente.
Para desativar o preenchimento automático, é possível usar um código semelhante a:

<INPUT TYPE="password" AUTOCOMPLETE="off">

Minha experiência quanto a isso:

Não pretendo ficar dando relatos pessoais sobre as falhas, mas sobre essa falha em específico, lembro que ano passado criei um malware em Python para uso educacional que explorava a captura de dados do navegador da vítima, posso confirmar que realmente é possível capturar e decodificar facilmente as informações de acesso a contas de sites do navegador e posso até trazer isso em algum artigo futuro com um intuito educacional, é claro.

Referrer Policy Inseguro

Descrição:

O Referrer Policy controla o comportamento do cabeçalho do Remetente, o que indica a origem ou url da página web de onde a solicitação foi feita. O TabNews usa a configuração insegura de Referrer Policy que, segundo o Acunetix, pode vazar informações do usuário para sites de terceiros.

O impacto dessa vulnerabilidade:

Em algumas situações, um invasor pode usar isso para vazar dados privados de um usuário.

Como corrigir essa vulnerabilidade:

Essa falha pode ser corrigida apenas definindo o cabeçalho referrer-policy para "strict-origin-when-cross-origin" ou um valor mais rigoroso.

Refências:

Referrer-Policy

Práticas recomendadas de HTTP Strict Transport Security (HSTS)

Descrição:

HTTP Strict Transport Security (HSTS) informa a um navegador que um site só pode ser acessado usando HTTPS. O TabNews não implementa as práticas do HTTP Strict Transport Security (HSTS).

O impacto dessa vulnerabilidade:

O HSTS pode ser usado para prevenir e/ou mitigar alguns tipos de ataques man-in-the-middle (MitM)

Como corrigir essa vulnerabilidade:

O Acunetix recomenda o TabNews a implementar as melhores práticas do HSTS (HTTP Strict Transport Security). Para saber mais detalhadamente disso, você ver nas referências desse tópico.

Mais sobre essa vulnerabilidade:

O Gabriel Pato fez um vídeo chamado "Esse site pode INVADIR o seu roteador", que fala sobre um ataque voltado a sites de bancos brasileiros e que usava também essa mesma vulnerabilidade que os bancos não tinham corrigido. Você pode acessar o vídeo e ver mais sobre isso aqui.

Refências:

Content Security Policy (CSP) não implementado

Descrição:

Content Security Policy (CSP) é uma camada adicional de segurança que ajuda a detectar e mitigar certos tipos de ataques, incluindo Cross Site Scripting (XSS) e ataques de data injection.

O impacto dessa vulnerabilidade:

O CSP pode ser usado para prevenir e/ou mitigar ataques que envolvem injeção de conteúdo ou de código, como ataques de XSS, ataques que requerem a incorporação de um recurso malicioso, ataques que envolvem uso malicioso de iframes, como ataques de clickjacking, entre outros.

Como corrigir essa vulnerabilidade:

Para implementar o CSP, você deve definir listas de origens permitidas para todos os tipos de recursos que o TabNews utiliza. Por exemplo, se você tiver um site simples que precise carregar scripts, folhas de estilo e imagens hospedadas localmente, bem como na biblioteca jQuery de seu CDN, o cabeçalho CSP pode se parecer com o seguinte:

Content-Security-Policy:
    default-src 'self';
    script-src 'self' https://code.jquery.com;

Refências:

Header access-control-allow-Origin com valor curinga (*)

Descrição:

O Cross-origin resource sharing (CORS) é um mecanismo que permite que recursos restritos (por exemplo fontes) em uma página da Web sejam solicitados de outro domínio fora do domínio do qual o recurso se originou. O header Access-Control-Allow-Origin indica se um recurso pode ser compartilhado com base no valor do header de solicitação de Origem, "*" ou "null" na resposta.

Se um site responder com Access-Control-Allow-Origin: "*" o recurso solicitado permite compartilhar com todas as origens. Portanto, qualquer site pode fazer solicitações XHR (XML HTTP Request) no site e acessar as respostas.

As páginas do TabNews afetados por isso, são:

O impacto dessa vulnerabilidade:

Qualquer outro site pode fazer solicitações XHR para o TabNews e acessar as respostas.

Como corrigir essa vulnerabilidade:

Verifique se o Access-Control-Allow-Origin: "*" é apropriado para o recurso/resposta nas páginas.

Refências:

Falhas leves:

As falhas leves são falhas geralmente com escopo limitado, mas, com um acesso especializado, interação do usuário ou circunstâncias que estão além do controle do invasor podem ser usados para que um ataque seja bem sucedido.

Vamos ver algumas dessas falhas achadas no TabNews:

Páginas sensíveis que podem ser armazenadas em cache

Descrição:

Uma ou mais páginas contêm possíveis informações confidenciais (por exemplo, um parâmetro de senha) e podem ser potencialmente armazenadas em cache. Mesmo em canais SSL seguros, dados confidenciais podem ser armazenados por proxies intermediários e terminadores SSL. Para evitar isso, um cabeçalho cache-control deve ser especificado.

As páginas do TabNews que podem sofrer com isso são páginas de login e cadastro, como:

O impacto dessa vulnerabilidade:

Possível divulgação de informações confidenciais.

Como corrigir essa vulnerabilidade:

É possível evitar o cache adicionando "Cache Control: No-store" e "Pragma: no-cache" ao cabeçalho de resposta HTTP.

Header Clickjacking: X-Frame-Options

Descrição:

Clickjacking (User Interface redress attack, UI redress attack, UI redressing) é uma técnica maliciosa de enganar um usuário para clicar em algo diferente do que o usuário percebe que está clicando, revelando assim informações confidenciais ou assumindo o controle de seu computador ao clicar em páginas da Web aparentemente inócuas.

As páginas do TabNews não retornam um header X-Frame-Options com o valor DENY ou SAMEORIGIN, o que significa que ele pode estar em risco de um ataque de clickjacking, segundo o Acunetix. O header de resposta HTTP X-Frame-Options pode ser usado para indicar se um navegador deve ou não ser autorizado a renderizar uma página dentro de um quadro ou iframe. Os sites podem usar isso para evitar ataques de clickjacking, garantindo que seu conteúdo não seja incorporado em sites não confiáveis.

O impacto dessa vulnerabilidade:

O impacto depende da aplicação web afetada.

Como corrigir essa vulnerabilidade:

É possível corrigir isso, configurando o servidor web para incluir um cabeçalho X-Frame-Options e um header CSP com frame-ancestors directive. Para saber mais sobre esses headers, veja o tópico de referências.

Referências:

Falhas médias

Falhas médias são falhas que podem comprometer parcialmente a confidencialidade, integridade ou disponibilidade de um sistema de destino. Elas podem ser usadas em conjunto com outras vulnerabilidades para escalar um ataque.

Vamos ver algumas dessas falhas achadas no TabNews:

Campo de senha enviado usando o método GET

Descrição:

Essas páginas contêm um formulário com um campo de senha. O atributo do método do formulário está definido como GET. Essa configuração pode levar a que os dados do usuário sejam enviados usando o método GET, fazendo com que o conteúdo do campo de senha apareça na URL. Os URLs podem ser registrados ou vazados através do header do Remetente.

As páginas de cadastro e de login do TabNews que contém essa falha, segundo o Acunetix:

O impacto dessa vulnerabilidade:

Possível divulgação de informações confidenciais.

Como corrigir essa vulnerabilidade:

O atributo do método do formulário HTML deve ser definido como POST em vez de GET.

Falhas graves

As falhas graves são falhas que podem comprometer totalmente a confidencialidade, integridade ou disponibilidade de um sistema de destino. Muito provavelmente vão permitir escalada de ataque para outros sistemas na rede interna da aplicação vulnerável.

Nesse caso, o TabNews não possui falhas graves, segundo o Acunetix, o que é muito bom!

E é isso! Seria legal discutir essas pequenas falhas aqui ou no repositório do GitHub, isso deixaria o TabNews mais seguro contra ataques e para o TabNews continuar com o objetivo de construir um pedaço de internet mais massa :D