Testes de Segurança Básicos: O Que Todo QA Deveria Fazer

Introdução

"Segurança não é minha responsabilidade, temos um time especializado para isso."

Se você pensa assim, precisa ler este artigo. Porque segurança É responsabilidade de todos, e existem testes básicos que TODO QA pode (e deve) fazer, sem ser especialista.

Neste artigo, você vai aprender os testes de segurança essenciais que previnem 80% dos problemas mais comuns. Não precisa ser hacker. Não precisa de ferramentas caras. Só precisa saber o que testar.

---

Por Que QA Deve Testar Segurança?

Realidade: A maioria das vulnerabilidades é descoberta em produção, não em testes. Por quê? Porque QAs acham que segurança não é com eles. Verdade: Testes básicos de segurança são tão importantes quanto testar se um botão funciona.

---

1. Script Injection (XSS - Cross-Site Scripting)

O Que É?

Injetar código JavaScript malicioso em campos de entrada.

Por Que É Perigoso?

• Roubo de cookies/sessões
• Redirecionamento para sites maliciosos
• Modificação da página
• Roubo de dados do usuário

Como Testar?

Payload básico:

<script>alert('XSS')</script>

Onde testar:
• TODOS os campos de texto
• Campos de busca
• Comentários
• Formulários
• URLs (parâmetros GET)
O que observar:
• ✅ Seguro: Código é escapado e aparece como texto
• ❌ Vulnerável: Popup aparece (script executou)
Outros payloads para testar:

<img src=x onerror=alert('XSS')>
<svg onload=alert('XSS')>
"><script>alert('XSS')</script>

---

2. SQL Injection

O Que É?

Injetar comandos SQL em campos de entrada para manipular o banco de dados.

Por Que É Perigoso?

• Acesso a dados sensíveis
• Modificação/exclusão de dados
• Bypass de autenticação
• Controle total do banco

Como Testar?

Payloads básicos:

' OR '1'='1
' OR 1=1--
admin'--
' UNION SELECT NULL--

Onde testar:
• Campos de login (usuário e senha)
• Campos de busca
• Filtros
• Qualquer campo que faça query no banco
O que observar:
• ✅ Seguro: Erro genérico ou busca vazia
• ❌ Vulnerável: Erro de SQL exposto, login bem-sucedido, dados inesperados
Exemplo prático:

Campo de login:

Usuário: admin'--
Senha: qualquer coisa

Se logar sem senha válida = VULNERÁVEL!

---

3. HTML Injection

O Que É?

Injetar tags HTML em campos de entrada.

Diferença de XSS?

• XSS executa JavaScript
• HTML Injection apenas modifica a aparência

Como Testar?

Payloads:

<h1>Teste</h1>
<b>Negrito</b>
<marquee>Texto rolando</marquee>

O que observar:
• ✅ Seguro: Tags aparecem como texto
• ❌ Vulnerável: HTML é renderizado

---

4. Validação de Upload de Arquivos

Riscos:

• Upload de arquivos maliciosos (.exe, .php, .sh)
• Sobrescrita de arquivos do sistema
• Consumo excessivo de espaço

O Que Testar?

4.1 Tipos de Arquivo

✅ Permitidos: .jpg, .png, .pdf
❌ Bloqueados: .exe, .php, .sh, .bat

Teste:
• Tente fazer upload de cada tipo
• Verifique se bloqueados são rejeitados

4.2 Tamanho Máximo

Teste com:
- Arquivo dentro do limite
- Arquivo no limite exato
- Arquivo acima do limite

4.3 Nomes Maliciosos

../../../etc/passwd
..\..\windows\system32\config
arquivo.jpg.exe (extensão dupla)
<script>alert('xss')</script>.jpg

4.4 Conteúdo vs Extensão

• Renomeie um .exe para .jpg
• Tente fazer upload
• Sistema deve validar conteúdo, não só extensão

---

5. Autenticação e Autorização

5.1 Acesso Sem Login

Teste:
• Copie URL de página autenticada
• Abra em aba anônima (sem login)
• Tente acessar diretamente
Esperado: Redirecionar para login

5.2 Acesso a Recursos de Outros Usuários

Teste:
• Logue como Usuário A
• Copie URL de recurso do Usuário A (ex: /pedido/123)
• Logue como Usuário B
• Tente acessar /pedido/123
Esperado: Acesso negado

5.3 Elevação de Privilégios

Teste:
• Logue como usuário comum
• Tente acessar URLs de admin
• Tente modificar parâmetros (ex: ?role=admin)
Esperado: Acesso negado

---

6. Exposição de Informações Sensíveis

6.1 Mensagens de Erro

❌ Ruim:

