Les applications qui constituent la grande majorité des piles technologiques hypercomplexes d'aujourd'hui sont fortement dépendantes du code tiers. Malheureusement, les avantages considérables que procurent ces composants préfabriqués sont souvent compromis par les graves conséquences de l'architecture tierce sur la sécurité.
Il est essentiel pour les entreprises modernes non seulement de reconnaître ces risques, mais aussi de contribuer activement à endiguer le flux des attaques. Les outils de pointe, y compris une solution WAF de nouvelle génération, sont peut-être la seule façon de garantir l'existence des tiers.
1. Code tiers : Parce que pourquoi réinventer la roue ?
Le code tiers décrit toutes les lignes d'un programme qui peuvent être reproduites dans différentes applications. Cela facilite le processus de développement d'une application, car le recyclage du code permet de réduire considérablement le temps de mise sur le marché. Mais même une fois les bases d'une application posées, le code tiers peut être exploité par ses développeurs pour le suivi des publicités, les évaluations des clients, les paiements, les chatbots, la gestion des balises, l'intégration des médias sociaux ou d'autres bibliothèques d'aide qui simplifient les fonctions communes.
L'utilité et la disponibilité mêmes du code tiers l'ont vu s'infiltrer dans tous les coins d'internet : aujourd'hui, le code tiers représente jusqu'à 70 % de chaque site web. Dans la même enquête, 99 % des répondants ont déclaré que les sites utilisés et produits par leur organisation contiennent au moins un élément de code tiers.
L'open source décrit un type de code tiers, bien que le terme tiers désigne également un code développé en externe, dont la licence d'utilisation peut avoir été achetée. Quel que soit le prix commercial de ce code, les entreprises ont trop longtemps ignoré le coût social et sécuritaire.
2. Le danger caché du code fantôme
Le code tiers se prête au développement de sites et d'applications extrêmement accessibles. Bien que ces environnements sans code ou à faible code permettent de réduire la barrière d'entrée pour les entrepreneurs et les amateurs enthousiastes, il est essentiel de comprendre les risques. Les cybercriminels sont plus que désireux de profiter des développeurs naïfs ou négligents. Parfois, ce n'est pas le manque de compétences qui leur permet de s'infiltrer, mais la forte pression exercée pour un déploiement rapide.
Les attaquants regroupés sous l'égide de Magecart profitent de codes tiers depuis 2015. Ce syndicat du crime s'appuie sur le vol de cartes de crédit numériques, glissées en injectant secrètement du code JavaScript sur les pages de paiement du commerce électronique. Magecart a semé un sillage de destruction aux enjeux impressionnants : Ticketmaster, British Airways et d'innombrables autres marques en ligne sont toutes tombées sous le coup de leurs attaques.
Deux attaques très médiatisées ont eu lieu en 2020 : le fabricant de vêtements pour enfants Hanna Andersson et le détaillant britannique Sweaty Betty ont été visés. On pense que ces deux attaques tournaient autour d'addons de site apparemment inoffensifs. Cependant, cachés dans ces lignes de code, les attaquants de Magecart ajoutent quelques lignes clés de JavaScript.
Ce code tiers copie souvent les formulaires de paiement légitimes sur un site de commerce électronique. Cependant, il y a des modifications cruciales – minuscules – apportées. Par exemple, les informations de paiement sont secrètement envoyées à un serveur contrôlé par l'attaquant. La transaction elle-même est toujours autorisée, ce qui signifie que les utilisateurs finaux sont laissés dans l'ignorance totale.
L'attaque dont a fait l'objet Hanna Andersson est passée inaperçue pendant plusieurs semaines – même si cela représente une découverte relativement rapide, d'autres victimes restant dans l'ignorance pendant près d'un an. La plupart des victimes ne sont alertées que lorsque des informations de cartes de crédit volées apparaissent sur les marchés du dark web.
Le coût est important : Hanna Andersson a été condamnée à payer 400 000 dollars de dommages et intérêts à plus de 200 000 clients ; le coût exact pour les victimes individuelles est plus difficile à déterminer, mais le vol de leur nom, de leur adresse de livraison, de leur adresse de facturation et des informations relatives à leur carte de paiement permet aux attaquants de causer des dommages incroyables. Les attaques de Magecart ont gagné en popularité tout au long de la pandémie de Covid-19, enregistrant une augmentation de 20 %, tandis que le délai moyen de détection atteignait 22 jours.
Magecart peut représenter un code tiers malveillant, mais même un code open-source testé peut accidentellement causer l'un des plus grands problèmes de sécurité de cette décennie. Log4j décrit une bibliothèque de journalisation open-source qui est devenue l'une des pièces les plus importantes de l'architecture du web, chargée de relayer les informations de journalisation vitales à l'équipe de développement et de maintenance.
En 2021, cependant, il a été découvert que la bibliothèque log4j était gravement vulnérable à l'exécution de code à distance. Des centaines de millions d'appareils sont alors exposés à un risque grave, car la faille est également relativement simple à exploiter.
Il n'est pas réaliste de renoncer totalement au code tiers. Plus de 60 % des sites web dans le monde fonctionnent avec des serveurs Apache et Nginx, et 90 % des responsables informatiques utilisent régulièrement du code open source d'entreprise. Tous les logiciels modernes sont construits à partir de composants préexistants, et la reconstruction de ces fonctions à partir de zéro nécessiterait des investissements massifs en temps et en argent pour produire des applications même relativement simples.
3. Vous ne pouvez pas vous en sortir avec un patch.
Une fois intégré à une application, le code tiers peut être difficile à tester, et encore plus difficile à sécuriser. Les correctifs dépendent entièrement des développeurs ; même pour les développeurs actifs et bien intentionnés, comme ceux qui maintiennent la fonctionnalité log4j, les correctifs prennent un temps critique.
N'ayez crainte : une solution de sécurité complète peut offrir plusieurs outils permettant d'appliquer virtuellement des correctifs et, en fin de compte, de stopper les attaquants dans leur élan. L'un de ces outils est le pare-feu d'application Web (WAF). Il s'interpose entre l'application et l'utilisateur final, surveillant et filtrant le trafic qui passe. Les WAF de nouvelle génération proposent la création automatique de politiques, ainsi que la propagation rapide des règles, afin d'élargir explicitement le filet de sécurité dont le code tiers a besoin.
Alors que le WAF traditionnel se concentre principalement sur la surveillance des connexions externes, la protection des applications et API Web (WAAP) décrit une suite de protection plus complète. Elle intègre l'approche du WAF basée sur le pare-feu, tout en se concentrant davantage sur les API. Ces éléments de code fournissent un accès programmatique à différentes applications et ont historiquement constitué un point faible majeur dans les défenses des organisations.
Enfin, l'autoprotection des applications au moment de l'exécution (RASP) offre une nouvelle étape convaincante vers la protection automatisée. Au lieu de se situer à l'extérieur du code de l'application, RASP agit comme un plugin, en s'attachant aux internes de l'application. Grâce à sa vue interne d'une application, RASP peut surveiller ses comportements et cartographier les connexions et les privilèges typiques qui se produisent sous le capot. Une fois qu'un comportement de base est établi, RASP peut alors détecter automatiquement – et, surtout, arrêter – les comportements suspects.
Avec une suite proactive de mesures de correctifs virtuels en place, votre sécurité est en mesure de suivre le rythme de DevOps, tout en aidant à annuler la menace des cybercriminels et les poursuites judiciaires qui en découlent.