appsec.mdc

---
description: Appsec
---

# Regras para Assistente de Appsec (Cursor)

## Perfil e Objetivo Principal

Você é um especialista sênior em segurança de aplicações (AppSec) e meu parceiro técnico. Seu objetivo é me auxiliar a conduzir um pentest whitebox e um secure code review em uma aplicação Node.js/JavaScript. Sua comunicação deve ser técnica, precisa e proativa.

## Contexto Permanente

Estes são os fatos e arquivos que você deve sempre considerar em todas as suas respostas:

1.  **Nosso Fluxo de Trabalho:** Estamos seguindo um processo sistemático. Nossas tarefas estão no arquivo `checklist_pentest_nodejs.md`. Nosso trabalho final é preencher o `report.md`. Os dois estão na pasta `.appsec` onde vamos colocar tudo relacionado a analise.
2.  **Arquivos Chave:**
    * `checklist_pentest_nodejs.md`: É nosso guia e lista de tarefas. Sempre consulte este arquivo para saber qual é o próximo passo e para marcar as tarefas concluídas.
    * `report.md`: É o relatório de segurança *em construção*. Ele **deve ser atualizado continuamente** por você após a conclusão de cada tarefa relevante.
3.  **Stack Tecnológico:**
    * **Linguagens:** Node.js, JavaScript (possivelmente TypeScript).
    * **Frameworks Comuns:** NextJS e React.
    * **Banco de Dados:** MongoDB.
4.  **Ferramentas Disponíveis:** Você pode simular a execução e interpretar os resultados, contando que precisamos validar manualmente os alertas, visto que estas ferramentas podem contem falsos positivo, então nunca considere adicionar os seus resultados no relatorio antes de consultar o usuario. As seguintes ferramentas estão disponiveis:
    * **SAST:** CodeQL, Semgrep.
    * **SCA:** `npm audit` ou `yarn audit`.
    * **DAST:** Burp Suite com MCP Server

## Regras de Execução

Estas são as diretrizes que você deve seguir rigorosamente:

1.  **O CICLO DE TAREFA-RELATÓRIO:** Esta é a regra mais importante.
    * **Passo 1: Identificar Tarefa:** Consulte o `checklist_pentest_nodejs.md` para a próxima tarefa não marcada (`- [ ]`).
    * **Passo 2: Executar Análise:** Execute a análise solicitada (ex: "rode o Semgrep", "analise esta função para IDOR").
    * **Passo 3: ATUALIZAR O RELATÓRIO:** Este passo é obrigatório.
        * **Se um achado for encontrado:** Documente a vulnerabilidade **imediatamente** no arquivo `report.md`. Utilize o formato exato especificado na seção "Formato de Saída". Peça-me para atribuir um ID (ex: `ID-001`) e a severidade, ou sugira uma com base no risco.
        * **Se nenhum achado for encontrado (resultado negativo):** Isso também é importante. Adicione uma breve nota na seção "5. Considerações Finais" do `report.md`, algo como: "A verificação de [TIPO DE VULNERABILIDADE] no [COMPONENTE] foi realizada e nenhuma vulnerabilidade foi encontrada." Isso mostra que a análise foi completa.
    * **Passo 4: Atualizar o Checklist:** Após a tarefa ser executada e o relatório atualizado, edite o arquivo `checklist_pentest_nodejs.md` e marque a tarefa como concluída (`- [x]`).
    * **Passo 5: Confirmar e Aguardar:** Informe que o ciclo foi concluído e aguarde a próxima instrução.

2.  **Seja Proativo:** Se, ao analisar um código para uma tarefa específica, você identificar uma outra vulnerabilidade potencial, **aponte-a imediatamente**. Pergunte: "Notei também [outra vulnerabilidade]. Deseja que eu a investigue e a adicione ao relatório agora?".

3.  **Peça Esclarecimentos:** Se uma tarefa no checklist ou uma instrução minha for ambígua, não prossiga. Peça esclarecimentos para garantir que a análise seja precisa. Ex: "Para testar o controle de acesso, quais são os diferentes perfis de usuário que devo considerar?".

## Formato de Saída para o Relatório (`report.md`)

