Penetration testing básico para desenvolvedores

1. O que é Penetration Testing e por que Desenvolvedores Precisam Conhecer?

Penetration testing (pentest) é a prática de simular ataques cibernéticos contra um sistema para identificar vulnerabilidades exploráveis. Diferente de um vulnerability assessment, que apenas escaneia e lista falhas conhecidas, o pentest busca explorá-las ativamente para provar o impacto real. Já o bug bounty é uma versão crowdsourced, onde pesquisadores externos são recompensados por encontrar bugs.

Para desenvolvedores, entender pentest é essencial porque ele complementa ferramentas de SAST (Static Application Security Testing) e DAST (Dynamic Application Security Testing). Enquanto SAST analisa código-fonte e DAST testa aplicações em execução, o pentest adiciona a criatividade humana para encontrar falhas de lógica de negócio e encadeamentos de vulnerabilidades que ferramentas automatizadas perdem.

Os três tipos principais de pentest são:
- Black-box: o testador não tem conhecimento interno do sistema, simulando um atacante externo
- White-box: acesso completo ao código, documentação e arquitetura
- Gray-box: acesso parcial (ex: credenciais de usuário comum, mas sem acesso ao código-fonte)

Para desenvolvedores, o gray-box é o mais prático, pois permite focar em vulnerabilidades relevantes sem perder tempo com reconhecimento cego.

2. Preparação e Escopo: Antes de Testar

Antes de qualquer teste, é crucial definir o escopo. Mapeie todos os endpoints, APIs e funcionalidades críticas da aplicação. Crie uma lista como:

POST /api/login
GET /api/users/{id}
POST /api/upload
GET /admin/dashboard

Obtenha autorização formal por escrito. Teste apenas em ambientes isolados (staging/homologação). Ferramentas essenciais incluem:
- Burp Suite: proxy interceptador completo para análise de tráfego HTTP/HTTPS
- OWASP ZAP: alternativa gratuita com scanner automatizado
- cURL/Postman: para testes manuais rápidos de endpoints

Exemplo de requisição manual com cURL:

curl -X POST https://staging.api.exemplo.com/login \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"test123"}'

3. Reconhecimento e Coleta de Informações

A enumeração de endpoints pode revelar rotas ocultas. Use ferramentas como dirb ou gobuster:

gobuster dir -u https://staging.exemplo.com -w /usr/share/wordlists/dirb/common.txt

Analise respostas HTTP para identificar versões de frameworks. Um cabeçalho como X-Powered-By: Express ou Server: Apache/2.4.41 revela tecnologias. Use Wappalyzer (extensão de navegador) ou WhatWeb:

whatweb https://staging.exemplo.com

Mensagens de erro detalhadas são minas de ouro. Um stack trace expõe caminhos de arquivos e versões de bibliotecas.

4. Testes Clássicos de Entrada: OWASP Top 10 na Prática

Injeção SQL (SQLi)

Teste campos de busca e login com caracteres especiais:

POST /api/login
{"username": "admin' OR '1'='1", "password": "qualquer"}

Se a resposta for diferente de um erro padrão, há potencial de SQLi.

Cross-Site Scripting (XSS)

Insira scripts em campos de comentários ou parâmetros de URL:

GET /busca?q=<script>alert('XSS')</script>

Verifique se o script é executado no navegador.

Falhas de Autenticação

Teste brute force em logins usando listas de senhas comuns:

for senha in $(cat senhas.txt); do
  curl -s -X POST https://staging.exemplo.com/login \
    -d "username=admin&password=$senha" | grep -q "Bem-vindo" && echo "Senha: $senha"
done

Verifique também tokens JWT: tente modificar o payload ou usar algoritmos "none":

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4ifQ.

5. Exploração de Lógica de Negócio e Configuração

IDOR (Insecure Direct Object Reference)

Altere IDs em requisições para acessar recursos de outros usuários:

GET /api/users/1
GET /api/users/2
GET /api/users/3

Se a resposta retornar dados de outro usuário sem autenticação adicional, há IDOR.

Upload de Arquivos Maliciosos

Tente fazer upload de arquivos com extensões perigosas:

POST /api/upload
Content-Type: multipart/form-data
Arquivo: shell.php

Teste também renomear extensões (shell.php.jpg) ou usar arquivos poliglotas.

Configuração Insegura

Verifique headers de segurança ausentes:

curl -I https://staging.exemplo.com

Procure por:
- Access-Control-Allow-Origin: * (CORS permissivo)
- Ausência de Content-Security-Policy
- X-Debug: true em respostas

6. Documentação e Relatório para o Time

Um relatório técnico deve conter:
1. Resumo executivo: impacto geral e riscos para o negócio
2. Vulnerabilidades encontradas: cada uma com ID, severidade (CVSS) e descrição
3. Evidências reprodutíveis: prints, requisições completas e passos para replicar
4. Recomendações de correção: exemplos de código seguro

Exemplo de evidência para SQLi:

Requisição:
POST /api/login
{"username": "admin' OR '1'='1", "password": "teste"}

Resposta:
HTTP 200
{"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}

Recomendação de correção:

// Código inseguro:
const query = `SELECT * FROM users WHERE username = '${username}'`;

// Código seguro (usando prepared statements):
const query = 'SELECT * FROM users WHERE username = ?';
db.execute(query, [username]);

7. Integrando Pentest no Pipeline de Desenvolvimento

Automatize testes recorrentes com OWASP ZAP em CI/CD. Exemplo para GitHub Actions:

name: ZAP Scan
on: [push]
jobs:
  zap_scan:
    runs-on: ubuntu-latest
    steps:
      - name: ZAP Scan
        uses: zaproxy/action-full-scan@v0.4.0
        with:
          target: 'https://staging.exemplo.com'

Crie checklists de segurança para pré-deploy:
- [ ] Testar injeção em todos os formulários
- [ ] Verificar autorização em endpoints de API
- [ ] Validar uploads de arquivos
- [ ] Conferir headers de segurança

Promova uma cultura de segurança com gamificação: crie um programa de bug bounty interno, onde desenvolvedores ganham pontos por encontrar vulnerabilidades em sistemas de colegas. Isso transforma segurança em um desafio divertido, não uma tarefa chata.

Referências