Write-Up: Análise de Segurança e Engenharia Reversa em Aplicação React/Supabase

Neste artigo, documento o processo de análise de segurança e auditoria técnica realizado em uma aplicação web moderna baseada em React (Vite) no frontend e Supabase / Vercel na infraestrutura. O objetivo foi mapear a superfície de ataque exposta e validar os controles de autenticação, autorização e persistência de dados.

1. Reconhecimento Externo e Infraestrutura (Black-Box)

O teste foi iniciado por um reconhecimento externo da aplicação, sem a utilização de credenciais. A análise das respostas HTTP permitiu identificar o seguinte cenário:

• Hospedagem e Backend: Aplicação hospedada na Vercel com backend gerenciado pelo Supabase.

• Criptografia em Trânsito: Redirecionamento forçado de HTTP para HTTPS ativo, com cifras TLS válidas.

• Ausência de Cabeçalhos Defensivos (Hardening): O servidor falha em omitir ou configurar cabeçalhos de segurança cruciais, deixando a aplicação sem as seguintes proteções:

  • Content-Security-Policy (CSP)

  • X-Frame-Options (Proteção contra Clickjacking/carregamento em iframe)

  • X-Content-Type-Options

  • Referrer-Policy

  • Permissions-Policy

2. Análise de Código Fonte Cliente (React/Vite)

Por se tratar de um build em React estruturado via Vite, boa parte da lógica de negócio do frontend estava exposta nos bundles de produção do JavaScript público. A varredura estática nesses arquivos revelou:

• Mapeamento de Endpoints: Identificação das rotas /api/auth/signup, /api/auth/event, /api/auth/admin-create-user e /api/ai.

• Mapeamento de Banco de Dados: Exposição dos nomes de tabelas internas como profiles, authorized_users, generated_contents, term_plans e teacher_schools.

• Vazamento de Metadados: Exposição de informações internas de desenvolvimento no lado do cliente, incluindo metadados de build, repositório Git, hashes de commits e identificadores internos da Vercel.

• Service Worker: O arquivo de service worker expunha caminhos para scripts de teste, páginas de recuperação de ambiente, bundles depreciados e arquivos de diagnóstico, fornecendo mais inteligência sobre a estrutura do banco.

3. Falha de Provisionamento de Recursos

Para testar a superfície autenticada, foi criada uma conta comum de testes sob o nome de Gentoober HCK. Após a validação do e-mail direto pelo Supabase, observou-se uma falha de lógica de negócios no provisionamento:

⚠️ Falha de Escopo: A nova conta comum recebeu, de forma automatizada e sem contrapartida financeira, o plano GOLD, 9.999 créditos e acesso irrestrito a todas as funcionalidades do sistema. Qualquer usuário mal-intencionado poderia automatizar a criação de contas para inflacionar o consumo de recursos computacionais.

4. Quebra de Isolamento: Row Level Security (RLS) no Supabase

O Supabase delega o controle de acesso diretamente ao banco de dados através de políticas de Row Level Security (RLS). Testou-se a eficácia dessas políticas utilizando o token de sessão da conta comum (Gentoober HCK).

Leitura Horizontal Indevida

A conta de teste não possuía nenhum conteúdo próprio associado. Ao remover os filtros de proprietário nas requisições da API, o banco permitiu a leitura horizontal de dados de terceiros:

• Exposição: Foi possível ler os UUIDs, tipos e datas de 45 registros de conteúdos gerados, 3 planejamentos e 2 vínculos de professores.

Escrita e Exclusão Arbitrária (Bypass Completo)

A falha de RLS mostrou-se bidirecional. Foi possível injetar um registro sintético de teste na tabela generated_contents apontando o UUID de outro usuário como proprietário (Retorno HTTP 201). Posteriormente, utilizando a mesma conta comum, foi possível deletar o marcador sintético.