Ao documentar uma vulnerabilidade no `report.md`, **sempre** utilize esta estrutura. Preencha cada campo de forma clara e detalhada:

```markdown
### [ID-XXX] - Título da Vulnerabilidade

* **Severidade:** 🔴 Crítica / 🟠 Alta / 🟡 Média / 🔵 Baixa
* **CWE:** [CWE Correspondente, ex: CWE-89]
* **OWASP Top 10:** [Categoria Correspondente, ex: A03:2021 - Injection]

**Descrição:**
[Explicação clara e concisa do que é a vulnerabilidade, onde ela está e por que é um problema.]

**Localização:**
* **Arquivo:** `[caminho/para/o/arquivo.js]`
* **Linha:** `[número da linha]`
* **Função:** `[nomeDaFuncao]`
* **Endpoint:** `[Método e URL, ex: GET /api/users/:id]`

**Prova de Conceito (PoC):**
[Passos detalhados para reproduzir a falha. Inclua snippets de código, requisições HTTP (se aplicável) e a resposta esperada que comprova a vulnerabilidade.]

**Impacto:**
[Descrição do que um atacante poderia conseguir ao explorar a falha (ex: vazamento de dados, execução de código, negação de serviço).]

**Recomendação de Correção:**
[Instruções **específicas e acionáveis** para o desenvolvedor. Inclua exemplos de código corrigido sempre que possível.]

**Referências:**
* [Links para OWASP Cheat Sheets, documentação oficial ou artigos relevantes.]
```

checklist.md

Checklist de Pentest Whitebox e Secure Code Review (Node.js/JavaScript)

Este checklist guia o processo de análise de segurança em uma aplicação Node.js e JavaScript, combinando revisão de código e testes de penetração whitebox. Use-o para rastrear o progresso e garantir a cobertura completa.

Fase 1: Análise de Arquitetura e Levantamento de Riscos

O objetivo é entender o design da aplicação e identificar os pontos de maior risco antes de mergulhar no código.

• 1.1. Mapeamento de Componentes:
  • Identificar todos os serviços (backend Node.js, frontend SPA - React/Vue/Angular, etc.).
  • Listar bancos de dados (SQL, NoSQL), sistemas de cache (Redis, Memcached) e filas de mensagens (RabbitMQ, SQS).
  • Mapear integrações externas (APIs de terceiros, gateways de pagamento, serviços de autenticação).
• 1.2. Análise de Fluxo de Dados:
  • Documentar como dados sensíveis (credenciais, PII, dados financeiros) fluem entre os componentes.
  • Criar ou revisar Diagramas de Fluxo de Dados (DFDs) para os principais casos de uso.
• 1.3. Modelagem de Ameaças (Threat Modeling):
  • Identificar as principais ameaças para a arquitetura (ex: acesso não autorizado a APIs internas, vazamento de dados da fila).
  • Priorizar os riscos com base no impacto e probabilidade.
• 1.4. Revisão de Configuração Arquitetural:
  • Analisar como a aplicação é implantada (contêineres, serverless, VM).
  • Verificar controles de segurança existentes (WAF, IPS) e decidir se serão desativados durante o teste para focar na aplicação.

Fase 2: Mapeamento da Aplicação e Pontos de Entrada

Enumerar todas as superfícies de ataque da aplicação.

• 2.1. Enumeração de Endpoints:
  • Extrair todas as rotas da API a partir do código (ex: arquivos de rotas do Express.js ou Koa).
  • Utilizar um proxy (ex: Burp Suite, OWASP ZAP) para navegar na aplicação e confirmar os endpoints descobertos.
  • Listar todos os parâmetros de entrada (query, body, headers, cookies) para cada endpoint.
• 2.2. Mapeamento de Funcionalidades e Acesso:
  • Identificar funcionalidades críticas (autenticação, gestão de perfil, transações, uploads).
  • Mapear os diferentes níveis de acesso (usuário anônimo, usuário autenticado, administrador).
  • Documentar fluxos de múltiplos passos (ex: recuperação de senha, checkout de compra).

Fase 3: Secure Code Review (Análise Estática)

Revisão do código-fonte com foco em vulnerabilidades, combinando automação e análise manual.

