Cloudflare veut confirmer les attaques en observant aussi les réponses web

Le résultat du serveur entre dans l'analyse

Cloudflare annonce deux fonctions pour son pare-feu pour applications web, ou WAF, un filtre placé devant les sites et leurs services. La première examine ensemble une demande et la réponse produite par le serveur. La seconde permet de bloquer cette réponse avant qu'elle atteigne son destinataire. Ces fonctions sont proposées à tous les clients, y compris ceux de l'offre gratuite.

Pour un site, la conséquence concrète concerne surtout les tentatives dont le succès restait incertain. Une requête peut sembler hostile sans prouver qu'une donnée a été révélée. La réponse peut montrer un refus, une erreur ou, au contraire, un contenu sensible. Cloudflare entend utiliser cette différence pour mieux séparer un simple sondage d'un résultat révélant un impact possible.

Pourquoi la requête seule laisse un doute

Jusqu'ici, les protections décrites agissaient principalement sur la requête entrante. Elles cherchaient des techniques connues ou appliquaient des règles fondées sur le chemin demandé, les en-têtes ou le contenu envoyé. Cette approche reste essentielle, selon Cloudflare, car elle arrête un trafic reconnaissable avant le serveur d'origine. Ce terme désigne ici la machine qui héberge réellement l'application derrière le réseau Cloudflare.

L'observation présentée est cependant limitée par un dilemme. Une signature large, c'est-à-dire un motif associé à une attaque, repère davantage de demandes suspectes. Elle risque aussi un faux positif, quand un usage légitime est classé à tort comme malveillant. Une règle très prudente réduit ce risque, mais laisse passer davantage de trafic ambigu vers l'application.

Cloudflare place cette évolution dans un contexte où des modèles d'intelligence artificielle découvrent des failles enfouies dans des logiciels répandus. Selon son analyse, des agents automatisés peuvent insister, modifier leurs charges d'attaque selon les réponses et combiner plusieurs accès. La réponse du serveur devient alors un retour utile pour ajuster la tentative suivante. Cette description expose la motivation du produit, sans démontrer la fréquence réelle de ces comportements.

La méthode relie l'entrée à ce qui ressort

La méthode consiste à corréler les deux moitiés d'une transaction HTTP, le protocole utilisé pour les échanges sur le Web. Cloudflare analyse la demande, puis recherche dans la réponse des indices compatibles avec une exploitation réussie. Le système attache ensuite des informations de détection aux deux flux. Ces résultats apparaissent dans ses outils d'analyse afin d'aider les équipes à examiner les événements.

La publication illustre ce mécanisme avec un service de téléchargement de fichiers. Une personne modifie un paramètre pour tenter de sortir du dossier autorisé et réclamer un fichier privé de configuration. La demande seule révèle la tentative, mais pas son résultat. Si la réponse contient des éléments caractéristiques de ce fichier, la combinaison fournit un indice plus fort qu'un signal observé isolément.

Détecter d'abord, décider ensuite

Cloudflare sépare volontairement l'interprétation et la mesure appliquée. Les détections évaluent le trafic et produisent des métadonnées, autrement dit des informations décrivant le résultat de l'analyse. Les règles décident ensuite de journaliser ou de bloquer. Cette séparation permet aux équipes d'observer les chemins concernés avant de choisir une politique adaptée à leur application.

Lorsqu'une règle de réponse bloque, Cloudflare remplace le contenu du serveur par une page de refus ou par une réponse personnalisée. Le contenu potentiellement sensible ne parvient alors pas au demandeur. Le fournisseur précise toutefois que ce contrôle intervient après le traitement par le serveur. Il ne peut donc pas annuler les actions déjà réalisées sur cette machine.

Un déploiement large, avec des limites visibles

Les premières protections gérées par Cloudflare visent php2shell, une vulnérabilité récemment divulguée que la publication présente comme un premier cas d'usage. Une protection gérée est une règle préparée par le fournisseur plutôt que construite par le client. Le jeu par défaut analyse chaque requête, mais son périmètre peut être restreint à certaines parties d'une application. Tous les forfaits peuvent aussi créer trois règles personnalisées de réponse.

La portée annoncée reste inégale selon les offres et les fonctions. Les clients payants disposent d'un catalogue de détections plus riche et de champs supplémentaires pour composer leurs politiques. La création de règles inspectant directement le corps de la réponse n'est pas encore disponible. Cloudflare indique aussi que certains champs sont toujours en cours de déploiement sur les comptes.

La publication interprète cette approche comme un moyen de distinguer les essais sans effet des indices d'impact. Elle prévoit ensuite des usages liés à l'exposition et à l'exfiltration, c'est-à-dire la sortie non autorisée de données. Cependant, aucun résultat mesuré sur des attaques réelles, aucun taux d'erreur et aucune évaluation indépendante ne sont fournis. Les performances et la précision du dispositif ne peuvent donc pas être établies à partir de cette seule publication.