Erro: Query failed: SELECT * FROM users WHERE email='test@test.com'

✅ Bom:

Erro: Não foi possível processar sua solicitação.

6.2 Comentários no HTML

Verifique:
• View Source da página
• Procure por comentários com informações sensíveis
• Senhas, tokens, endpoints internos

6.3 Respostas de API

Teste:
• Faça requisições à API
• Verifique se retorna mais dados que o necessário
• Ex: Senha hash, dados de outros usuários

---

7. Força Bruta e Rate Limiting

O Que Testar?

Login:
• Tente logar 10x com senha errada
• Sistema deve bloquear após N tentativas
APIs:
• Faça 100 requisições em 1 minuto
• Deve ter limite de taxa (rate limiting)
Formulários:
• Envie múltiplos formulários rapidamente
• Deve ter proteção contra spam

---

8. HTTPS e Cookies Seguros

8.1 HTTPS

Teste:
• Acesse site com HTTP (sem S)
• Deve redirecionar para HTTPS
• Páginas de login/pagamento DEVEM ser HTTPS

8.2 Cookies

Verifique (DevTools → Application → Cookies):
• ✅ Secure: true (só HTTPS)
• ✅ HttpOnly: true (não acessível via JavaScript)
• ✅ SameSite: Lax ou Strict

---

9. Validação de Entrada

Regra de Ouro:

NUNCA confie em dados do usuário!

O Que Validar?

Servidor-side:
• Todas as validações devem ser no servidor
• Validação no front-end é apenas UX
Whitelist vs Blacklist:
• ✅ Whitelist: Aceitar apenas o que é permitido
• ❌ Blacklist: Bloquear o que é proibido (sempre falta algo)

---

10. Checklist de Segurança Básica

INJECTION:
☐ Script Injection (XSS) em todos os campos
☐ SQL Injection em campos de busca/login
☐ HTML Injection em campos de texto

UPLOAD:
☐ Tipos de arquivo permitidos/bloqueados
☐ Tamanho máximo
☐ Nomes maliciosos
☐ Validação de conteúdo

AUTENTICAÇÃO:
☐ Acesso sem login bloqueado
☐ Acesso a recursos de outros usuários bloqueado
☐ Elevação de privilégios bloqueada

EXPOSIÇÃO:
☐ Mensagens de erro genéricas
☐ Sem comentários sensíveis no HTML
☐ APIs não retornam dados extras

PROTEÇÃO:
☐ Limite de tentativas de login
☐ Rate limiting em APIs
☐ Proteção contra spam

HTTPS/COOKIES:
☐ Redirecionamento HTTP → HTTPS
☐ Cookies com Secure e HttpOnly
☐ Páginas críticas em HTTPS

---

Como Reportar Vulnerabilidades

❌ Não Faça:

• Explorar a vulnerabilidade além do teste
• Acessar dados de outros usuários
• Compartilhar publicamente antes de correção

✅ Faça:

• Documente evidências (screenshots, payloads)
• Classifique severidade (Crítica, Alta, Média, Baixa)
• Reporte ao time de segurança/desenvolvimento
• Sugira correção se possível

Template de Reporte:

Título: XSS no campo de comentários

Severidade: Alta

Descrição:
Campo de comentários não sanitiza entrada, permitindo execução de JavaScript.

Passos para Reproduzir:
1. Acessar /comentarios
2. Inserir: <script>alert('XSS')</script>
3. Salvar comentário
4. Recarregar página

Resultado:
Popup aparece, indicando execução de script.

Impacto:
Atacante pode roubar cookies de sessão de outros usuários.

Sugestão:
Sanitizar entrada com htmlspecialchars() ou biblioteca equivalente.

---

Quando Escalar para Especialista?

Escale quando:
• Encontrar vulnerabilidade crítica
• Precisar de testes avançados (pentest)
• Lidar com criptografia
• Testar infraestrutura (servidores, rede)
Você pode fazer:
• Testes básicos de injection
• Validação de upload
• Testes de autenticação/autorização
• Verificação de HTTPS/cookies

---

Conclusão

Segurança não é "coisa de especialista". 80% das vulnerabilidades podem ser prevenidas com testes básicos que qualquer QA pode fazer.

Use este checklist em TODOS os seus projetos. Não espere o time de segurança. Não espere acontecer em produção.

Lembre-se: Um bug de funcionalidade é ruim. Uma vulnerabilidade de segurança pode ser catastrófica.

---

Quer aprender mais sobre testes práticos?

Inscreva-se no canal LiraQuality no YouTube

Encontrou uma vulnerabilidade e quer discutir?

Acesse o fórum da comunidade (sem expor detalhes sensíveis!)