Rapport sur la sécurité des applications : deuxième trimestre 2023

Cloudflare dispose d'une visibilité unique sur l'Internet. Cette perspective nous permet d'observer, d'explorer et d'identifier des tendances qui passeraient autrement inaperçues. C'est précisément ce que nous faisons dans ce rapport, en présentant nos observations concernant les tendances en matière de sécurité des applications à l'échelle d'Internet.

Ce rapport est la troisième édition de notre rapport sur la sécurité des applications. La première édition a été publiée en mars 2022, et la deuxième au mois de mars cette année ; il s'agit du premier rapport publié sur une base trimestrielle.

Depuis le dernier rapport, notre réseau est devenu plus vaste et plus rapide : nous traitons maintenant, en moyenne, 46 millions de requêtes HTTP chaque seconde et 63 millions en période de pointe. Nous traitons continuellement environ 25 millions de requêtes DNS par seconde, ce qui représente près de 2 100 milliards de requêtes DNS par jour, soit 65 000 milliards de requêtes par mois. Il s'agit de la somme des requêtes du DNS de référence et du résolveur servies par notre infrastructure. Si nous additionnons les requêtes HTTP et DNS, nous observons un volume très important de trafic malveillant, et nous nous intéressons uniquement aux requêtes HTTP, Cloudflare a, en moyenne, bloqué 112 milliards de cybermenaces par jour au deuxième trimestre 2023 ; ce sont ces données sur lesquelles repose ce rapport.

Comme d'habitude, avant d'entrer dans le vif du sujet, nous devons définir nos termes.

Tout au long de ce rapport, nous allons utiliser les termes suivants :

• Trafic atténué : toute requête HTTP* émanant d'un utilisateur à laquelle la plateforme Cloudflare a appliqué une action de « terminaison ». Ce type d'action inclut notamment des actions suivantes : BLOCK, CHALLENGE, JS_CHALLENGE et MANAGED_CHALLENGE. Le trafic atténué n'inclut pas les demandes auxquelles ont été appliquées les actions suivantes : LOG, SKIP, ALLOW. Contrairement à l'année dernière, nous excluons désormais les requêtes auxquelles des actions CONNECTION_CLOSE et FORCE_CONNECTION_CLOSE ont été appliquées par notre système d'atténuation des attaques DDoS, dans la mesure où ces actions ne font techniquement que ralentir l'initialisation de la connexion. Par ailleurs, elles ne représentent qu'un pourcentage relativement faible des requêtes. En outre, nous avons amélioré notre calcul concernant les actions de type CHALLENGE, afin de nous assurer que seuls les défis non résolus sont comptabilisés comme étant du trafic atténué. Une description détaillée des actions est disponible dans notre documentation destinée aux développeurs.

• Trafic lié aux bots/trafic automatisé : toute requête HTTP* identifiée par le système de gestion des bots de Cloudflare comme ayant été générée par un bot. Cette catégorie inclut les requêtes obtenant un score de bot compris entre 1 et 29. Aucune modification n'a été apportée par rapport à l'année dernière.

