Pourquoi les signaux côté client sont indispensables pour détecter les attaques sophistiquées

En matière de détection des bots, il existe des arguments pour et contre l’utilisation des signaux côté client. Cet article explique en quoi les signaux côté client améliorent considérablement la précision avec laquelle on détecte les frameworks modifiés / de contournement de la détection des bots.

Que sont les signaux côté client ?

Les signaux côté client sont collectés directement à partir de l’appareil de l’utilisateur final. Ils peuvent provenir du navigateur via JavaScript (JS) ou d’applications mobiles via un SDK. Certains remettent en question l’utilisation des signaux côté client, car ils sont recueillis sur l’appareil de l’utilisateur (ou du potentiel attaquant) et peuvent donc être manipulés (nous aborderons cette limite plus loin).

Chez DataDome, nous recommandons fortement la collecte de signaux côté client en plus des signaux côté serveur et des signaux de réputation. Pour vous aider à comprendre pourquoi il est important de collecter des signaux côté client, j’aborde les sujets suivants :

3 types de signaux de détection des bots :

1. Signaux comportementaux
2. Signaux de réputation
3. Signaux de signature

Comment surmonter les limites de la collecte de signaux côté client ?

Signaux JavaScript côté client pour la détection des bots 

3 types de signaux de détection de bots

1. Comportement

Les signaux comportementaux peuvent être collectés à la fois côté serveur et côté client, chacun apportant une couche supplémentaire à la détection des bots.

Par exemple :

• Côté serveur, un moteur de détection peut analyser la manière dont l’utilisateur navigue sur un site ou une application mobile. Il peut détecter des anomalies en observant les séries temporelles des requêtes, et utiliser des algorithmes d’apprentissage automatique non supervisé pour identifier des comportements inhabituels. Nous pouvons également procéder à une détection plus avancée basée sur les graphes afin d’analyser la transition entre les différentes URL et de déterminer s’il existe ou non des cycles dans les URL visitées.

• Côté client, les signaux comportementaux sont collectés via JavaScript dans un navigateur ou via un SDK dans une application mobile. Ces signaux proviennent des interactions directes avec l’interface : mouvements de souris, clics, événements tactiles, vitesse de frappe, ou même des données de capteurs comme l’accéléromètre des appareils mobiles.

Ces signaux comportementaux sont ensuite traités par des modèles d’apprentissage automatique qui évaluent si le comportement observé correspond à celui d’un utilisateur humain ou d’un bot, en se basant sur l’authenticité et la fluidité des interactions.

2. Réputation

Les signaux de réputation sont exclusivement calculés côté serveur. Ils peuvent être évalués à différents niveaux de granularité, qu’il s’agisse d’une session utilisateur, d’une adresse IP ou d’un système autonome, et sur différentes périodes temporelles (heures, jours, voire mois).

Ces signaux permettent au moteur de détection d’utiliser des informations historiques pour ajuster ses décisions et la rigueur des mesures appliquées. Par exemple, si un système autonome est fréquemment associé à des attaques de credential stuffing, les modèles d’apprentissage automatique intégreront cette donnée (en plus de milliers d’autres signaux) pour renforcer les protections face au trafic en question.

3. Signatures

Les signaux de signature peuvent être collectés à la fois côté serveur et côté client. Ils prennent diverses formes, notamment :

• empreintes HTTP, basées sur les en-têtes HTTP (côté serveur) ;
• empreintes TLS, dérivées des métadonnées échangées lors de la négociation TLS (côté serveur) ;
• empreintes numériques du navigateur, qui rassemblent des informations sur le navigateur, le dispositif et le système d’exploitation (collectées via JS, côté client) ;
• empreintes mobiles, reposant sur des informations issues du dispositif et du système d’exploitation, obtenues via un SDK (côté client, dans une application mobile).

Les empreintes de navigateur et de mobile sont essentielles pour une détection complète. Les défis JS ou SDK avancés permettent de détecter les navigateurs sans tête et les cadres d’automatisation les plus courants, tels que :

• Headless Chrome ;
• Puppeteer ;
• Selenium ;
• Playwright.

Au-delà de la détection des technologies d’automatisation courantes, les challenges côté client se révèlent très efficaces pour identifier et suivre des frameworks de bots modifiés, conçus spécifiquement pour contourner les mécanismes de détection habituels. Ils permettent de détecter notamment :

• Puppeteer Extra Stealth, une version modifiée de Puppeteer qui cache ses empreintes et tente de falsifier les CAPTCHA ;
• des drivers Chrome Selenium modifiés ;
• des versions altérées de Playwright.

Si vous souhaitez en savoir plus sur la manière dont les challenges côté client aident à détecter rapidement et avec précision ces frameworks de bots modifiés, consultez nos articles sur la détection de Puppeteer Extra Stealth et les drivers Chrome modifiés dans Selenium.

