Pourquoi wget et curl sont-ils indispensables face aux URL infectées par malware ?

Qu'est-ce qu'une infection par error template exactement ?

Une infection par error template consiste en l'injection de code malveillant dans les fichiers de templates d'erreur (404, 500, etc.) d'un CMS. Les attaquants profitent du fait que ces fichiers sont rarement surveillés et peuvent servir des milliers de pages infectées sans éveiller immédiatement les soupçons.

Le piège classique : ces pages infectées se chargent différemment selon le user-agent. Quand vous les ouvrez dans Chrome ou Firefox, le script détecte un visiteur humain et déclenche des redirections malveillantes, du cloaking ou pire. Wget et curl, eux, récupèrent le code HTML brut sans exécuter JavaScript, ce qui permet d'examiner la structure réelle sans déclencher les mécanismes d'infection.

Pourquoi un navigateur standard expose-t-il votre machine ?

Les navigateurs modernes exécutent JavaScript, chargent des iframes, suivent les redirections et interprètent l'ensemble du DOM. Sur une URL infectée, cela signifie que le code malveillant s'active et peut tenter d'exploiter des failles, installer des scripts trackers, ou rediriger vers des pages phishing.

Les outils en ligne de commande comme wget ou curl ne font qu'une chose : récupérer le contenu brut de la réponse HTTP. Pas d'interprétation, pas d'exécution. Vous obtenez exactement ce que le serveur renvoie, ce qui permet d'identifier les injections de spam SEO, les redirections 302 suspectes ou les balises meta refresh cachées.

Comment wget et curl s'intègrent-ils dans un audit de piratage SEO ?

Quand Google vous notifie d'un problème de contenu piraté via Search Console, la première étape consiste à identifier l'étendue de l'infection. Wget permet de crawler rapidement un échantillon d'URL suspectes et d'extraire les patterns communs : présence de liens externes vers des domaines pharmaceutiques, balises title modifiées, scripts injectés dans le head.

