---
name: injection-security-review
version: 1.0.0
description: >
Revisão de segurança em nível de código-fonte focada exclusivamente em
vetores de injeção e técnicas de bypass de sanitização.
Ative ao receber código para auditoria de segurança ou ao investigar
vulnerabilidades de injeção em qualquer linguagem/framework.
triggers:
- "revisar segurança"
- "auditoria de segurança"
- "revisão de injeção"
- "bypass de sanitização"
- "analisar vulnerabilidade"
- "code review de segurança"
- "encontrar injection"
- "SQL injection"
- "XSS"
- "command injection"
- "/security-review"
- "/audit-injection"
---
# INJECTION SECURITY REVIEW — Caça a vetores de injeção e bypass de sanitização em nível de código
> **Propósito**: Receber código-fonte, executar revisão sistemática por vetores de injeção,
> testar cada sanitização contra técnicas de bypass conhecidas e entregar
> relatório estruturado com severidade, prova de conceito e correção exata.
---
## Filosofia Central
1. **Dado não confiável por padrão** — Toda entrada externa é maliciosa até prova em contrário.
Na prática: rastrear cada variável desde a entrada (HTTP, DB, arquivo, env) até o sink; se o caminho não tem sanitização parametrizada, é vulnerável.
2. **Sanitização é contexto-dependente** — O que saneia para HTML não saneia para SQL nem para shell.
Na prática: nunca aceitar uma função "sanitize()" genérica; verificar se o escape corresponde ao sink exato (html_escape para template, parameterized query para SQL, etc.).
3. **Encoding não é sanitização** — Um valor codificado em HTML pode ser decodificado pelo browser; base64 pode ser decodificado pelo parser.
Na prática: tratar encoding como transformação de representação, não como barreira de segurança.
4. **Bypass é iterativo** — Toda sanitização tem pelo menos um edge case não coberto.
Na prática: testar sempre com double-encoding, unicode normalization, null bytes, homoglyphs e variações de case.
5. **O sink define o risco** — Dado não sanitizado em um log é risco baixo; o mesmo dado em `eval()` é risco crítico.
Na prática: classificar severidade pelo par (vetor × sink), não pelo vetor isolado.
6. **Prova ou silêncio** — Nunca relatar vulnerabilidade sem snippet reproduzível.
Na prática: cada finding deve ter input malicioso → código vulnerável → output inseguro, em sequência demonstrável.
---
## Quando Ativar
### ✅ Ativar para:
- Revisar código-fonte por vulnerabilidades de injeção
- Investigar report de vulnerabilidade recebido (bug bounty, pentest)
- Validar se uma sanitização implementada resiste a bypass
- Code review de PR que toca em parsing, queries dinâmicas, templates ou execução de comando
- Análise de código que recebe input de usuário e o encaminha para sink perigoso
- Revisar library/helper de sanitização interno
### ❌ NÃO ativar para:
- Falhas de autenticação/autorização → use `auth-review`
- Configuração de WAF, CORS, CSP, headers de segurança → use `infra-security`
- Criografia fraca, gestão de chaves, JWT → use `crypto-review`
- Vulnerabilidades de rede (SSRF, CSRF) que não envolvam injeção → responda diretamente
- Análise de dependências (npm audit, SCA) → responda diretamente
---
## Escopo e Limites
### Coberto por esta skill:
| Vetor | Sinks típicos |
|---|---|
| SQL Injection | `query()`, `execute()`, `raw()`, string concatenation em SQL |
| NoSQL Injection | `$where`, `$regex`, `$ne`, `findOne()` com objeto do usuário |
| XSS (Stored/Reflected/DOM) | `innerHTML`, `document.write`, template literals em DOM, `v-html` |
| Command Injection | `exec()`, `spawn()`, `system()`, `popen()`, backticks |
| SSTI | `render()`, `compile()`, `template()` com string do usuário |
| Path Traversal | `fs.readFile()`, `open()`, `include/require` com concatenação |
| LDAP Injection | `search()`, filtros com concatenação de input |
| XPath Injection | `evaluate()`, `selectNodes()` com concatenação |
| HTTP Header Injection | `setHeader()`, `Location:`, `Set-Cookie:` com input |
| Log Injection | `logger.info()`, `console.log()` com input sem newlines |
| Sanitization Bypass | Qualquer função de escape/sanitize/encode como alvo |
### Delegado para outras skills:
| Fora do escopo | Delegar para |
|---|---|
| RBAC/ABAC bypass | `auth-review` |
| TLS, HSTS, cookie flags | `infra-security` |
| Deserialization | `crypto-review` |
---
## Protocolo de Execução
### Fase 1 — Ingestão e Parse
1. **Receber o código-alvo** — Identificar linguagem, framework, versão.
- Se o usuário enviou arquivos: ler cada um via `file-reading`.
- Se o usuário enviou snippet inline: usar diretamente.
- Se o usuário enviou repositório: solicitar os arquivos específicos ou listar estrutura.
- **Critério de conclusão**: linguagem e framework identificados, todos os arquivos relevantes carregados.
2. **Mapear superfície de entrada (Sources)** — Listar todos os pontos onde dados externos entram.
- HTTP: `req.body`, `req.query`, `req.params`, `req.headers`, cookies, `formData`
- Storage: resultados de DB, mensagens de queue, cache
- Filesystem: `readFile()`, argumentos de CLI, variáveis de ambiente não-controladas
- **Critério de conclusão**: tabela de sources com localização no código (arquivo:linha).
3. **Mapear superfície de saída (Sinks)** — Listar todos os pontos onde dados fluem para interpretadores.
- SQL: chamadas a query builders com strings dinâmicas
- Shell: chamadas a `exec`/`spawn`/`system`
- HTML: `innerHTML`, `dangerouslySetInnerHTML`, `v-html`, `|raw` em templates
- Templates: `render_string()`, `Template(user_string).render()`
- Filesystem: `readFile(path + user_input)`, `include(user_input)`
- **Critério de conclusão**: tabela de sinks com localização no código (arquivo:linha).
4. **Traçar fluxos source→sink** — Para cada source, seguir o dado até cada sink alcançável.
- Usar análise estática mental: variável passa por sanitize? Por concatenação? Por template literal?
- Marcar cada fluxo como: **PARAMETRIZADO** | **SANITIZADO** | **VULNERÁVEL**
- **Critério de conclusão**: lista de fluxos com classificação.
### Fase 2 — Ataque Sistemático
5. **Classificar cada fluxo VULNERÁVEL por tipo de injeção** — Usar a taxonomia da seção "Padrões".
- **Critério de conclusão**: cada fluxo vulnerável rotulado com tipo exato (SQLi-Classic, XSS-DOM-Stored, etc.).
6. **Testar cada sanitização contra bypass** — Para cada fluxo marcado SANITIZADO, tentar bypass:
- Executar os testes da seção "Técnicas de Bypass de Sanitização".
- Verificar se o escape é contextual (escape HTML usado em contexto SQL = bypass).
- **Critério de conclusão**: cada sanitização classificada como EFETIVA ou BYPASSÁVEL, com prova.
7. **Montar prova de conceito para cada finding** — Sequência input → código → output.
- Input: o payload exato que explora a vulnerabilidade
- Código: o trecho vulnerável com highlight da linha exata
- Output: o resultado inseguro (query executada, HTML renderizado, comando executado)
- **Critério de conclusão**: cada finding tem PoC completo e reproduzível.
### Fase 3 — Resiliência e Casos Excepcionais
8. **Testar edge cases de resiliência** — Aplicar os cenários da seção "Casos de Exceção e Resiliência".
- Input vazio, null, undefined, array em vez de string, objeto aninhado, input extremamente longo
- Multi-byte characters, BOM, RTL override, zero-width characters
- **Critério de conclusão**: cada edge case documentado com comportamento observado.
9. **Verificar mitigação de erro** — Se o código tem try/catch, verificar se o erro vaza informação útil.
- Stack traces expostos contêm nomes de tabela, queries parciais, caminhos de arquivo
- **Critério de conclusão**: erros classificados como "seguros" ou "information leak".
### Fase 4 — Geração do Artefato
10. **Classificar severidade** — Usar escala fixa:
- **CRÍTICO**: exploração trivial, impacto imediato (RCE, exfileração de DB inteiro)
- **ALTO**: exploração requer conhecimento mínimo, impacto significativo
- **MÉDIO**: exploração requer condições específicas, impacto limitado
- **BAIXO**: exploração teórica, impacto mínimo (ex: log injection sem consumo downstream)
- **Critério de conclusão**: cada finding com severidade justificada em 1 frase.
11. **Escrever correção exata** — Para cada finding, fornecer o diff exato (antes → depois).
- Nunca sugerir "use sanitize" genérico.
- Sempre especificar a função exata, o contexto e a versão mínima da lib.
- **Critério de conclusão**: cada finding tem diff aplicável sem interpretação.
12. **Montar relatório final** — Estrutura fixa (ver seção "Formato do Artefato de Saída").
- **Critério de conclusão**: relatório completo, formatado em markdown, pronto para consumo.
---
## Padrões Específicos
### Padrão 1 — SQL Injection via Concatenação
**Regra**: Nunca interpolar variáveis em string SQL. Use sempre parameterized queries ou query builder com binding.
```javascript
// ✅ PASS — parameterized query
const result = await db.query('SELECT id, name FROM users WHERE email = $1', [userEmail]);
// ❌ FAIL — concatenação direta
const result = await db.query(`SELECT id, name FROM users WHERE email = '${userEmail}'`);
// ❌ FAIL — template literal
const result = await db.query(`SELECT id, name FROM users WHERE email = ${userEmail}`);
```
```python
# ✅ PASS — parameterized
cursor.execute("SELECT id, name FROM users WHERE email = %s", (user_email,))
# ❌ FAIL — f-string
cursor.execute(f"SELECT id, name FROM users WHERE email = {user_email}")
# ❌ FAIL — string format
cursor.execute("SELECT id, name FROM users WHERE email = '%s'" % user_email)
```
```java
// ✅ PASS — PreparedStatement
PreparedStatement stmt = conn.prepareStatement("SELECT id, name FROM users WHERE email = ?");
stmt.setString(1, userEmail);
// ❌ FAIL — concatenação
Statement stmt = conn.createStatement("SELECT id, name FROM users WHERE email = '" + userEmail + "'");
```
**Por que importa**: Concatenação permite que `userEmail = "' OR 1=1 --"` altere a semântica da query. Parameterized queries separam código de dados no protocolo do banco — o driver nunca interpreta o parâmetro como SQL.
---
### Padrão 2 — SQL Injection em Query Builder com String Dinâmica
**Regra**: Query builders protegem apenas quando usados via API tipada. Strings raw dentro de query builder são tão perigosas quanto SQL puro.
```javascript
// ✅ PASS — API tipada do builder
const users = knex('users').where('email', userEmail).select('id', 'name');
// ❌ FAIL — whereRaw com concatenação
const users = knex('users').whereRaw(`email = '${userEmail}'`).select('id', 'name');
// ❌ FAIL — knex.raw com template literal
const users = knex.raw(`SELECT * FROM users WHERE email = '${userEmail}'`);
```
```python
# ✅ PASS — API tipada
users = User.objects.filter(email=user_email)
# ❌ FAIL — extra() com string
users = User.objects.extra(where=[f"email = '{user_email}'"])
# ❌ FAIL — raw()
users = User.objects.raw(f"SELECT * FROM auth_user WHERE email = '{user_email}'")
```
**Por que importa**: `whereRaw`, `knex.raw`, `.extra()`, `.raw()` são escapes que desabilitam a proteção do builder. O dado vira string SQL novamente.
---
### Padrão 3 — SQL Injection em Order By / Column Name Dinâmico
**Regra**: Nomes de coluna e direções de ordenação não podem ser parametrizados — use whitelist.
```javascript
// ✅ PASS — whitelist de colunas válidas
const ALLOWED_COLUMNS = ['name', 'created_at', 'email'];
const ALLOWED_DIRS = ['ASC', 'DESC'];
const col = ALLOWED_COLUMNS.includes(sortCol) ? sortCol : 'created_at';
const dir = ALLOWED_DIRS.includes(sortDir?.toUpperCase()) ? sortDir.toUpperCase() : 'ASC';
const result = await db.query(`SELECT id, name FROM users ORDER BY ${col} ${dir}`);
// ❌ FAIL — interpolação direta
const result = await db.query(`SELECT id, name FROM users ORDER BY ${sortCol} ${sortDir}`);
// Payload: sortCol = "id; DROP TABLE users; --"
```
```python
# ✅ PASS — whitelist
ALLOWED_COLUMNS = {'name', 'created_at', 'email'}
col = sort_col if sort_col in ALLOWED_COLUMNS else 'created_at'
users = User.objects.order_by(col)
# ❌ FAIL — .order_by com input direto
users = User.objects.order_by(sort_col)
```
**Por que importa**: Nenhum driver SQL suporta parameterizar nomes de coluna ou keywords. Placeholder `?` em `ORDER BY ?` resulta em erro ou aspas literais. Whitelist é a única defesa correta.
---
### Padrão 4 — SQL Injection de Segunda Ordem
**Regra**: Dado sanitizado na inserção mas reusado sem sanitização em query posterior é vulnerável.
```javascript
// ❌ FAIL — sanitized no INSERT, mas o valor armazenado é usado raw depois
// Passo 1: INSERT (seguro via parameterized)
await db.query('INSERT INTO users (name, email) VALUES ($1, $2)', [userName, userEmail]);
// Passo 2: SELECT usando o valor armazenado (a coluna contém dado não sanitizado)
const row = await db.query("SELECT * FROM users WHERE name = '" + row.name + "'");
// Se row.name = "admin' --" (armazenado literalmente), a query é injetada
```
```javascript
// ✅ PASS — parameterized em TODOS os usos
const row = await db.query('SELECT * FROM users WHERE name = $1', [row.name]);
```
**Por que importa**: Sanitização no INSERT protege a escrita, mas o valor no banco é o original. Qualquer leitura subsequente que não use parameterized query é vulnerável.
---
### Padrão 5 — NoSQL Injection
**Regra**: Nunca passar objeto construído com input do usuário diretamente como filtro de query.
```javascript
// ❌ FAIL — objeto do usuário como filtro
app.post('/login', (req, res) => {
// req.body = { "email": {"$ne": ""}, "password": {"$ne": ""} }
db.users.findOne(req.body); // bypass completo de autenticação
});
// ❌ FAIL — spread do input no filtro
db.users.findOne({ ...req.body, active: true });
// req.body = { "password": { "$gt": "" } } → retorna qualquer senha
// ✅ PASS — campos explícitos com valores escalares
db.users.findOne({
email: req.body.email, // string escalar, operadores ignorados
password: hashedPassword, // string escalar
active: true
});
```
```python
# ❌ FAIL — dict do request como filtro
users.find_one(request.json)
# ✅ PASS — campos explícitos
users.find_one({"email": request.json.get("email"), "active": True})
```
**Por que importa**: MongoDB/Mongoose aceitam operadores como `$ne`, `$gt`, `$regex`, `$where` como valores. Se o usuário controla a estrutura do objeto, controla a query.
---
### Padrão 6 — NoSQL Injection via $where / $regex
**Regra**: `$where` executa JavaScript no servidor. `$regex` permite denial of service via backtracking. Bloqueie ambos de input do usuário.
```javascript
// ❌ FAIL — $where permite execução arbitrária
db.users.findOne({ $where: `this.username === '${username}'` });
// Payload: username = "'; sleep(5000); '"
// ❌ FAIL — $regex com input do usuário causa ReDoS
db.users.findOne({ email: { $regex: userInput } });
// Payload: userInput = "(a+)+$" → backtracking catastrófico
// ✅ PASS — usar operadores escalares
db.users.findOne({ username: username }); // sem $where, sem $regex
```
**Por que importa**: `$where` é eval disfarçado de query. `$regex` com input não-validado é vetor de ReDoS que derruba o banco.
---
### Padrão 7 — XSS Refletido via Template Sem Escape
**Regra**: Templates devem escapar por padrão. Escape manual só se o contexto exigir (ex: atributo HTML vs. contexto JavaScript).
```html
{{{ userComment }}}
{{ comment|raw }}
<%= raw(comment) %>
```
```html
{{ userComment }}
{{ comment }}
{comment}
{{ comment }}
<%= comment %>
```
**Por que importa**: O escape automático do template engine converte `"
// O HTML encoder não escapa aspas e quebra a tag script
"
'>
```
**Por que importa**: HTML entities (`<`) são interpretadas literalmente dentro de `` antes do parser JavaScript, quebrando o contexto. É necessário sanitizar para o contexto específico.
---
### Padrão 9 — XSS via DOM (Source: URL hash, Sink: innerHTML)
**Regra**: innerHTML com dado de `location.hash`, `location.search`, `document.referrer` ou `postMessage` é sempre vulnerável.
```javascript
// ❌ FAIL — hash direto em innerHTML
document.getElementById('content').innerHTML = location.hash.slice(1);
// URL: page.html#
// ❌ FAIL — referrer em innerHTML
document.getElementById('welcome').innerHTML = `Bem-vindo, ${document.referrer}`;
// ✅ PASS — textContent (nunca parseia HTML)
document.getElementById('content').textContent = location.hash.slice(1);
// ✅ PASS — DOMPurify se HTML for necessário
document.getElementById('content').innerHTML = DOMPurify.sanitize(location.hash.slice(1));
```
**Por que importa**: DOM XSS não aparece no HTML fonte — ocorre em runtime no browser. `textContent` é a defesa mais simples e infalível quando HTML não é necessário.
---
### Padrão 10 — Command Injection
**Regra**: Nunca interpolar input do usuário em string de comando. Use API com array de argumentos.
```javascript
// ❌ FAIL — exec com string concatenada
const { exec } = require('child_process');
exec(`convert ${userFile} -resize 50% output.jpg`);
// Payload: userFile = "clean.jpg; rm -rf /"
// ❌ FAIL — exec com template literal
exec(`ping -c 3 ${userHost}`);
// Payload: userHost = "8.8.8.8; cat /etc/passwd"
// ✅ PASS — execFile com array de argumentos
const { execFile } = require('child_process');
execFile('convert', [userFile, '-resize', '50%', 'output.jpg'], (err, stdout) => { ... });
// Payload não funciona: userFile é passado como argumento único, não interpretado por shell
// ✅ PASS — spawn (ainda mais seguro, stream-based)
const { spawn } = require('child_process');
const child = spawn('convert', [userFile, '-resize', '50%', 'output.jpg']);
```
```python
# ❌ FAIL — os.system com f-string
os.system(f"convert {user_file} -resize 50% output.jpg")
# ❌ FAIL — subprocess.run com shell=True
subprocess.run(f"convert {user_file} -resize 50% output.jpg", shell=True)
# ✅ PASS — subprocess.run com lista, shell=False (padrão)
subprocess.run(['convert', user_file, '-resize', '50%', 'output.jpg'], check=True)
```
**Por que importa**: `exec()` e `shell=True` invocam `/bin/sh -c "string"`, onde `;`, `|`, `&&`, `$(...)`, backticks são metacaracteres do shell. `execFile`/`spawn`/`subprocess.run(list)` chamam o executável diretamente via `execve()` — sem shell, sem metacaracteres.
---
### Padrão 11 — Command Injection via Argument Injection (sem shell)
**Regra**: Mesmo sem shell, argumentos podem injetar flags perigosas. Valide o formato esperado.
```javascript
// ❌ FAIL — sem shell, mas argumento injeta flag
execFile('curl', [userUrl, '-o', 'output.html']);
// Payload: userUrl = "-o /etc/cron.d/backdoor" → sobrescreve arquivo do sistema
// ✅ PASS — validar que input corresponde ao formato esperado
const urlPattern = /^https?:\/\/[a-zA-Z0-9._~:/?#\[\]@!$&'()*+,;=%-]+$/;
if (!urlPattern.test(userUrl)) throw new Error('URL inválida');
execFile('curl', [userUrl, '-o', 'output.html']);
```
```python
# ❌ FAIL — argumento injeta flag no tar
subprocess.run(['tar', '-czf', user_filename, '/data'])
# Payload: user_filename = "--to-command=malicious_script.sh /tmp/x"
# ✅ PASS — validar formato de filename
if not re.match(r'^[a-zA-Z0-9_\-\.]+\.tar\.gz$', user_filename):
raise ValueError("Nome de arquivo inválido")
subprocess.run(['tar', '-czf', user_filename, '/data'])
```
**Por que importa**: Sem shell, `;` e `|` não funcionam. Mas `-` inicia flags em utilitários Unix. Um atacante pode injetar `--to-command`, `-o`, `--data` dependendo do binário. Validação de formato é essencial.
---
### Padrão 12 — Server-Side Template Injection (SSTI)
**Regra**: Nunca renderizar string do usuário como template. Templates devem ser arquivos estáticos do servidor.
```python
# ❌ FAIL — string do usuário como template Jinja2
from jinja2 import Template
template = Template(user_input) # user_input = "{{ ''.__class__.__mro__[1].__subclasses__() }}"
template.render()
# ❌ FAIL — render_template_string com input
from flask import render_template_string
render_template_string(user_input)
# ✅ PASS — template como arquivo estático
from flask import render_template
render_template('user_profile.html', username=username) # username é variável, não template
```
```javascript
// ❌ FAIL — template literal do usuário como template EJS
const ejs = require('ejs');
ejs.render(userInput, data);
// Payload: "<%= process.exit() %>"
// ✅ PASS — arquivo de template
ejs.renderFile('./views/user.ejs', { username });
```
**Por que importa**: Template engines como Jinja2, EJS, Pug, Twig têm acesso ao objeto de contexto e frequentemente ao runtime da linguagem. `{{ ''.__class__ }}` em Jinja2 acessa a hierarquia de classes Python, permitindo RCE.
---
### Padrão 13 — Path Traversal
**Regra**: Nunca concatenar input do usuário em caminho de arquivo. Use `path.resolve` + verificação de prefixo ou whitelist.
```javascript
// ❌ FAIL — concatenação direta
const filePath = `/uploads/${userFilename}`;
fs.readFile(filePath);
// Payload: userFilename = "../../etc/passwd"
// ❌ FAIL — path.join não previne traversal
const filePath = path.join('/uploads', userFilename);
fs.readFile(filePath);
// Payload: userFilename = "../../etc/passwd" → path.join normaliza para "/etc/passwd"
// ✅ PASS — resolve + verificação de prefixo
const basePath = path.resolve('/uploads');
const filePath = path.resolve(path.join(basePath, userFilename));
if (!filePath.startsWith(basePath + path.sep)) {
throw new Error('Path traversal detectado');
}
fs.readFile(filePath);
// ✅ PASS — whitelist de extensões
const ALLOWED_EXT = ['.jpg', '.png', '.gif', '.pdf'];
const ext = path.extname(userFilename).toLowerCase();
if (!ALLOWED_EXT.includes(ext)) throw new Error('Extensão não permitida');
```
```python
# ❌ FAIL — os.path.join não previne traversal
filepath = os.path.join('/uploads', user_filename)
# ✅ PASS — resolve + startswith
base = os.path.realpath('/uploads')
filepath = os.path.realpath(os.path.join(base, user_filename))
if not filepath.startswith(base + os.sep):
raise ValueError('Path traversal detectado')
```
**Por que importa**: `path.join` e `os.path.join` resolvem `..` — eles normalizam o caminho. A defesa é verificar se o caminho resultante está dentro do diretório permitido após normalização completa (`realpath`/`resolve`).
---
### Padrão 14 — Path Traversal via Null Byte (Legacy)
**Regra**: Em PHP < 5.3.4 e C APIs antigas, null byte (`%00`) truncava o caminho. Verifique em código legado.
```php
// ❌ FAIL — null byte truncava o caminho em PHP < 5.3.4
$file = "/uploads/" . $_GET['file'];
include($file);
// Payload: ?file=../../etc/passwd%00.jpg → include("/etc/passwd")
// ✅ PASS — verificação antes de usar + versão do PHP atualizada
$file = basename($_GET['file']); // remove path components
$fullPath = '/uploads/' . $file;
if (!file_exists($fullPath)) die('Not found');
include($fullPath);
```
**Por que importa**: Embora corrigido em versões modernas, código legado pode ainda estar rodando em PHP antigo. `basename()` é a defesa mais simples pois remove tudo exceto o nome do arquivo.
---
### Padrão 15 — LDAP Injection
**Regra**: Nunca concatenar input do usuário em filtro LDAP. Escape caracteres especiais LDAP.
```java
// ❌ FAIL — concatenação em filtro
String filter = "(uid=" + username + ")";
ctx.search("ou=users,dc=example,dc=com", filter, controls);
// Payload: username = "admin)(|(password=*))" → retorna todos os usuários
// ✅ PASS — escape de caracteres especiais LDAP
String escapeLDAP(String input) {
return input.replace("\\", "\\5c")
.replace("*", "\\2a")
.replace("(", "\\28")
.replace(")", "\\29")
.replace("\u0000", "\\00");
}
String filter = "(uid=" + escapeLDAP(username) + ")";
```
**Por que importa**: Caracteres `*`, `(`, `)` e `\` têm significado especial em filtros LDAP. Sem escape, o atacante modifica a lógica do filtro.
---
### Padrão 16 — HTTP Header Injection
**Regra**: Nunca incluir input do usuário em headers HTTP sem remover CRLF (`\r\n`).
```javascript
// ❌ FAIL — input em header sem sanitização
res.setHeader('X-Custom-Header', userValue);
// Payload: userValue = "test\r\nSet-Cookie: session=stolen"
// Resultado: header extra injetado
// ❌ FAIL — redirect com input
res.redirect(`/callback?next=${userRedirect}`);
// Payload: userRedirect = "https://evil.com\r\nX-Frame-Options: ALLOW-ALL"
// ✅ PASS — remover CRLF
function sanitizeHeader(value) {
return value.replace(/[\r\n]/g, '');
}
res.setHeader('X-Custom-Header', sanitizeHeader(userValue));
// ✅ PASS — URL whitelist para redirect
const ALLOWED_REDIRECTS = ['/dashboard', '/profile', '/settings'];
const safeRedirect = ALLOWED_REDIRECTS.includes(userRedirect) ? userRedirect : '/dashboard';
res.redirect(safeRedirect);
```
**Por que importa**: CRLF (`\r\n`) é o delimitador de headers HTTP. Injetar CRLF em um header permite ao atacante adicionar headers arbitrários (response splitting) ou, em casos raros, injetar corpo de resposta.
---
### Padrão 17 — Log Injection
**Regra**: Entradas de log com newlines ou sequências de controle podem falsificar entradas ou enganar parsers.
```javascript
// ❌ FAIL — input do usuário em log sem sanitização
logger.info(`Login attempt: username=${username}, ip=${ip}`);
// Payload: username = "admin\n[ERROR] Database connection failed\n[INFO] Admin login successful"
// Resultado: log falsificado parece conter erro de DB + login admin bem-sucedido
// ✅ PASS — remover newlines e caracteres de controle
function sanitizeLog(value) {
return String(value).replace(/[\r\n\t\x00-\x1f\x7f]/g, ' ');
}
logger.info(`Login attempt: username=${sanitizeLog(username)}, ip=${sanitizeLog(ip)}`);
```
**Por que importa**: Ferramentas de SIEM, ELK e Datadog parseiam newlines como separadores de evento. Log injection pode falsificar alertas de segurança ou mascarar ataques reais.
---
## Técnicas de Bypass de Sanitização
Estas técnicas devem ser aplicadas contra CADA função de sanitização encontrada no código.
### Bypass 1 — Double Encoding
```javascript
// Sanitização: decode once, then validate
function sanitize(input) {
const decoded = decodeURIComponent(input);
if (decoded.includes(' (executa)
```
**Defesa**: Decodificar iterativamente até que o resultado seja estável antes de validar.
```javascript
function fullDecode(input) {
let prev = '';
let current = input;
while (current !== prev) {
prev = current;
try { current = decodeURIComponent(current); } catch { break; }
}
return current;
}
```
---
### Bypass 2 — Unicode Normalization
```javascript
// Sanitização: verifica por ';
// ...se o regex não tiver 'i' flag, passa
```
**Defesa**: Decodificar TODAS as representações antes de aplicar regex.
---
### Bypass 5 — HTML Parser Diferenças entre Browsers
```html