Décryptage d’une nuit ordinaire sur les sites web de Nomios : l’intérêt concret d’un WAF

Les attaques offusquées : contourner les protections et détecter les failles

Une partie notable des attaques observées est volontairement offusquée.
Les requêtes contiennent un mélange de :

• commentaires SQL imbriqués (/*!50000*/, /**/, /*random*/),
• chaînes encodées (%2F%2A, %2527, %22),
• fonctions détournées (CHR(126), CTXSYS.DRITHSX.SN()),
• constructions tordues pour échapper aux filtres.

Exemple d’attaque offusquée observée :

?clearCookie=test%2F%2A%2150000AnD%2A%2F%2F%2A%2A%2F8301%3DCTX
syS.DrIthsx.sn%283624%2CCHr%28126%29%7C%7C%27~%27%7C%7C%28%2F%
2A%2150000SElecT%2A%2F%2F%2A%2A%2F%28%2F%2A%2150000CAse%2A%
2F%2F%2A%2A%2F%2F%2A%2150000When%2A%2F%2F%2A%2A%2F%288301%
3D8301%29%2F%2A%2A%2F%2F%2A%2150000tHeN%2A%2F%2F%2A%2A%2F1%
2F%2A%2A%2F%2F%2A%2150000ELsE%2A%2F%2F%2A%2A%2F0%2F%2A%2A%
2F%2F%2A%2150000End%2A%2F%29%2F%2A%2A%2F%2F%2A%2150000fRoM
%2A%2F%2F%2A%2A%2FDUAL%29%7C%7C%27~%27%7C%7Cchr%28126%29%29%23

Ce que cherche l’attaquant

• Échapper aux protections basiques ou aux WAF mal configurés.
• Tester une injection SQL tout en rendant le payload difficile à détecter.
• Déduire si le serveur renvoie un comportement différent (erreur, délai, contenu HTML).
• S’assurer que la requête est interprétée par la base sans que le mot “SELECT” ou “UNION” n’apparaisse clairement.

Ces attaques offusquées prouvent que les attaquants automatisés utilisent des outils modernes capables de générer des milliers de variations d’un même payload.
Sans un WAF avancé, un simple filtre applicatif ne peut pas suffire.

Injections SQL : comprendre les tests de reconnaissance

Les attaques par injection SQL restent l’un des tests les plus courants. La plupart des requêtes observées ressemblent à ceci :

?clearCookie=test%2F%2A%2150000AnD%2A%2F...CASE WHEN (8301=8301) THEN 1 ELSE 0 END...

Ce que cherche l’attaquant

• Vérifier si un paramètre influence une requête SQL.
• Identifier une différence dans la réponse (erreur, délai).
• Confirmer l’existence d’une faille avant exploitation.

Pourquoi un WAF est utile

Un WAF moderne reconnaît ces patterns — même obfusqués — et bloque la tentative avant que l’application ne renvoie des informations utiles.
Sans retour d’erreur, l’attaquant ne peut pas savoir si une faille existe.

 Tentatives d’exécution de code (RCE)

Autre exemple vu récemment :

?p=admin/dashboard&a=<?=exec($_GET["cmd"]);die()?>

Ce que cherche l’attaquant

• Déterminer si le serveur interprète du code reçu dans un paramètre.
• Déclencher une commande système (whoami, ls, etc.).
• Tester une mauvaise configuration ou un framework vulnérable.

Rôle du WAF

Un WAF catégorise ce payload comme une attaque web et le bloque immédiatement, évitant tout début d’exécution et masquant l’environnement interne.

Scans de fichiers sensibles : .env, .git, configs…

Les robots testent une longue liste de chemins standards :

/.git/config /config/default.json /config.yaml /config.env /compose/.env /community/.env

Ce que cherche l’attaquant

• Récupérer des secrets (clés API, identifiants DB).
• Accéder à un dépôt Git exposé.
• Exploiter un fichier oublié lors d’un déploiement.

Ce que fait un WAF

Même si un fichier existe par erreur, un WAF peut en bloquer l’accès externe et éviter une fuite directe d’informations sensibles.

Tests HTTP sur la racine : un indicateur d’exploration

Des requêtes très simples comme :

POST /

paraissent anodines, mais elles font partie d’une stratégie de reconnaissance.

L’objectif de l’attaquant

• Voir comment le serveur réagit à une méthode inattendue.
• Obtenir un code HTTP révélateur (500, 405, stacktrace).
• Distinguer un framework ou une configuration vulnérable.

Seulement si le WAF n’est pas là

Le WAF absorbe ces requêtes, normalise les réponses, et empêche toute fuite d’information technique.

Une origine géographique trompeuse

Contrairement aux idées reçues, les attaques ne proviennent pas seulement d’Asie ou d’Europe de l’Est.
Un grand volume de requêtes observées vient :

• des États‑Unis (infrastructures cloud massivement utilisées),
• de France (serveurs compromis ou bots résidentiels),
• et d’autres régions très actives en 2025‑2026 (Afrique, Asie‑Pacifique).
  [cyberinstitut.fr]

Selon le World Cybercrime Index (2024), les États‑Unis font partie des principaux pays sources de cybercriminalité lucrative, non pas par origine des attaquants, mais par l’usage massif de leur cloud.
[deepstrike.io]

Conclusion : la géolocalisation n’est pas une protection fiable.

Pourquoi un WAF est indispensable

Toutes ces attaques suivent le même schéma :

1. Reconnaître — injection SQL, RCE, scan, POST suspect
2. Observer — différence de comportement, erreur, lenteur
3. Exploiter — seulement si un signal positif est détecté

Un WAF coupe ce cycle dès la première étape.

Sans reconnaissance → pas d’exploitation.

C’est la fonction essentielle d’un WAF dans la protection d’un site internet :

• bloquer les injections SQL,
• masquer les erreurs internes,
• normaliser les réponses,
• intercepter les scans de fichiers,
• empêcher la divulgation de secrets,
• neutraliser les tentatives d’exécution de code.

Les attaques web observées — injections SQL, scans de fichiers sensibles, requêtes RCE ou POST anormaux — ne sont pas exceptionnelles : elles constituent le bruit de fond permanent d’Internet.

Un WAF offre une protection essentielle en empêchant ces tests d’aboutir.
Il réduit la surface d’exposition, bloque les attaques avant leur exploitation et évite que l’application ne révèle des vulnérabilités potentielles.

C’est aujourd’hui l’une des briques de sécurité les plus efficaces pour toute organisation disposant d’applications exposées.

En conclusion :

Regardez vos logs de site web, vous trouverez sans aucun doute le même type de tentative d'attaque en espérant qu'elle ne soit pas passée.