• 3.1. Varredura Automatizada Inicial (SAST):
  • Executar CodeQL: Configurar e rodar a análise do CodeQL para uma varredura profunda de fluxo de dados.

    # Exemplo de comando para preparar e analisar com CodeQL
    codeql database create --language=javascript --source-root . db
    codeql database analyze codeql_db --format=sarif-latest --output=codeql_results.sarif

  • Executar Semgrep: Rodar o Semgrep com o conjunto de regras para JavaScript/TypeScript e segurança.

    semgrep --config "p/javascript" --config "p/expressjs" --config "p/node" .

• 3.2. Revisão Manual Guiada (Foco nos pontos críticos):
  • Validação de Entradas (Prevenção de Injeção):
    • Revisar como os dados de entrada são usados em queries de banco de dados (risco de SQL/NoSQL Injection).
    • Verificar o uso de dados em comandos do sistema operacional (risco de Command Injection).
  • Prevenção de Cross-Site Scripting (XSS):
    • Analisar como os dados são renderizados no frontend. Procurar por innerHTML, dangerouslySetInnerHTML etc.
    • Garantir que a sanitização e o escaping de saída estão sendo aplicados corretamente.
  • Controle de Acesso:
    • Verificar se cada endpoint sensível possui um middleware de autorização.
    • Procurar por falhas de Referência Insegura a Objetos (IDOR) onde um usuário pode acessar/modificar dados de outro apenas alterando um ID.
  • Autenticação e Gestão de Sessão:
    • Revisar o processo de login (proteção contra brute force, enumeração de usuários).
    • Analisar o armazenamento de senhas (uso de bcrypt ou argon2 com salt).
    • Inspecionar a implementação de JWT (validação de assinatura, algoritmo, expiração).
  • Exposição de Dados Sensíveis:
    • Procurar por dados sensíveis em logs (console.log).
    • Verificar se as mensagens de erro não expõem detalhes da implementação (stack traces).
  • Vulnerabilidades Específicas de Node.js:
    • Investigar a manipulação de objetos em busca de riscos de Prototype Pollution.
    • Revisar o uso de eval(), setTimeout() e new Function() com entradas do usuário.
    • Analisar o tratamento de eventos e callbacks para evitar condições de corrida ou lógica insegura.

Fase 4: Pentest White-Box (Análise Dinâmica)

Testar a aplicação em execução, usando o conhecimento do código para guiar os ataques.

• 4.1. Preparação do Ambiente:
  • Configurar o proxy (Burp Suite / OWASP ZAP) para interceptar o tráfego da aplicação.
  • Obter credenciais para os diferentes níveis de acesso.
  • Nota: Temos o servidor Burp Suite MCP (Master-Collaborator-Proxy) disponível para testes colaborativos e para detectar interações fora da banda (out-of-band).
• 4.2. Execução dos Testes (baseado nos achados da Fase 3):
  • Testar Injeções: Tentar explorar ativamente os pontos de injeção identificados no código.
  • Testar XSS: Injetar payloads de XSS nos campos suspeitos e verificar a execução no navegador.
  • Testar Quebras de Controle de Acesso:
    • Como usuário A, tentar acessar recursos do usuário B (IDOR).
    • Como usuário comum, tentar acessar endpoints de administrador.
  • Explorar Lógica de Negócio: Tentar subverter fluxos de negócio (ex: pular uma etapa de pagamento, aplicar um cupom mais de uma vez).
  • Fuzzing: Utilizar o Intruder (Burp) ou Fuzzers (ffuf, wfuzz) para enviar dados inesperados aos endpoints e observar falhas.
  • Testar o JWT: Manipular tokens (alterar payload, tentar alg:none) usando extensões como o JWT Editor.

Fase 5 & 6: Análise de Dependências e Segredos

Identificar vulnerabilidades em componentes de terceiros e segredos hardcoded.

• 5.1. Análise de Composição de Software (SCA):
  • Executar npm audit ou yarn audit para encontrar dependências com vulnerabilidades conhecidas.
  • (Opcional) Usar o OWASP Dependency-Check para um relatório mais detalhado.
• 5.2. Varredura de Segredos:
  • Rodar o Gitleaks ou TruffleHog no repositório para encontrar chaves de API, senhas ou outros segredos no código e no histórico do Git.

    gitleaks detect --source . -v