En résumé, deux types de signaux de détection de bots peuvent être collectés côté client :

• le comportement : mouvements de la souris, événements tactiles, capteurs ;
• les signatures : empreintes numériques des navigateurs et mobiles.

Bien que les signaux comportementaux et de signature puissent comporter des limites, DataDome a constaté que supprimer les signaux côté client (~30-40% de tous les signaux) nuit gravement à l’efficacité de la détection des bots. En particulier, les navigateurs automatisés (headless) tels que Headless Chrome présentent des empreintes HTTP et TLS cohérentes par nature. Il est donc essentiel de collecter un maximum de signaux pour permettre une détection rapide et efficace des bots.

Comment pallier les limites de la collecte de signaux côté client ?

Les attaquants peuvent usurper ou manipuler les signaux collectés côté client en utilisant différentes techniques. Par exemple, des bibliothèques comme Puppeteer extra stealth permettent de modifier les objets natifs JavaScript pour échapper à la détection.

En cybersécurité, une règle fondamentale est : ne jamais faire confiance aux données fournies par un utilisateur. Cela inclut non seulement les textes ou paramètres envoyés, mais aussi toute information collectée côté client.

Alors comment dépasser ces limites ?

Nous adoptons une approche combinée :

1. Obfuscation du code : le code JavaScript chargé de collecter les signaux côté client est obfusqué pour rendre plus difficile aux attaquants la compréhension de ce qui est collecté.
2. Collecte de signaux bruts côté client : toute la logique de détection se trouve côté serveur. Ainsi, même si un attaquant parvient à deviner certains signaux collectés, l’objectif de cette collecte et son utilisation ne sont pas exposés côté client.
3. Mise à jour fréquente des signaux côté client : nous actualisons régulièrement nos signaux pour devancer les développeurs de bots qui cherchent à adapter leurs scripts. Nos modules de collecte de signaux côté client (SDK et JSTag) sont conçus pour permettre des mises à jour rapides et sécurisées, avec l’intégration immédiate de nouveaux signaux dans nos modèles d’apprentissage automatique et nos règles de détection.

Enfin, tous les signaux sont traités de manière sécurisée, ce qui signifie qu’avoir des signaux côté client non suspects ne garantit aucun privilège. Les utilisateurs ne seront pas autorisés simplement parce qu’ils envoient un ensemble légitime de signaux côté client. Chaque requête est toujours évaluée en temps réel par notre moteur de détection, en prenant en compte l’ensemble des signaux (comportement, réputation, signatures côté serveur, etc.) pour identifier les trafics malveillants.

Signaux JavaScript côté client pour la détection des bots en conditions réelles

Les deux graphiques ci-dessous, extraits de nos récents articles sur Puppeteer extra stealth (graphique 1) et Selenium modifié (graphique 2), illustrent le volume de requêtes que nous avons bloquées grâce aux signaux collectés côté client avec JavaScript.

Nombre de requêtes Puppeteer extra stealth bloquées dans le temps grâce aux signaux JavaScript côté client

Nombre de requêtes Selenium modifié bloquées dans le temps grâce aux signaux JavaScript côté client. Le trafic est réparti par type de Selenium modifié.

Sans les signaux côté client/JavaScript, il est probable que nous aurions tout de même détecté les bots ci-dessus à l’aide d’autres signaux, mais cela aurait pris plus de temps. Les signaux comportementaux, par exemple, nécessitent davantage de requêtes avant de pouvoir prendre une décision précise. Heureusement, les signaux côté client sont instantanés.

Lorsque des signaux côté client sont liés à un navigateur automatisé (modifié), nous pouvons bloquer la session malveillante en toute confiance. De plus, ces signaux nous aident à fournir des informations contextuelles supplémentaires à nos clients. En effet, nous pouvons déduire le type de technologies utilisées par les attaquants—qu’il s’agisse d’un framework d’automatisation ou d’une éventuelle intégration avec des fermes CAPTCHA—en analysant les signaux comportementaux et de réputation.

Conclusion

Chez DataDome, nous affirmons qu’un moteur de détection de bots performant doit s’appuyer sur un ensemble large et diversifié de signaux de détection (côté client, côté serveur, comportementaux, de réputation, signatures) en temps réel pour identifier les bots avancés.

Bien que les signaux côté client puissent parfois être manipulés par des attaquants, ils apportent une valeur considérable à la détection des menaces et à l’explicabilité lorsqu’ils sont utilisés avec les bonnes contre-mesures (obfuscation, mises à jour fréquentes et absence de privilèges).

En particulier, les signaux côté client sont très efficaces pour détecter et suivre les frameworks anti-bots qui modifient leurs empreintes. Pour obtenir une vision complète des attaques sophistiquées qui vous ciblent, essayez notre évaluation gratuite des menaces et un essai de 30 jours de DataDome.