Curl, lui, est idéal pour inspecter les en-têtes HTTP et repérer des redirections conditionnelles (basées sur le referer ou l'IP). Combinez les deux avec grep et vous pouvez automatiser la détection de signatures malveillantes sur des centaines d'URL en quelques minutes. C'est le workflow standard de tout professionnel confronté à un hack massif.

• Wget/curl évitent l'exécution de code malveillant lors de l'inspection d'URL compromises
• Les navigateurs classiques déclenchent les mécanismes d'infection (JavaScript, redirections, iframes)
• Ces outils permettent l'analyse des en-têtes HTTP bruts et du code source sans interprétation
• Ils s'intègrent dans des scripts d'audit automatisés pour traiter des volumes importants d'URL suspectes
• Google recommande cette approche officiellement pour protéger les machines des professionnels SEO

Cette recommandation reflète-t-elle les pratiques réelles des SEO chevronnés ?

Absolument. Tout professionnel ayant géré un site piraté sait que la première règle est de ne jamais ouvrir directement les URL suspectes depuis sa machine de travail. L'usage de wget ou curl est documenté dans toutes les ressources sérieuses sur le nettoyage de hacks SEO, bien avant que Google ne le formalise.

Ce qui est intéressant ici, c'est que Google le mentionne explicitement dans un contexte d'error template. Cela suggère qu'ils ont observé une recrudescence de ce vecteur d'attaque spécifique et que trop de webmasters continuent à inspecter ces pages à la main, contaminant leurs machines au passage. [A vérifier] si cette recommandation s'accompagne d'une détection accrue côté Search Console.

Quelles limites faut-il avoir en tête avec cette approche ?

Wget et curl montrent ce que le serveur renvoie à un user-agent en ligne de commande. Le problème : les infections modernes sont souvent contextuelles. Elles servent du contenu propre aux bots Google et du contenu malveillant aux visiteurs humains, ou seulement aux IP hors États-Unis, ou seulement après le premier clic.

Si le malware détecte un user-agent curl/wget, il peut servir une version clean. Dans ces cas, vous devez forcer l'user-agent Googlebot ou utiliser des outils comme Puppeteer en mode headless avec des proxies variés. La recommandation de Google reste valide pour une première inspection, mais elle ne couvre pas les cas de cloaking avancé. Un audit complet nécessite plusieurs approches combinées.

Que faire si l'infection persiste malgré le nettoyage visible ?

C'est la situation classique : vous nettoyez les templates, vous passez wget sur 50 URL échantillons, tout semble propre, et Google continue de signaler du contenu piraté. Le malware s'est probablement propagé dans la base de données (champs custom, widgets, menus), dans le .htaccess avec des règles RewriteCond complexes, ou pire, dans un plugin ou thème obfusqué.

Wget/curl ne détectent que ce qui transite en HTTP. Ils ne fouillent pas vos fichiers PHP à la recherche de backdoors encodés en base64. Vous devez compléter avec des scanners serveur comme maldet, des audits de permissions fichiers, et une revue manuelle du code. Si vous trouvez du code suspect mais propre via wget, c'est que l'infection se cache ailleurs.

Comment utiliser concrètement wget et curl pour auditer des URL infectées ?

Commencez par récupérer une liste d'URL échantillons depuis Search Console (section Sécurité ou Problèmes de contenu piraté). Exportez 20 à 50 URL suspectes. Lancez wget avec l'option --user-agent pour simuler Googlebot : wget --user-agent="Mozilla/5.0 (compatible; Googlebot/2.1)" -O output.html "https://example.com/infected-page".

Avec curl, vérifiez d'abord les en-têtes HTTP : curl -I "https://example.com/infected-page". Repérez les redirections 301/302 suspectes, les headers X-Redirect ajoutés, ou des Set-Cookie inhabituels. Ensuite, récupérez le body complet : curl -A "Googlebot" "https://example.com/infected-page" > page.html et grep les patterns typiques (iframe, document.write, eval, pharma keywords).

Quelles erreurs éviter lors de l'investigation ?

Ne testez jamais depuis le réseau du client directement si le serveur est compromis. Certains malwares whitelistent les IP locales et ne servent l'infection qu'aux visiteurs externes. Utilisez un VPN ou testez depuis un serveur tiers pour obtenir une vue réaliste.

Autre piège : se contenter d'un seul test wget. Les infections conditionnelles changent de comportement selon l'heure, le referer, ou le nombre de visites. Lancez plusieurs passes avec des user-agents variés (Desktop Chrome, Mobile Safari, Googlebot, Bingbot) et comparez les résultats. Si les réponses diffèrent, vous avez du cloaking actif.

Comment automatiser la détection sur des centaines d'URL ?

Créez un script bash qui boucle sur votre liste d'URL, exécute wget pour chacune, et filtre les résultats avec grep. Exemple : chercher toutes les occurrences de "viagra" ou "casino" dans les titles. Vous pouvez aussi parser le HTML avec xmllint ou pup pour extraire automatiquement les balises suspectes.

Pour les sites volumineux, combinez avec Screaming Frog en mode custom extraction : configurez des regex pour détecter les patterns malveillants dans le code source. Screaming Frog utilise un moteur headless qui n'exécute pas JavaScript par défaut, donc c'est plus sûr qu'un navigateur classique, même si wget/curl restent la référence pour les cas critiques.

• Récupérer la liste des URL suspectes depuis Search Console (section Sécurité)
• Utiliser wget/curl avec user-agent Googlebot pour obtenir le rendu serveur brut
• Comparer les réponses avec différents user-agents pour détecter le cloaking
• Parser le HTML avec grep, xmllint ou scripts Python pour identifier les injections
• Vérifier les en-têtes HTTP (redirections, cookies, headers custom suspects)
• Ne jamais tester depuis le réseau du serveur compromis (whitelist IP possible)