Dependency Chain Attack (npm)

Vetor real: invasores comprometem um pacote npm popular (typosquatting, account takeover do mantenedor, ou malicious update) e publicam uma versão com malware. Se seu package.json usa ^ ou ~ (range versions) em vez de versão exata, npm install puxa a versão comprometida. O malware roda no postinstall script e pode roubar environment variables, injetar código no bundle, ou abrir backdoor. Casos reais: event-stream (2018), ua-parser-js (2021), coa/rc (2021). O que testamos: (a) se suas dependências têm versões fixas ou range, (b) se há scripts postinstall, (c) se npm audit encontra vulnerabilidades conhecidas.

Passo 1 — Verificar versões fixas vs range no package.json:

cd /d/Antigravity-Monetizacao_TikTok/app
grep -E '"\^|"~' package.json | head -20

Resultado esperado:

"next": "^16.3.4",
"react": "^19.1.0",
...

🔍 ^ e ~ permitem que npm install puxe versões mais novas automaticamente — se um pacote for comprometido, você instala a versão maliciosa.

Passo 2 — Verificar scripts postinstall (execução automática):

cd /d/Antigravity-Monetizacao_TikTok/app
grep -A5 '"scripts"' package.json | grep -i "postinstall\|preinstall"
# Verificar scripts em dependências:
npm ls --all 2>/dev/null | grep -i "postinstall" | head -10

Resultado esperado: vazio (nenhum postinstall explícito). ✅ Bom — mas dependências transitivas podem ter.

Passo 3 — npm audit (vulnerabilidades conhecidas):

cd /d/Antigravity-Monetizacao_TikTok/app
npm audit --json 2>/dev/null | python -c "
import sys, json
d = json.load(sys.stdin)
vulns = d.get('vulnerabilities', {})
print(f'Total de vulnerabilidades: {len(vulns)}')
for name, info in vulns.items():
    print(f'  {name}: {info.get(\"severity\", \"?\")} — {info.get(\"via\", \"?\")}')
" 2>/dev/null || echo "npm audit indisponível ou sem vulnerabilidades"

Resultado esperado (validado anteriormente): 0 vulnerabilidades conhecidas. ✅ Bom — mas npm audit só conhece CVEs publicados, não ataques em andamento.

Passo 4 — Verificar integrity hashes no lockfile:

cd /d/Antigravity-Monetizacao_TikTok/app
grep -c "integrity" package-lock.json
# Cada dependência DEVE ter um integrity hash (sha512). Se faltar, npm não verifica.

Resultado esperado: número alto (centenas) — cada pacote tem hash de integridade. ✅

Passo 5 — Simular ataque de typosquatting (o que o invasor faz):

# Atacante registra no npm um pacote com nome parecido:
# - "nxt" (em vez de "next")
# - "reactt" (em vez de "react")
# - "supabase-js" (em vez de "@supabase/supabase-js")
# Se alguém digita errado no package.json, instala o malicioso.
# Verificar se TODAS as dependências são os nomes corretos:
cd /d/Antigravity-Monetizacao_TikTok/app
cat package.json | python -c "
import sys, json
d = json.load(sys.stdin)
deps = {**d.get('dependencies', {}), **d.get('devDependencies', {})}
known_typos = ['nxt', 'reactt', 'supabase-js', 'nextjs', 'react-router-dom4']
for name in deps:
    if name.lower() in [t.lower() for t in known_typos]:
        print(f'⚠️ Possível typo: {name}')
    else:
        print(f'✅ {name}: {deps[name]}')
"

Análise — como invasores usam dependency attacks:

1. Typosquatting: registram nxt no npm. Desenvolvedor digita nxt em vez de next. Instala malware.
2. Account takeover: invasor compra/phishinga a conta npm de um mantenedor popular. Publica versão 1.2.3 com backdoor.
3. Dependency confusion: se você tem um pacote interno @mycompany/utils e o invasor registra @mycompany/utils no npm público, npm install pode puxar o público (malicioso) em vez do privado.
4. postinstall malware: o script roda com as permissões do CI/CD — rouba process.env, envia para webhook, modifica node_modules para injetar no bundle.