Introdução

Em cibersegurança, nem todas as vulnerabilidades críticas envolvem payloads complexos ou exploits avançados. Muitas vezes, falhas simples de lógica e controlo de acesso são suficientes para comprometer dados sensíveis. Neste write‑up, descrevo como identifiquei uma falha de autorização numa API REST que permitia a qualquer utilizador autenticado aceder a informações privadas de outros utilizadores.

Contexto da Aplicação

O alvo era uma aplicação web do tipo SaaS que disponibilizava uma API para gestão de perfis de utilizador. Cada utilizador autenticado podia consultar e editar os seus próprios dados através de endpoints protegidos por token JWT.

À primeira vista, a aplicação parecia implementar corretamente a autenticação. No entanto, como é comum em testes de segurança, autenticação não implica necessariamente autorização.

A Descoberta

Durante a análise dos pedidos enviados pela aplicação, foquei‑me num endpoint responsável por devolver os detalhes do perfil do utilizador:

GET /api/users/{userId}


Ao fazer um pedido normal, o {userId} correspondia ao ID da minha própria conta. O servidor devolvia corretamente os meus dados pessoais.

A questão óbvia surgiu:
o servidor valida se o utilizador autenticado tem permissão para aceder ao ID solicitado?

A Exploração

Para testar esta hipótese, intercetei o pedido e alterei manualmente o userId para um valor diferente, pertencente a outro utilizador da plataforma.

O resultado foi imediato: o servidor respondeu com os dados completos do utilizador alvo, incluindo:

Nome completo

Endereço de e‑mail

Informação interna de conta

Não existia qualquer verificação que relacionasse o ID presente no token JWT com o ID solicitado no endpoint.

Impacto

Esta falha permitia a qualquer utilizador autenticado enumerar IDs e recolher dados sensíveis de toda a base de utilizadores. Num cenário real, isto poderia levar a:

Violação de privacidade em larga escala

Preparação de ataques de phishing direcionados

Comprometimento de contas através de engenharia social

A severidade foi classificada como Alta, devido à facilidade de exploração e ao impacto direto nos dados dos utilizadores.

Mitigação Recomendada

A correção passa por implementar controlos de autorização no backend. O servidor deve sempre validar se o utilizador autenticado tem permissão para aceder ao recurso solicitado, ignorando qualquer ID fornecido pelo cliente quando possível.

Uma abordagem segura seria extrair o ID diretamente do token de sessão e usá‑lo como referência única para operações sensíveis.

Conclusão

Este write‑up demonstra como uma falha simples de autorização numa API pode ter consequências sérias. Mais uma vez, fica claro que segurança não depende apenas de autenticação, mas de validações rigorosas no lado do servidor.

Introdução

Em cibersegurança, nem todas as vulnerabilidades críticas envolvem payloads complexos ou exploits avançados. Muitas vezes, falhas simples de lógica e controlo de acesso são suficientes para comprometer dados sensíveis. Neste write‑up, descrevo como identifiquei uma falha de autorização numa API REST que permitia a qualquer utilizador autenticado aceder a informações privadas de outros utilizadores.

Contexto da Aplicação

O alvo era uma aplicação web do tipo SaaS que disponibilizava uma API para gestão de perfis de utilizador. Cada utilizador autenticado podia consultar e editar os seus próprios dados através de endpoints protegidos por token JWT.

À primeira vista, a aplicação parecia implementar corretamente a autenticação. No entanto, como é comum em testes de segurança, autenticação não implica necessariamente autorização.

A Descoberta

Durante a análise dos pedidos enviados pela aplicação, foquei‑me num endpoint responsável por devolver os detalhes do perfil do utilizador:

GET /api/users/{userId}


Ao fazer um pedido normal, o {userId} correspondia ao ID da minha própria conta. O servidor devolvia corretamente os meus dados pessoais.

A questão óbvia surgiu:
o servidor valida se o utilizador autenticado tem permissão para aceder ao ID solicitado?

A Exploração

Para testar esta hipótese, intercetei o pedido e alterei manualmente o userId para um valor diferente, pertencente a outro utilizador da plataforma.

O resultado foi imediato: o servidor respondeu com os dados completos do utilizador alvo, incluindo:

Nome completo

Endereço de e‑mail

Informação interna de conta

Não existia qualquer verificação que relacionasse o ID presente no token JWT com o ID solicitado no endpoint.

Impacto

Esta falha permitia a qualquer utilizador autenticado enumerar IDs e recolher dados sensíveis de toda a base de utilizadores. Num cenário real, isto poderia levar a:

Violação de privacidade em larga escala

Preparação de ataques de phishing direcionados

Comprometimento de contas através de engenharia social

A severidade foi classificada como Alta, devido à facilidade de exploração e ao impacto direto nos dados dos utilizadores.

Mitigação Recomendada

A correção passa por implementar controlos de autorização no backend. O servidor deve sempre validar se o utilizador autenticado tem permissão para aceder ao recurso solicitado, ignorando qualquer ID fornecido pelo cliente quando possível.

Uma abordagem segura seria extrair o ID diretamente do token de sessão e usá‑lo como referência única para operações sensíveis.

Conclusão

Este write‑up demonstra como uma falha simples de autorização numa API pode ter consequências sérias. Mais uma vez, fica claro que segurança não depende apenas de autenticação, mas de validações rigorosas no lado do servidor.