Fase 7: Consolidação e Relatório

Documentar todos os achados de forma clara e acionável.

• 6.1. Coletar Evidências: Tirar screenshots, salvar requisições/respostas HTTP e snippets de código para cada vulnerabilidade encontrada.
• 6.2. Preencher o Relatório: Usar o template report_template.md para documentar cada achado com descrição, impacto, PoC e recomendação.
• 6.3. Revisar o Relatório: Garantir que o relatório seja claro, preciso e útil para a equipe de desenvolvimento.
• 6.4. Apresentar os Resultados: Agendar uma reunião para discutir os achados com os stakeholders.

final_report.md

Relatório de Análise de Segurança da Aplicação

• Nome do Projeto: [Inserir Nome do Projeto]
• Período da Análise: [DD/MM/AAAA] a [DD/MM/AAAA]
• Avaliador(es): [Seu Nome/Equipe]
• Versão do Código/Commit: [Inserir Hash do Commit ou Versão]

---

1. Resumo Executivo

Neste período, foi conduzida uma análise de segurança no formato whitebox (revisão de código e testes de penetração) na aplicação [Nome do Projeto]. O objetivo foi identificar e avaliar vulnerabilidades de segurança na base de código Node.js e JavaScript.

A análise revelou um total de [X] vulnerabilidades, sendo [X] críticas, [X] altas, [X] médias e [X] baixas. As falhas mais críticas encontradas estão relacionadas a [Ex: controle de acesso inadequado, permitindo que usuários visualizem dados de outros clientes] e [Ex: vulnerabilidades de injeção que podem levar ao comprometimento do banco de dados].

Recomenda-se que a equipe de desenvolvimento priorize a correção das vulnerabilidades críticas e altas para mitigar os riscos mais significativos para o negócio.

Tabela de Resumo dos Achados

Severidade	Quantidade
🔴 Crítica	[X]
🟠 Alta	[X]
🟡 Média	[X]
🔵 Baixa	[X]
Total	[X]

---

2. Escopo e Metodologia

A análise focou no código-fonte do repositório [Link para o Repositório] e na aplicação em execução no ambiente de [desenvolvimento/staging].

A metodologia seguiu um framework estruturado, combinando:

1. Análise de Arquitetura e Modelagem de Ameaças.
2. Mapeamento de Funcionalidades e Pontos de Entrada.
3. Análise Estática de Código de Segurança (SAST): Revisão manual e com ferramentas como CodeQL e Semgrep.
4. Análise Dinâmica de Segurança (DAST): Testes de penetração guiados pelo código (whitebox) com auxílio do Burp Suite.
5. Análise de Composição de Software (SCA): Verificação de dependências vulneráveis com npm audit.
6. Varredura de Segredos: Busca por credenciais expostas com Gitleaks.

A classificação de severidade foi baseada no modelo de risco da OWASP, considerando o impacto técnico e a probabilidade de exploração.

---

3. Ferramentas Utilizadas

• Análise Estática (SAST): GitHub CodeQL, Semgrep, ESLint (com plugins de segurança).
• Proxy de Interceptação e Análise Dinâmica (DAST): PortSwigger Burp Suite Professional (com servidor MCP).
• Análise de Dependências (SCA): npm audit.
• Varredura de Segredos: Gitleaks.
• Cliente de API: Postman/Insomnia.

---

4. Detalhamento Técnico dos Achados

A seguir, cada vulnerabilidade encontrada é detalhada com informações técnicas, prova de conceito e recomendações de correção.

---

---

[ID-001] - Título da Vulnerabilidade (Ex: Injeção de SQL na Busca de Produtos)

• Severidade: 🔴 Crítica
• CWE: CWE-89 (Improper Neutralization of Special Elements used in an SQL Command)
• OWASP Top 10: A03:2021 - Injection

Descrição: A funcionalidade de busca de produtos, localizada no endpoint /api/products/search, constrói a consulta SQL concatenando diretamente o parâmetro q fornecido pelo usuário. Isso permite que um atacante manipule a query, extraia, modifique ou delete dados do banco de dados.

Localização:

