Protection des données dans l'e-commerce : comment les cyber attaquants volent silencieusement ?

Depuis plusieurs années les données sont considérées comme l'or noir d'une économie numérique en pleine transformation.

Les informations collectées et détenues par une entreprise sont une ressource précieuse qui, si elle est correctement exploitée, peut devenir une source de croissance. Cependant, comme tout bien de valeur, elles attisent les convoitises d’acteurs malveillants sur les sites de e-commerce. Derrière les API, les lignes de code constituent le terrain d’une lutte pour la protection des données.

D’un côté, des hackers qui répètent, réinventent et renouvellent des attaques ciblées pour dérober les data tant convoitées. De l’autre, des entreprises conscientes de la valeur des informations collectées via leur interface. Alors que les technologies visant à sécuriser les applications web concentrent leur action côté serveur, les acteurs malveillants ont trouvé de nouvelles voies d'attaque qui exploitent le côté client (ou front-end) d'une application web.

Les incitations et possibilités d’attaques front-end ont augmenté de façon exponentielle en raison de la multiplication des transactions en ligne. Ces dernières entraînent une explosion du volume de données sensibles, dont les données personnelles des utilisateurs, qui traversent les réseaux. Pour les exploiter, les attaquants s’appuient notamment sur le manque de contrôle du code Javascript.

Scripts et formulaires des sites web, les principales faiblesses côté client

Les hackers profitent de la grande vulnérabilité des services d’application web : leur code javascript. En effet, elles chargent en moyenne plus de 30 scripts tiers lors de l'exécution sur le navigateur d'un utilisateur.

Cela signifie que l’entreprise qui possède et exploite l’application web, perd de la visibilité sur la façon dont se comporte le code au moment de son exécution. Cette dépendance au code tiers crée un angle-mort en matière de sécurité des applications de service web et élargit considérablement la surface d'attaque.

Lorsque le code n’a pas été créé par l’entreprise et provient de sources tierces, on parle de JavaScript third-party. Il présente ainsi un risque important car il dispose des mêmes privilèges que le code JavaScript first-party. Puisqu’il n'existe pas de paramètres de sécurité par défaut pour le code JavaScript tiers, l’entreprise qui exploite le site Web ou l'application tirant parti de ce code est responsable de l'application de la sécurité et de la surveillance continue.

À l’inverse, JavaScript first-party désigne le code généré par une entreprise. Il peut avoir été sécurisé lors de sa rédaction, et puis analysé par des outils internes pour s’assurer de l’intégrité du code. Cependant, des acteurs malveillants parviennent à l’altérer après la mise en production ou par rétro-ingénierie. Pour garantir l'intégrité de ce code, une plateforme est nécessaire, comme le prescrit actuellement l'OWASP (Open Web Application Security Project) dans ses recommandations pour sécuriser les applications. C’est pourquoi, lors de l’élaboration d’une stratégie de protection, il est important de prendre en compte les faiblesses intrinsèques aux scripts côté client.

Les formulaires constituent une autre porte d’entrée pour les hackers puisque la plupart des sites web y ont recours pour collecter des données personnelles et financières. Les utilisateurs ignorent que ces informations sont généralement exposées à une quinzaine de domaines tiers, ce qui accroît d’autant plus le risque d'accès illégal en cas de violation.

Les principales attaques par exfiltration de données et injection de code

Les hackers s’appuient sur ces faiblesses pour construire leurs techniques d’attaque. Celles-ci prennent principalement la forme d'exfiltration de données ou d'injection de contenu. La première a pour objectif de voler des informations précieuses sur un serveur, un ordinateur ou une page Web. La seconde consiste à insérer du contenu malveillant qui sera renvoyé à l'utilisateur final. Prenons l’exemple de l’exfiltration de données par attaque Magecart. La technique consiste à insérer du code, généralement dans des pages de paiement, où il agit comme un écrémeur de cartes de crédit en ligne, arrachant les informations personnelles et les détails des cartes de paiement de toute personne assez malchanceuse pour s'y livrer.