• Trafic d'API : toute requête HTTP* avec un type de contenu de réponse XML ou JSON. Lorsque le type de contenu de réponse est indisponible, comme c'est le cas pour les requêtes atténuées, le type de contenu Accept équivalent (spécifié par l'agent utilisateur) est utilisé à la place. Dans ce dernier cas, le trafic d'API n'est pas entièrement pris en compte, mais il offre néanmoins une représentation satisfaisante permettant d'obtenir des informations supplémentaires.

Sauf indication contraire, la période évaluée dans cette publication est la période de 3 mois courant d'avril 2023 à juin 2023 (inclus).

Enfin, notez que les données ne sont calculées que sur la base du trafic observé au travers du réseau Cloudflare, elles ne reflètent pas forcément les configurations du trafic HTTP dans tout Internet.

* Lorsque nous parlons du trafic HTTP, nous faisons référence à la fois au trafic HTTP et HTTPS.

Bien que le nombre de requêtes HTTP atténuées ait diminué de 2 points de pourcentage, atteindre 6 % en moyenne entre 2021 et 2022, les jours durant lesquels l'activité malveillante a été plus intense que d'habitude sont clairement observables sur l'ensemble du réseau. Un exemple clair est représenté sur le graphique ci-dessous : vers la fin du mois de mai 2023, nous observons un pic de l'ordre de 8 %. Ce pic est imputable à des événements DDoS de grande ampleur, ainsi qu'à d'autres activités qui ne se conforment pas aux cycles quotidiens ou hebdomadaires habituels, et nous rappelle encore que des événements malveillants de grande ampleur peuvent avoir un impact perceptible au niveau mondial, même à l'échelle de Cloudflare.

75 % des requêtes HTTP atténuées ont été immédiatement traitées avec l'action BLOCK. Cela représente une baisse de 6 points de pourcentage par rapport à l'édition précédente de ce rapport. La majorité des autres requêtes ont été atténuées avec différentes actions de type CHALLENGE ; les défis gérés arrivent en tête, représentant environ 20 % de ce sous-ensemble.

Dans notre précédent rapport, notre système automatisé d'atténuation des attaques DDoS était, en moyenne, à l'origine de plus de 50 % du trafic atténué. Au cours des deux derniers trimestres, en raison de l'adoption accrue du pare-feu WAF (mais également, selon toute vraisemblance, de meilleures configurations et mesures de protection des applications des entreprises contre le trafic indésirable), nous avons assisté à l'émergence d'une nouvelle tendance : le trafic atténué par le pare-feu WAF a dépassé le trafic lié à l'atténuation d'attaques DDoS. La majeure partie de l'augmentation est imputable aux règles personnalisées BLOCK du pare-feu WAF, plutôt qu'aux règles gérées du pare-feu WAF de Cloudflare, ce qui indique que ces mesures d'atténuation sont déclenchées par des règles configurées par les clients afin de protéger leur logique opérationnelle, ou à des fins connexes. C'est ce que révèle clairement le graphique ci-dessous.

Vous remarquerez que les atténuations liées aux règles gérées du pare-feu WAF (ligne jaune) représentent un volume négligeable par rapport à l'ensemble du trafic atténué par le pare-feu WAF, ce qui indique également que les clients adoptent des modèles de sécurité positive en autorisant le trafic légitime connu, plutôt qu'en bloquant uniquement le trafic malveillant connu. Cependant, le volume d'atténuations liées aux règles gérées du pare-feu WAF a atteint 1,5 milliard de requêtes par jour au cours du trimestre.

Notre atténuation des attaques DDoS est volumétrique, bien entendu, et le volume de trafic correspondant à nos règles d'atténuation des attaques DDoS contre la couche 7 ne doit pas être sous-estimé, d'autant plus que nous observons, sur l'ensemble du web, l'apparition d'un certain nombre d'attaques et de botnets nouveaux. Vous pouvez consulter une analyse approfondie des tendances en matière d'attaques DDoS dans notre rapport sur les menaces DDoS du deuxième trimestre.

Après agrégation de la source du trafic atténué, le pare-feu WAF est aujourd'hui à l'origine d'environ 57 % de la totalité des atténuations. Les données sont présentées sous forme de tableau ci-dessous, avec d'autres sources pour référence.

Source

Source	Percentage %
WAF	57%
DDoS Mitigation	34%
IP Reputation	6%
Access Rules	2%
Other	1%

Pourcentage %

Pare-feu WAF

Field	Used in percentage % of rules
Geolocation fields	40%
HTTP URI	31%
IP address	21%
Other HTTP fields (excluding URI)	34%
Bot Management fields	11%
IP reputation score	4%

57%

Atténuation des attaques DDoS

34%

Réputation IP

6%

Règles d'accès

Source	Percentage %
HTTP Anomaly	32%
SQLi	13%
Directory Traversal	10%
File Inclusion	9%
DoS	9%
XSS	9%
Software Specific	7%
Broken Authentication	6%
Common Injection	3%
CVE	1%

2%

Autre

1%

Compte tenu de l'augmentation du volume de trafic atténué par des règles de pare-feu WAF définies par les clients, nous avons pensé qu'il serait intéressant d'approfondir la question et de mieux comprendre quel trafic les clients bloquent, et comment ils le font. Pour cela, nous pouvons examiner l'utilisation des champs de règles sur l'ensemble des règles personnalisées de notre pare-feu WAF, afin d'identifier les thématiques communes. Bien entendu, les données doivent être interprétées correctement, car tous les clients n'ont pas accès à tous les champs, en fonction de leur contrat et du niveau de leur offre ; cependant, nous pouvons tout de même effectuer certaines déductions sur la base des « catégories » de champs. Si nous examinons les quelque 7 millions de règles personnalisées du pare-feu WAF déployées sur le réseau, en nous concentrant uniquement sur les principaux groupes, nous constatons la répartition suivante dans l'utilisation des champs :

Champ

Pourcentage % de règles d'utilisation

Champs liés à la géolocalisation

40%

URI HTTP

31%

adresse IP

Source	Percentage %
WAF	77%
DDoS Mitigation	13%
IP reputation	5%
Access Rules	3%
Other	1%

21%

Autres champs HTTP (hors URI)

34%

Champs liés à la gestion des bots

11%

Score IP Reputation

4%

Notamment, 40 % de la totalité des règles personnalisées du pare-feu WAF actuellement déployées utilisent des champs liés à la géolocalisation pour prendre des décisions concernant le traitement du trafic. Il s'agit d'une technique couramment utilisée afin de mettre en œuvre une logique opérationnelle ou d'exclure des secteurs géographiques depuis lesquels aucun trafic n'est attendu, permettant ainsi de réduire la surface d'attaque. Bien qu'il s'agisse de contrôles rudimentaires, peu susceptibles d'arrêter l'auteur d'une attaque sophistiquée, ils permettent néanmoins de réduire efficacement la surface d'attaque.

Une autre observation remarquable est l'utilisation de champs liés à la gestion des bots dans 11 % des règles personnalisées du pare-feu WAF. Ce nombre augmente continuellement au fil du temps ; en effet, pour protéger leurs applications, un nombre croissant de clients adoptent des stratégies de classification reposant sur l'apprentissage automatique.

Contribuant à hauteur d'environ 32 % au trafic atténué par les règles gérées du pare-feu WAF, les anomalies HTTP demeurent la catégorie d'attaque la plus fréquemment bloquée par les règles gérées du pare-feu WAF. Les attaques SQLi progressent à la deuxième position, dépassant en nombre les attaques par traversée de répertoires, avec 12,7 % et 9,9 % respectivement.

Lorsque l'on examine le début du mois d'avril 2023, on constate que la catégorie des attaques DoS dépasse considérablement la catégorie des anomalies HTTP. Les règles de la catégorie DoS sont des signatures HTTP correspondant à la couche 7 du pare-feu WAF, qui sont suffisamment spécifiques pour identifier (et bloquer) des requêtes uniques sans tenir compte du comportement des requêtes croisées, et qui peuvent être attribuées à des botnets spécifiques ou des charges utiles provoquant un déni de service (DoS). Normalement, comme c'est le cas ici, ces requêtes ne font pas partie des attaques « distribuées », d'où l'absence du premier « D » (correspondant au terme « distribué ») dans le nom de la catégorie.

Source	Percentage %
HTTP Anomaly	64%
SQLi	11%
XSS	9%
Software Specific	5%
Command Injection	4%

Format tableau pour référence (10 principales catégories) :

Source

Pourcentage %

Anomalie HTTP

32%

SQLi

13%

Directory Traversal

10%

Inclusion de fichier

9%

DoS

9%

XSS

9%

Spécifique à un logiciel

7%

Défaillance d'authentification

6%

Injection commune

3%

CVE

1%

En réalisant un examen approfondi et en filtrant uniquement les données pertinentes à la catégorie DoS, nous constatons que la majeure partie du trafic atténué est attribuable à une règle : 100031 / ce02fd... (ID de règle de l'ancien pare-feu WAF et du nouveau pare-feu WAF, respectivement). Cette règle, dont la description est « Microsoft IIS - DoS, Anomaly:Header:Range - CVE:CVE-2015-163523 », concerne une CVE (« Common Vulnerability and Exposure) datant de 2015, qui affecte un certain nombre de composants Microsoft Windows, permettant l'exécution de code à distance*. Il s'agit d'un rappel pertinent que les anciennes CVE, même celles datant de plus de 8 ans, sont toujours activement exploitées pour compromettre des machines n'ayant pas reçu de correctifs et exécutant encore des logiciels vulnérables.

* En raison de la catégorisation des règles, certaines règles spécifiques aux CVE sont encore affectées à une catégorie plus vaste, telle que la catégorie DoS, dans cet exemple. Les règles sont uniquement affectées à une catégorie de CVE lorsque la charge utile de l'attaque ne recoupe pas clairement une autre catégorie plus générique.

Une autre observation intéressante est l'augmentation des correspondances avec la règle « Broken Authentication » (authentification défaillante) à partir du mois de juin. Cette augmentation est également attribuable à une règle unique, déployée pour l'ensemble de nos clients, y compris les utilisateurs de notre offre gratuite : « Wordpress - Broken Access Control, File Inclusion ». Cette règle bloque les tentatives d'accès à wp-config.php – le fichier de configuration par défaut de WordPress, qui se trouve normalement dans le répertoire racine du document du serveur web, mais qui, bien entendu, ne devrait jamais être accessible directement via HTTP.

Dans le même ordre d'idées, CISA/CSA a récemment publié un rapport intitulé « 2022 Top Routinely Exploited Vulnerabilities », présentant les principales vulnérabilités couramment exploitées. Nous avons profité de l'occasion pour examiner de quelle manière chaque CVE mentionnée dans le rapport de CISA était reflétée dans les données de Cloudflare. CISA/CSA examine 12 vulnérabilités régulièrement exploitées par des cyberacteurs malveillants en 2022. Toutefois, selon notre analyse, deux CVE mentionnées dans le rapport de CISA sont à l'origine de l'immense majorité des attaques que nous avons observées « dans la nature » : Log4J et Atlassian Confluence Code Injection. Nos données suggèrent clairement une différence considérable dans le volume d'exploitations entre ces attaques, qui occupent les deux premières places du classement, et le reste de la liste. Le graphique suivant compare le volume d'attaques (en échelle logarithmique) des six principales vulnérabilités de la liste de CISA d'après nos journaux.

La solution de gestion des bots de Cloudflare continue de bénéficier d'investissements importants, à l'image de l'ajout d'URL vérifiées par JavaScript pour une meilleure protection contre les bots ciblant les navigateurs ; par ailleurs, des ID de détection sont désormais disponibles dans les règles personnalisées, pour une plus grande facilité de configuration, tandis qu'une interface utilisateur améliorée offre une prise en main plus aisée. Pour les clients en libre-service, nous avons ajouté la possibilité d'ignorer les règles du mode Super Bot Fight et la prise en charge des requêtes Loopback de Wordpress, afin d'offrir une meilleure intégration aux applications de nos clients, ainsi que la protection qu'ils recherchent.

Notre confiance dans les résultats de la classification de la solution de gestion des bots demeure très élevée. Si nous représentons graphiquement les scores des bots sur l'intervalle analysé, nous constatons une répartition très claire, la plupart des requêtes étant classées comme étant certainement liées à des bots (score inférieur à 30) ou certainement d'origine humaine (score supérieur à 80) ; en réalité, la plupart des requêtes obtiennent un score inférieur à 2 ou supérieur à 95. Cela équivaut, sur la même période, à la classification de 33 % du trafic comme automatisé (c'est-à-dire généré par un bot). Sur des périodes plus longues, nous constatons que le pourcentage global de trafic automatisé reste stable, à 29 %, reflétant les données présentées dans Cloudflare Radar.

Comparée à l'édition précédente du rapport, l'atténuation du trafic HTTP lié à des bots non vérifiés diminue actuellement (moins 6 points de pourcentage). Cependant, l'utilisation du champ Bot Management (gestion des bots) dans les règles personnalisées du pare-feu WAF n'est pas négligeable, puisqu'elle s'élève à 11 %. Cela signifie que plus de 700 000 règles personnalisées du pare-feu WAF déployées sur Cloudflare se fient à des signaux caractéristiques des bots pour exécuter une action. Le champ le plus fréquemment utilisé est cf.client.bot, un alias de cf.bot_management.verified_bot, qui repose sur notre liste de bots vérifiés et permet aux clients d'établir une distinction entre les bots légitimes et les bots non vérifiés, potentiellement malveillants.

Les entreprises ont accès à la fonctionnalité cf.bot_management.score, plus puissante, qui leur permet d'accéder directement au score calculé pour chaque requête ; il s'agit du même score que celui utilisé pour générer le graphique de répartition des scores des bots dans la section précédente.

L'examen du service de Cloudflare exécutant l'atténuation du trafic de bots non vérifiés permet également de valider les données ci-dessus. Bien que notre système d'atténuation des attaques DDoS bloque automatiquement le trafic HTTP pour l'ensemble des clients, cela ne représente que 13 % des mesures d'atténuation de trafic de bots non vérifiés. En revanche, le pare-feu WAF (et principalement les règles définies par les clients) représentent 77 % de ces mesures d'atténuation ; cette valeur est beaucoup plus élevée que les mesures d'atténuation pour l'ensemble du trafic (57 %) évoquées au début du rapport. Notez que la solution de gestion des bots est spécifiquement mentionnée, mais qu'elle fait référence à nos règles en un clic « par défaut », qui sont comptabilisées séparément des champs liés aux bots utilisés dans les règles personnalisées du pare-feu WAF.

Format tableau pour référence :

Source

Pourcentage %

Pare-feu WAF

77%

Atténuation des attaques DDoS

13%

Réputation IP

5%

Règles d'accès

3%

Autre

1%

La croissance du trafic d'API global observée par Cloudflare ne connaît pas de ralentissement. Par rapport au trimestre précédent, nous constatons que 58 % du trafic dynamique total est classé comme étant lié aux API. Cela représente une augmentation de 3 points de pourcentage par rapport au premier trimestre.

Notre investissement dans la passerelle API Gateway suit également une tendance croissante similaire. Au cours du dernier trimestre, nous avons inauguré plusieurs nouvelles fonctionnalités de sécurité des API.

Premièrement, nous avons facilité l'utilisation du service d'identification des API, avec une nouvelle vue de la boîte de réception. Le service d'identification des API répertorie les API afin d'éviter les problèmes liés à l'informatique fantôme (Shadow IT) et aux API zombies ; les clients peuvent désormais facilement filtrer les données afin d'afficher uniquement les nouveaux points de terminaison identifiés par le service d'identification des API. L'enregistrement des points de terminaison depuis le service d'identification des API entraîne leur ajout à notre système de gestion des points de terminaison.

Ensuite, nous avons ajouté une toute nouvelle fonctionnalité de sécurité des API, proposée exclusivement par Cloudflare : la possibilité de contrôler l'accès aux API en fonction du comportement du client. Nous l'appelons Sequence Mitigation. Les clients peuvent désormais créer des modèles de sécurité positive ou négative basés sur l'ordre des chemins d'accès aux API utilisés par les clients. Vous pouvez désormais vous assurer que les utilisateurs de votre application sont les seuls à accéder à votre API, et ainsi, arrêter les tentatives par force brute qui passent outre les fonctionnalités normales de l'application. Par exemple, dans une application de services bancaires, vous pouvez désormais exiger que l'accès au point de terminaison de transfert de fonds soit uniquement possible qu'après qu'un utilisateur ait également accédé au point de terminaison de vérification du solde du compte.

Nous sommes heureux de continuer à proposer de nouvelles fonctionnalités de sécurité et de gestion des API pendant le reste de l'année 2023 et après.

Le pourcentage du trafic d'API généré par les navigateurs est resté très stable au cours du dernier trimestre. Cette statistique fait référence aux requêtes HTTP qui ne servent pas de contenu HTML directement rendu par le navigateur sans traitement préalable, à l'image des requêtes plus communément appelées AJAX, qui servent habituellement des réponses basées sur JSON.

Comme au trimestre précédent, les anomalies HTTP demeurent le vecteur de trafic d'attaque atténué le plus courant parmi le trafic lié aux API. Les attaques par injection SQLi ne sont pas négligeables, toutefois, puisqu'elles contribuent à hauteur d'environ 11 % au volume total de trafic atténué, suivies de près par les attaques XSS, à hauteur d'environ 9 %.

Présentation sous forme de tableau pour référence (5 premières attaques) :

Source

Pourcentage %

Anomalie HTTP

64%

SQLi

11%

XSS

9%

Spécifique à un logiciel

5%

Injection de commande

4%

Tandis que nous optons pour une publication trimestrielle de notre rapport sur la sécurité des applications, nous avons l'intention d'approfondir l'examen de certaines informations et de présenter des données supplémentaires issues de certains de nos produits récents, tels que Page Shield ; cela nous permettra d'aller au-delà du trafic HTTP et d'explorer l'état des dépendances tierces en ligne.

Restez à l'écoute et gardez un œil sur Cloudflare Radar pour bénéficier de rapports et d'informations plus fréquents consacrés à la sécurité des applications.