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.
- 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/123não tem verificação no servidor.
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:-- comenta a verificação de senha, concedendo acesso à conta admin sem saber a senha.
Código seguro (consulta parametrizada, ou parameterized query):
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
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
Exemplo de payload:
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.:
dangerouslySetInnerHTMLno 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:- Vítima está logada no banco em
banco.com.br. - Vítima visita uma página maliciosa contendo:
<img src="https://banco.com.br/transferir?para=atacante&valor=10000"> - O navegador inclui automaticamente o cookie de sessão da vítima.
- 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
SameSiteem cookies de sessão paraStrictouLax. - 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.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
- Nunca confie em input do usuário: Valide, sanitize e codifique tudo.
- Autorize no servidor: Controles do lado do cliente são cosméticos, não segurança.
- Use consultas parametrizadas: A única defesa confiável contra SQL Injection.
- Implemente headers CSP: Defesa em profundidade contra XSS.
- Proteja contra CSRF: Use tokens anti-CSRF e cookies SameSite.
- Bloqueie SSRF: Valide URLs, bloqueie IPs internos.
- Audite configurações: Configurações padrão quase nunca são seguras.