Wget et cURL suffisent-ils vraiment pour détecter toutes les redirections malveillantes ?

Pourquoi Google conseille-t-il ces outils plutôt que d'autres méthodes ?

Wget et cURL sont des utilitaires en ligne de commande universels qui permettent d'envoyer des requêtes HTTP brutes sans navigateur. Leur principal avantage est qu'ils révèlent les headers de réponse complets, y compris les codes de statut 301, 302, 307 et les URLs de destination.

Les hackers exploitent souvent des redirections conditionnelles qui se déclenchent selon l'user-agent, l'adresse IP ou le referer. Un navigateur classique ou la Search Console peuvent masquer ces comportements, tandis que Wget et cURL laissent une trace complète des redirections successives et des paramètres transmis.

Quels types de piratages ces outils permettent-ils de repérer ?

Les injections de redirections malveillantes visent généralement à détourner le trafic organique vers des sites de phishing, spam pharmaceutique ou malware. Le schéma classique : un fichier .htaccess compromis redirige GoogleBot ou les visiteurs vers une destination externe, souvent avec un code 302 temporaire pour éviter l'alerte.

Wget avec l'option --max-redirect=10 --spider suit la chaîne complète sans télécharger le contenu, exposant chaque saut. cURL avec -I -L affiche les headers de chaque étape. Ces outils détectent aussi les redirections en cascade : page A vers B, puis B vers C, masquant l'origine du piratage.

Ces méthodes sont-elles efficaces contre tous les scénarios de hack ?

Non, et c'est là que ça coince. Wget et cURL capturent uniquement les redirections HTTP au niveau serveur. Ils sont aveugles aux redirections JavaScript (window.location, meta refresh), aux iframes cachées et aux cloakings sophistiqués qui analysent le fingerprint du client.

Un hacker compétent peut servir un contenu propre à un user-agent curl/wget et rediriger uniquement les vrais navigateurs. Pour ces cas, il faut combiner avec des outils headless comme Puppeteer ou des services de crawl avec rendu JavaScript complet.

• Wget et cURL exposent les redirections HTTP serveur brutes et les chaînes de sauts
• Ils révèlent les codes de statut (301, 302, 307) souvent utilisés dans les hacks
• Ces outils ne détectent pas les redirections JavaScript ou les cloakings basés sur fingerprinting
• La commande curl -I -L https://example.com affiche tous les headers de redirection
• L'option wget --max-redirect=10 --spider suit jusqu'à 10 sauts sans télécharger le contenu

Cette recommandation est-elle suffisante pour un audit complet ?

Soyons honnêtes : Wget et cURL sont un point de départ nécessaire, mais loin d'être exhaustif. Sur le terrain, les redirections malveillantes que je vois en audit se divisent en deux familles : les piratages amateurs (fichiers .htaccess modifiés, redirections 302 brutales) et les attaques sophistiquées qui ciblent GoogleBot avec un cloaking JS.

Les outils CLI détectent la première catégorie sans problème. Pour la seconde, il faut impérativement tester avec un user-agent GoogleBot réel et un moteur de rendu JavaScript. J'ai vu des sites propres en curl mais qui servaient du spam pharma aux crawlers Google. [A vérifier] sur vos propres URLs avec plusieurs user-agents différents.

Quelles limites terrain faut-il connaître avant d'utiliser ces outils ?

Première limite : les hackers savent que les SEO testent avec curl. Certains scripts détectent l'user-agent curl/wget et servent un comportement propre, réservant la redirection aux navigateurs standards. Il faut donc modifier l'user-agent avec curl -A "Mozilla/5.0..." pour simuler un vrai visiteur.

Deuxième piège : les redirections conditionnelles basées sur l'IP. Un hacker peut rediriger uniquement les IP hors datacenter, ce qui rend le test depuis un serveur AWS inefficace. Testez depuis plusieurs sources : votre connexion locale, un VPN résidentiel, un proxy mobile. Et vérifiez toujours les pages de pagination et les URLs avec paramètres, rarement protégées.

Dans quels cas cette méthode peut-elle donner des faux négatifs ?

Les redirections JavaScript asynchrones passent totalement sous le radar. Exemple : un script attend 3 secondes puis redirige via setTimeout(() => location.href = ...). Wget et cURL sortent immédiatement après avoir reçu le HTML, ils ne voient jamais cette redirection.

Autre cas classique : les iframes masquées chargées depuis un domaine externe. Le serveur répond 200 OK, le HTML semble propre, mais une iframe 1x1 pixel charge du contenu malveillant. Pour ces scénarios, il faut parser le DOM avec un outil qui exécute le JavaScript et analyse les ressources chargées.

Comment utiliser concrètement Wget et cURL pour auditer ses redirections ?

Commencez par lister vos URLs stratégiques : pages principales, pages de catégorie, anciens contenus redirigés. Pour chaque URL, lancez curl -I -L https://example.com/page. L'option -I récupère uniquement les headers, -L suit les redirections. Notez chaque code de statut et URL de destination.

Avec Wget, utilisez wget --spider --max-redirect=10 --server-response https://example.com/page. L'option --spider simule un crawl sans télécharger, --server-response affiche tous les headers HTTP. Comparez les résultats avec plusieurs user-agents : curl par défaut, GoogleBot desktop, GoogleBot mobile, navigateur standard.

Quelles erreurs faut-il absolument éviter lors du diagnostic ?

Erreur numéro un : tester uniquement la homepage. Les hackers injectent souvent leurs redirections sur des pages profondes, des URLs avec paramètres ou des anciennes URLs indexées. Exportez votre sitemap et testez un échantillon aléatoire de 50-100 URLs, pas juste les pages principales.

Deuxième erreur : ignorer les codes 302. Beaucoup de SEO se focalisent sur les 301, alors que les redirections temporaires 302 sont un signal classique de piratage. Un 302 vers un domaine externe que vous ne reconnaissez pas doit déclencher une alerte immédiate. Vérifiez aussi les chaînes de redirections : A vers B, puis B vers C. Toute cascade de plus de 2 sauts mérite investigation.

Quelle stratégie de monitoring mettre en place pour détecter les futures intrusions ?

Automatisez un script cron qui teste vos 20-30 URLs clés chaque nuit avec curl et vous alerte par email si un code de statut change ou si une nouvelle redirection apparaît. Loggez les résultats dans un fichier CSV pour suivre l'historique. Combinez avec une surveillance de vos fichiers sensibles : .htaccess, wp-config.php, functions.php.

Intégrez aussi un monitoring de Search Console : les pics soudains d'erreurs 404, les chutes d'impressions sur des pages spécifiques ou les nouvelles URLs indexées inconnues sont souvent les premiers signaux d'un hack. Croisez ces alertes avec vos tests curl pour confirmer rapidement.

• Testez un échantillon aléatoire d'au moins 50 URLs, pas seulement la homepage
• Variez les user-agents : curl par défaut, GoogleBot, navigateurs standards
• Surveillez tous les codes 302 vers des domaines externes inconnus
• Automatisez un contrôle quotidien de vos URLs stratégiques avec curl en cron
• Croisez les résultats avec Search Console : pics d'erreurs 404, chutes d'impressions
• Vérifiez l'intégrité de vos fichiers sensibles (.htaccess, wp-config.php)