Anatomie d’une Attaque de Scraping Distribuée

Bien qu’un nombre important de sites web populaires utilisent des logiciels de détection de bots dédiés, certaines entreprises en ligne estiment qu’elles peuvent résoudre le problème des bots par elles-mêmes. Elles tentent de lutter contre les bots en utilisant des approches traditionnelles telles que les CAPTCHA classiques ou des mécanismes de limitation de débit basés sur l’IP et le géoblocage disponibles dans leur WAF.

Dans cet article, nous nous concentrons sur une attaque de scraping distribuée qui a visé une place de marché française. Ce type d’attaque est assez courant, que ce soit en raison de son ampleur ou des techniques utilisées par l’attaquant pour contourner les techniques de détection traditionnelles. Les sites web populaires et les applications mobiles subissent plusieurs attaques de scraping chaque jour, au quotidien.

Anatomie de l’attaque de scraping

L’attaquant a été détecté en utilisant différentes techniques et signaux, tels que l’analyse du comportement et les méthodes de détection de proxy résidentiel.

Comment avons-nous isolé les requêtes de l’attaquant ?

La raison pour laquelle nous savons que l’attaque provenait d’un seul attaquant est qu’il utilisait des URL mal formées, probablement délibérément. L’attaquant a introduit une lettre au milieu d’un nombre dans un paramètre GET qui n’attend qu’un nombre (par exemple, “http://example.com?products=0a12″ au lieu de “products=012”).

Cependant, malgré la présence d’une lettre dans le paramètre GET, le site web a quand même interprété correctement le nombre, ce qui signifie que la requête a renvoyé le contenu attendu par l’attaquant.

Pourquoi l’attaquant introduisait-il des paramètres GET fictifs ?

Certains paramètres GET avec une valeur élevée peuvent être suspects, par exemple, si vous essayez d’ajouter trop de produits à un panier en une seule fois, ou si vous visitez une page avec une valeur élevée en début de session de navigation. L’introduction de paramètres fictifs peut aider un attaquant à échapper à la détection.

Au total, sur une semaine, l’attaquant a effectué 1,1 million de requêtes de recherche pour extraire des données du site web. Le graphique ci-dessous montre le nombre de requêtes de bots malveillants effectuées par l’attaquant chaque jour.

Nombre de requêtes de scraping liées à notre attaquant sur une semaine.

Quels signaux et empreintes distinguent l’attaquant ?

L’attaquant a effectué des requêtes de recherche avec différents paramètres pour explorer et collecter des données sur le marché immobilier français. L’attaque était fortement distribuée, utilisant plus de 45 000 adresses IP différentes.

L’attaquant a également aléatoirement modifié l’empreinte du bot en utilisant différents user-agents récents ou à jour, tels que :

• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36 Edg/116.0.1900.70 ;
• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36 ;
• Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/117.0 ;
• Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.0 Safari/605.1.15.

Contrairement aux user-agents aléatoires, les bots de l’attaquant utilisaient des en-têtes accept-language cohérents, en l’occurrence le français, car ils ciblaient un site web français :

• fr-FR,fr;q=0.9 ;
• fr-FR,fr;q=0.5.

L’attaquant utilisait également des en-têtes HTTP cohérents avec le type de ressources demandées (une requête de recherche renvoyant du contenu HTML) et le user-agent falsifié par les bots était cohérent avec un navigateur Chrome, par exemple :

text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7

Il convient de noter que, bien que les empreintes TLS ne soient pas entièrement cohérentes, elles ne peuvent pas être liées à des bibliothèques client HTTP populaires.

L’attaquant utilisait principalement des adresses IP résidentielles françaises : environ 45 000 IP distinctes sur une semaine.

Les adresses IP utilisées par l’attaquant sont liées aux principaux fournisseurs de services Internet français :

• Orange, fournisseur de services historique français (équivalent d’AT&T aux États-Unis)
• Free et Free Mobile
• SFR
• Bouygues Telecom

Pourquoi les techniques de détection de bots traditionnelles en interne ne sont pas suffisantes

En résumé, l’attaque de scraping visait une place de marché française, effectuant 1,1 million de requêtes de recherche en une semaine. Les bots utilisaient des en-têtes HTTP falsifiés pour correspondre au type de ressources demandées et au navigateur prétendu dans le user-agent. L’attaquant utilisait également l’acceptation de la langue française, avec plus de 45 000 adresses IP de proxys résidentiels français distinctes. En moyenne, chaque IP impliquée dans l’attaque effectuait entre une et dix requêtes par jour.

Les techniques traditionnelles suivantes utilisées dans les WAF ou mises en œuvre en interne n’auraient pas fonctionné contre les bots utilisés dans cette attaque :

• Blocage basé sur la signature : les empreintes digitales côté serveur étaient plutôt cohérentes et évoluaient avec le temps. Ainsi, il n’y avait pas de signature particulière et stable pouvant être utilisée pour le blocage.
• Géoblocage : ne pouvait pas être utilisé, car les bots utilisaient des adresses IP françaises. (En général, nous ne recommandons pas l’utilisation du geoblocage, car cela peut entraîner de nombreux faux positifs.)
• Blocage des IP des data centers : l’attaquant utilisait principalement des adresses IP résidentielles, donc le blocage des adresses IP de data centers n’aurait pas fonctionné.
• Limitation de débit basée sur les IP : n’aurait pas été efficace, car chaque IP effectuait en moyenne moins de dix requêtes par jour.
• Blocage sur la base d’un langage d’utilisateur non correspondant : l’utilisation d’autres informations contextuelles comme la langue utilisateur n’aurait pas été utile, puisque l’attaquant les a adaptées au pays du site web ciblé.

Un argument contraire pourrait être que l’utilisation de CAPTCHA traditionnels aurait pu aider. Bien que cela puisse être vrai dans certains cas, il est important de prendre en compte l’impact en termes d’expérience utilisateur. Quels sont vos utilisateurs qui souhaitent voir un CAPTCHA dès qu’ils effectuent leur première recherche ? De plus, les CAPTCHA traditionnels peuvent être contournés très facilement par des fermes à CAPTCHA, où des êtres humains résolvent des défis pour des bots.

L’attaque que nous avons décrite ci-dessus peut sembler sophistiquée, et vous pourriez penser que ce type d’attaquants ne cible pas votre site web. Cependant, ces techniques avancées sont devenues assez courantes ces derniers temps, même pour le scraping. Plusieurs packages open source permettent aux attaquants de créer des bots plus réalistes. Des scraping bots en tant que service proposent également ces fonctionnalités clés en main via une API.

Conclusion

Pour protéger vos sites web, applications mobiles et API contre les bots malveillants, que ce soit contre les attaques de scraping, de credential stuffing, de DDoS de couche 7 ou autre chose, il est important de reconnaître que les attaquants sont devenus de plus en plus sophistiqués ces dernières années en raison de toutes les bibliothèques, les logiciels, les fermes de CAPTCHA et les bots as a service à leur disposition. L’utilisation de techniques de détection de bots traditionnelles en interne ou de pare-feu applicatifs web (WAF) n’est plus suffisante pour protéger votre entreprise et vos clients. De plus, les techniques classiques telles que la limitation de débit basée sur les IP, les CAPTCHA et le géoblocage ont tendance à avoir un impact négatif sur l’expérience utilisateur.

Les attaques sophistiquées nécessitent des défenses sophistiquées. Suivre les derniers vecteurs d’attaque est un défi à temps plein, que vous ne voulez pas que vos équipes perdent du temps et des ressources à essayer de relever. La détection automatique de bots et de fraudes de DataDome utilise le machine learning pour s’améliorer à chaque interaction. Elle bloque les bots malveillants en moins de 2 millisecondes sans compromettre l’expérience utilisateur.

Notre Vulnerability Scan peut vous donner un aperçu des bots de base qui atteignent vos sites web, applications et/ou API. Ou vous pouvez repérer des menaces plus sophistiquées dès maintenant grâce à un essai gratuit de DataDome.