Nota de Segurança: O teste comprovou que um atacante poderia ler, inserir e apagar registros no contexto de qualquer usuário da aplicação. Nenhum dado legítimo foi alterado durante a validação.

5. Atribuição em Massa (Mass Assignment)

Testou-se a capacidade de alterar campos privilegiados do perfil através do token comum.

• Controle Positivo: Tentativas de alterar a role para admin ou definir is_admin como true foram rejeitadas por uma regra severa que valida os e-mails administrativos na origem.

• Controle Negativo (Falha): Campos financeiros e de controle de consumo não possuíam a mesma validação. Foi possível atualizar diretamente os campos credits para 1.000.000 e is_unlimited para true, obtendo recursos infinitos a partir do contexto do cliente.

6. Vazamento de Credenciais de Alta Gravidade (Tomada de Conta)

Ao consultar a tabela authorized_users utilizando o token do usuário comum, a API retornou indevidamente os registros de contas administrativas.

O sistema apresentou uma falha grave de armazenamento de segredos:

• Vulnerabilidade: A tabela expôs o e-mail do administrador, seu papel no sistema e sua access_key armazenada em texto claro (plain text).

• Impacto: Utilizando a chave obtida diretamente no endpoint oficial do Supabase, obteve-se uma sessão válida (HTTP 200), confirmando o comprometimento completo do perfil administrativo (role=admin / is_admin=true).

A validação foi corroborada pela execução bem-sucedida da função RPC restrita get_all_profiles_secure, que antes rejeitava o usuário comum e, sob a nova sessão, retornou o contador exato de 19 perfis cadastrados.

7. Desconexão de Lógica: Fluxo de Senhas

Analisando o comportamento do frontend, detectou-se uma falha de sincronia na arquitetura de autenticação:

• O login da aplicação utiliza o módulo nativo do Supabase (signInWithPassword).

• No entanto, a tela de alteração de senha atualiza exclusivamente o campo access_key na tabela customizada authorized_users.

Consequência: A interface reporta ao usuário que a credencial foi alterada com sucesso, mas a senha antiga mantida pelo módulo de autenticação do Supabase permanece ativa e funcional, inviabilizando a revogação real de acessos comprometidos.

8. Abuso de APIs Públicas e Vetores de Custo

Proxy de Inteligência Artificial Sem Autenticação

O endpoint /api/ai processa as requisições enviadas aos modelos de inteligência artificial. Testes sem o envio de cabeçalhos de autorização (Authorization Token) demonstraram que a API aceita requisições anônimas, retornando HTTP 200 e gerando o conteúdo processado.

• Risco Comercial: Aliado a uma política de CORS permissiva (Access-Control-Allow-Origin: *), qualquer agente externo pode utilizar o endpoint como um proxy gratuito de IA, transferindo todo o custo financeiro do consumo de tokens para o dono da aplicação.

Injeção de Logs de Eventos

O endpoint /api/auth/event aceita o envio de eventos de autenticação (como logins) de forma anônima e sem validação de integridade. Isso viabiliza a inserção em massa de registros falsos, inutilizando logs para auditoria Forense ou tratamento de incidentes.

9. Varredura Automatizada e Falsos Positivos

Uma varredura automatizada de escopo estrito (focada em configurações de TLS e cabeçalhos) confirmou a ausência das defesas de hardening citadas no item 1.

A ferramenta apontou a ausência do cabeçalho HSTS (HTTP Strict Transport Security). Contudo, a validação manual via curl -I comprovou que o cabeçalho estava sendo enviado corretamente pelo servidor da Vercel, caracterizando o alerta da ferramenta como um falso positivo.

Conclusão e Recomendações

A aplicação possui sérias fragilidades estruturais, principalmente na camada de persistência (Supabase) devido à falta de isolamento por RLS, uso de chaves em texto claro e falta de validação em funções de proxy no backend. A correção imediata exige a reestruturação das políticas de banco de dados e a migração de segredos para variáveis de ambiente seguras.