• Arquivo: src/controllers/productController.js
• Linha: 42
• Função: searchProducts

Prova de Conceito (PoC): Um atacante pode explorar esta falha enviando um payload malicioso no parâmetro q.

Requisição HTTP:

GET /api/products/search?q=xyz' OR '1'='1'; -- HTTP/1.1
Host: [app-hostname]
...

Trecho de Código Vulnerável:

// Arquivo: src/controllers/productController.js:42
const query = `SELECT * FROM products WHERE name LIKE '%${req.query.q}%'`;
db.query(query, (err, results) => { ... });

Impacto: A exploração bem-sucedida pode resultar no vazamento de todos os dados da tabela de produtos, negação de serviço ao banco de dados ou, dependendo das permissões do usuário do banco, comprometimento total do servidor.

Recomendação de Correção: Utilize prepared statements (consultas parametrizadas) para garantir que as entradas do usuário sejam tratadas como dados e não como parte do código SQL.

Exemplo de Código Corrigido:

// Arquivo: src/controllers/productController.js:42
const query = 'SELECT * FROM products WHERE name LIKE ?';
const searchTerm = `%${req.query.q}%`;
db.query(query, [searchTerm], (err, results) => { ... });

Referências:

• OWASP SQL Injection Prevention Cheat Sheet

---

---

[ID-002] - Título da Vulnerabilidade (Ex: Quebra de Controle de Acesso - IDOR)

• Severidade: 🟠 Alta
• CWE: CWE-639 (Authorization Bypass Through User-Controlled Key)
• OWASP Top 10: A01:2021 - Broken Access Control

Descrição: O endpoint /api/users/{userId}/profile, que retorna os dados do perfil de um usuário, não valida se o usuário autenticado é o mesmo que o userId solicitado ou se possui privilégios de administrador. Isso permite que qualquer usuário autenticado visualize os dados de perfil de qualquer outro usuário apenas alterando o ID na URL.

Localização:

• Arquivo: src/routes/userRoutes.js
• Endpoint: GET /api/users/:userId/profile

Prova de Conceito (PoC):

1. Autentique-se na aplicação como user_A (com ID 101).
2. Faça uma requisição para o seu próprio perfil: GET /api/users/101/profile. A aplicação retorna seus dados.
3. Altere a requisição para GET /api/users/102/profile (onde 102 é o ID do user_B).
4. A API retorna os dados do user_B, confirmando a falha.

Impacto: Vazamento de informações pessoais de todos os usuários da plataforma, incluindo nomes, e-mails, endereços e outras informações armazenadas no perfil.

Recomendação de Correção: Implemente uma verificação no controlador da rota para garantir que o ID do usuário na sessão (ou no token JWT) seja o mesmo do userId na URL, ou que o usuário tenha uma permissão de admin.

Exemplo de Código Corrigido:

// Middleware ou lógica no controlador
router.get('/api/users/:userId/profile', (req, res) => {
  const requestedId = req.params.userId;
  const requesterId = req.user.id; // ID do usuário a partir do token/sessão
  const isAdmin = req.user.role === 'admin';

  if (requestedId !== requesterId && !isAdmin) {
    return res.status(403).json({ error: 'Forbidden' });
  }

  // Prossiga com a lógica para buscar o perfil...
});

Referências:

• OWASP Broken Access Control
• OWASP Insecure Direct Object Reference (IDOR) Prevention Cheat Sheet

---

---

... adicione mais seções de vulnerabilidades conforme necessário ...

5. Considerações Finais e Pontos Positivos

Recomendações Gerais:

• Integração Contínua (CI/CD): Recomenda-se integrar as ferramentas de SAST (Semgrep) e SCA (npm audit) ao pipeline de CI/CD para detectar vulnerabilidades automaticamente em cada pull request.
• Treinamento: Investir em treinamento de desenvolvimento seguro para a equipe, focando nas vulnerabilidades mais comuns encontradas nesta análise (ex: OWASP Top 10).

Pontos Positivos:

• [Ex: A aplicação já utiliza bcrypt para o armazenamento seguro de senhas, o que é uma excelente prática.]
• [Ex: O uso de cookies de sessão com as flags HttpOnly e Secure já está implementado corretamente.]