De nombreuses attaques Magecart impliquent également une attaque de la chaîne d'approvisionnement des services Web de la victime ; par exemple, la compromission du fournisseur d'un certain service à un site Web plus important afin de voler les données des cartes de crédit du site Web.. British Airways a subi une attaque de ce type et a vu les données de 480 000 clients compromises.

L’injection de code malveillant est une autre technique exploitant la multitude de services tiers intégrés aux applications web. Les attaquants peuvent cibler ces services pour injecter du code malveillant et lancer des attaques sur la chaîne d'approvisionnement. Ils obtiennent ainsi l’accès à des données sensibles (personnelles, bancaires, …) qu’ils pourront divulguer, à l’insu des utilisateurs ou des entreprises intégrant ces services. Le cross-site scripting (XSS) est l’un des vecteurs les plus courants. Il consiste à injecter un code malveillant dans le contenu d'un site web. Le XSS figure dans le Top 10 des principales vulnérabilités selon OWASP. Moins connu, le form jacking est un type de cyberattaque dans lequel un code JavaScript malveillant est injecté dans un formulaire de page Web, le plus souvent un formulaire de page de paiement. Lorsqu'un visiteur du site Web saisit les informations relatives à sa carte de paiement et clique sur "Envoyer", le code malveillant recueille le numéro de sa carte de paiement et des informations telles que son nom, son adresse et son numéro de téléphone. Le code envoie ensuite ces informations à un endroit choisi par les attaquants.

Comment remédier aux faiblesses de sécurité côté client ?

Les pratiques recommandées pour traiter les vulnérabilités côté client sont les suivantes :

Mettre régulièrement à jour et corriger tous les logiciels et applications associés à son site Web. En outre, il est recommandé d’utiliser une technologie de surveillance et d'inspection qui émet des alertes sur toute activité de script non autorisée. Cette technologie doit inclure une capacité de détection et d'analyse d'anomalies, d'intrusions ou de menaces inconnues.
Les politiques de sécurité du contenu (CSP) peuvent aider à détecter et à atténuer certains types d'attaques. Cependant, elles peuvent être contournées si elles utilisent des listes blanches statiques ou encore manquer de granularité. En effet, ces politiques s'appuient sur une approche binaire de type "bloquer ou autoriser" l'accès des tiers. Cela ne permet pas de répondre à des questions telles que "Autoriser ceci à moins que...".
Diviser les applications frontales en composants plus petits, tels que les composants publics, authentifiés et administratifs, afin de les compartimenter et de réduire la surface d’exposition potentiel
Stocker les données sensibles du site Web dans un méta-champ dédié et cacher les clés API au public.
Utiliser des certificats SSL pour tous les sites Web et les tenir à jour.
Faire preuve d'une extrême prudence lors de la sélection et de la mise en œuvre de scripts de tiers et de quatrième partie (c'est-à-dire, scripts provenant d'un fournisseur tiers).
Maintenir un inventaire dynamique de tous les scripts du site Web, y compris le code de tiers et de première partie.
Mettre en place une surveillance en temps réel avec système d’alerte pour détecter tout service tentant d'accéder à des données sensibles sur le site Web et de les divulguer.
Adopter une approche proactive de la sécurité côté client, en limitant les comportements des scripts de sites Web pour les empêcher de falsifier les formulaires et/ou de divulguer des données sensibles.

Face à la sophistication des attaques, il est important que les entreprises adaptent leur stratégie aux nouvelles pratiques des hackers. Ces derniers exploitent désormais le côté client des applications de service pour récupérer des données sensibles. Les e-commerçants ne peuvent donc plus ignorer cette faille. Ils doivent prendre en compte ces risques et les prévenir en contrôlant l’intégrité de leur script.