Résumé

  • Un site qui chargeaitcdn.polyfill.ione faisait pas que citer un projet open source. Il permettait à un service distant en direct de sélectionner du JavaScript et de le renvoyer pour exécution dans le contexte du navigateur du site. L'objet de confiance incluait donc le domaine, l'opérateur, le routage et le chemin de réponse, pas seulement le code source qui pouvait être inspecté ailleurs. [15][16][17]
  • Le contrôle du domaine Polyfill.io et de la présence associée du projet a changé en février 2024. Fastly, Cloudflare et un problème du projet FormatJS ont réagi à ce moment, montrant qu'une réévaluation en aval était possible avant que la livraison malveillante ne soit signalée publiquement en juin. Le transfert lui-même ne doit pas être décrit comme une preuve d'intention malveillante. [2][3][4]
  • Sansec a rapporté le 25 juin que le service renvoyait sélectivement du JavaScript modifié qui redirigeait les visiteurs qualifiés. Cloudflare a déclaré que les indicateurs Page Shield incluaient des correspondances dès le 8 juin, tandis qu'Akamai décrivait un échantillonnage côté serveur suivi de vérifications côté client. Ces observations établissent une campagne de redirection, pas toutes les actions qu'un fournisseur de JavaScript distant pourrait théoriquement effectuer. [1][5][9]
  • L'estimation de Sansec de plus de 100 000 sites concernait les sites intégrant ou utilisant le service. Cloudflare a cité une estimation d'utilisation approchant quatre pour cent des sites web. Aucun des deux chiffres n'est un nombre vérifié de sites qui ont servi la branche malveillante, redirigé des visiteurs ou subi des pertes. [1][5]
  • La réécriture automatique de Cloudflare et le blocage du domaine par Namecheap ont contraint le chemin de livraison. Ils n'ont pas supprimé les références obsolètes du code en aval, établi ce que chaque visiteur précédent avait reçu ou achevé l'enquête de chaque propriétaire de site. [5][6][10]
  • Fides, Jellyfish et Wordfence illustrent trois tâches de preuve différentes: déterminer si un chemin conditionnel était accessible, tracer un fournisseur transitif, vérifier la suppression, et éviter de traiter une référence au point d'accès comme une preuve d'exploitation. [11][12][13][14][22]
  • La responsabilité ici n'est pas une conclusion juridique ou une affirmation de blâme égal. Cela signifie que chaque partie doit être responsable des contrôles qu'elle pouvait effectivement exercer. Les propriétaires de sites ont conservé le contrôle sur la nécessité, l'inventaire, le choix du fournisseur, l'hébergement propre, la surveillance de la propriété, l'observation côté navigateur, l'enquête, la réparation et la communication.

Un script tag déléguait une autorité, pas seulement une commodité

La décision technique centrale semblait ordinaire. Un site web plaçait un élémentscriptdans une page et le pointait verscdn.polyfill.io. Lorsqu'un visiteur chargeait cette page, le navigateur demandait du JavaScript au service distant. Le service pouvait inspecter les caractéristiques de la requête et fournir des polyfills adaptés au navigateur, permettant aux navigateurs plus anciens d'utiliser des fonctionnalités web qu'ils n'implémentaient pas nativement.

Cet arrangement résolvait un problème pratique de compatibilité. Au lieu d'envoyer toutes les fonctions de compatibilité à chaque visiteur, un site pouvait demander à un service spécialisé de renvoyer ce dont un navigateur particulier semblait avoir besoin. Le résultat pouvait être plus petit et plus facile à maintenir qu'un bundle local universel. Mais l'efficacité provenait du maintien de la réponse dynamique. Le site web ne téléchargeait pas simplement un paquet fixe pendant le développement et ne déployait pas des octets révisés depuis sa propre infrastructure.

Il invitait un autre opérateur à décider, au moment du chargement de la page, quels octets un visiteur exécuterait.

La distinction détermine le cadre de responsabilité. Un dépôt open source est un code et un historique inspectables. Un service hébergé est une relation opérationnelle. Le service en direct dépend d'un domaine, du DNS, du routage, de l'hébergement, des certificats, de l'accès au déploiement et des personnes ou organisations capables de modifier la réponse. Un site web peut faire confiance au code public tout en échouant à examiner si le point d'accès servant ses visiteurs reste sous le même contrôle, suit le même processus ou renvoie la même classe de sortie.

HTTPS ne résout pas ces questions. Il peut aider un navigateur à authentifier qu'il a atteint le détenteur de l'autorité valide pour le domaine demandé et protéger la réponse en transit. Il ne promet pas que le détenteur du domaine est inchangé, que le programme renvoyé est bienveillant ou que le contenu est invariant entre les requêtes. Lorsque le contrôle du domaine change légitimement, HTTPS peut continuer à fonctionner exactement comme prévu tout en authentifiant une nouvelle réalité opérationnelle.

Le navigateur donne au JavaScript chargé à distance une influence pratique étendue sur la page qui l'inclut. La portée précise dépend de la page et des contrôles du navigateur, mais la faiblesse de base est bien établie: la fonctionnalité tierce s'exécute dans le contexte web de la première partie. MITRE's CWE-830 décrit cette classe d'inclusion comme un transfert de confiance vers du code d'un autre domaine, et OWASP traite le JavaScript tiers comme un problème de gouvernance car il peut affecter les données et le comportement de la page.

Les conseils de GitHub CodeQL appliquent la même logique aux fonctionnalités chargées depuis un domaine non fiable. [15][16][17]

C'est pourquoi l'incident ne devrait pas être réduit à "l'open source est devenu dangereux." Le code open source original, une copie hébergée localement et révisée, et un service contrôlé par un domaine en direct étaient des objets de confiance distincts. Un site web utilisant une copie locale fixe ne faisait pas la même délégation au moment de l'exécution qu'un site web demandant une réponse changeante àcdn.polyfill.io. Un hôte alternatif créait également une relation opérationnelle différente, même s'il servait du code dérivé du même projet.

La première question de responsabilité n'est donc pas de savoir si les développeurs doivent se méfier de toutes les bibliothèques externes. C'est de savoir si le site web savait quelle partie pouvait choisir des octets exécutables pour ses visiteurs au moment de l'utilisation. Un inventaire utile répondrait à au moins cinq questions: quelles pages demandaient le script, si l'inclusion était directe ou transitive, quels utilisateurs et chemins de navigateur pouvaient y accéder, quelle fonction commerciale l'exigeait, et qui contrôlait actuellement le point d'accès.

Ces questions appartiennent au propriétaire du site web car le site web rendait l'inclusion effective. Un visiteur n'a pas négocié avec Polyfill.io ni choisi son opérateur. Le visiteur demandait une page au site web et expérimentait raisonnablement les scripts renvoyés comme faisant partie de cette page. Même lorsqu'un thème, un plugin, un gestionnaire de balises ou un fournisseur insérait la référence, l'organisation en aval restait la partie présentant l'expérience combinée à ses utilisateurs.

Cela ne fait pas du propriétaire du site web l'auteur du code malveillant ni n'efface le contrôle de l'opérateur du service. Cela signifie que le pouvoir délégué n'élimine pas la responsabilité de première partie. L'opérateur du service pouvait choisir la réponse. Le propriétaire du site web pouvait choisir si cet opérateur conservait une place dans la page. Ce sont des contrôles différents, et l'incident a testé les deux.

Le transfert de février était un événement de gouvernance logicielle

La chronologie publique fournit un intervalle d'avertissement inhabituellement important. En février 2024, le contrôle du domaine Polyfill.io et de la présence GitHub associée a été transféré à Funnull, comme décrit dans les sources contemporaines. Les sources établissent un changement de contrôle et de base de confiance. Elles n'établissent pas, par ce seul fait, le motif du nouvel opérateur, un plan criminel, une violation légale ou l'identité ultime de chaque personne qui a ensuite influencé la livraison.

Pour un site web informationnel conventionnel, un transfert de domaine peut surtout changer l'autorité de publication. Pour un domaine qui renvoie du JavaScript exécutable à d'autres sites web, le transfert change qui peut influencer le logiciel fonctionnant sur ces pages en aval. Cela fait de l'information sur la propriété une partie de l'état de la dépendance. Un nouveau propriétaire du point d'accès est opérationnellement comparable à un nouveau mainteneur, une autorité de signature ou un canal de publication, même lorsque le dépôt source semble familier.

L'avis de Fastly du 28 février rend visible la signification de gouvernance. Il annonçait des domaines de remplacement et donnait aux utilisateurs des options incluant la migration, l'auto-hébergement ou la suppression du service. Ces options n'étaient pas simplement des alternatives de marque. Chacune changeait qui contrôlerait les octets livrés aux visiteurs. La migration sélectionnait une relation de service différente. L'auto-hébergement plaçait la livraison sous les propres contrôles de déploiement du site web. La suppression éliminait la dépendance de compatibilité si elle n'était plus nécessaire. [3]

Cloudflare a suivi le 29 février avec une alternative hébergée sur cdnjs. Son explication reliait la transition de fournisseur au risque de chaîne d'approvisionnement: les sites web s'étaient appuyés sur une autre partie pour maintenir et sécuriser un service qui pouvait exécuter du code dans leurs pages. L'alternative de Cloudflare ne rendait pas l'hébergement tiers sans risque, mais elle montrait que les fournisseurs d'infrastructure comprenaient le changement de propriété comme un motif pour une nouvelle décision de confiance. [2]

Un problème FormatJS ouvert le 28 février fournit un enregistrement de projet en aval de la même période. Il soulevait des préoccupations concernant la propriété et la relation CNAME et demandait au projet de cesser de recommander le point d'accès. Cet enregistrement est important car il montre un mainteneur agissant sur une dépendance de documentation avant qu'une campagne malveillante ne soit signalée publiquement. Supprimer une recommandation ne répare pas chaque site web qui l'a suivie auparavant, mais cela limite la propagation future et crée un avertissement traçable. [4]

Ensemble, ces enregistrements empêchent un récit trop commode dans lequel les propriétaires en aval n'avaient aucun signal avant le 25 juin. Tous les propriétaires de site n'auraient pas vu l'avis de Fastly, le post de Cloudflare ou le problème FormatJS. Les sources n'établissent pas un avis universel, et il serait injuste de convertir la disponibilité publique en preuve que chaque organisation savait réellement. Ils établissent que le changement de propriété était observable, que des alternatives étaient disponibles et que certaines parties responsables ont réévalué le point d'accès des mois avant le rapport d'incident.

Cette distinction est essentielle à la responsabilité. Un devoir de surveillance ne signifie pas l'omniscience. Cela signifie concevoir un processus qui peut recevoir les changements pertinents pour les dépendances à haute autorité. Un site peut suivre les avis de paquets tout en ignorant les changements de domaine, de DNS ou d'hébergement. Pour un paquet versionné, les flux de publication et de vulnérabilité peuvent être les signaux importants. Pour un point d'accès de script distant, l'enregistrement, le DNS, l'opérateur et le comportement de réponse appartiennent également au modèle de surveillance.

L'événement de février expose également les limites d'une révision unique de fournisseur. Une équipe peut avoir approuvé Polyfill.io des années plus tôt sur la base de l'opérateur, de l'infrastructure, de la réputation du projet et des besoins de navigateur de l'époque. Si l'enregistrement d'approbation ne contenait que la chaînecdn.polyfill.io, l'équipe pourrait traiter par erreur la dépendance comme inchangée tant que l'URL restait inchangée. En réalité, la partie derrière le nom stable avait changé.

Une approbation responsable devrait enregistrer la base de confiance, pas seulement l'adresse. Cette base pourrait inclure l'opérateur, le but du service, les caractéristiques de réponse attendues, la relation contractuelle ou communautaire, les preuves d'audit disponibles, le plan de repli et les déclencheurs de révision. Le transfert de propriété invaliderait ou du moins rouvrirait l'approbation. Sans un tel enregistrement, une organisation ne peut pas facilement expliquer pourquoi la délégation continue restait justifiée après que la prémisse ait changé.

La question de la nécessité aurait également dû être rouverte. Les polyfills sont liés aux capacités du navigateur. Les populations de navigateurs évoluent, les politiques de support des produits changent, et le code de compatibilité qui était autrefois essentiel peut devenir résiduel. Une dépendance distante avec une autorité au niveau de la page ne devrait pas persister simplement parce que personne ne possède sa suppression. Les avis de février offraient un moment pour se demander si le support des navigateurs plus anciens nécessitait encore le point d'accès et si un petit bundle local pouvait répondre au besoin restant.

Rien de tout cela ne prouve que chaque site conservant la référence a agi avec négligence, et cela ne transforme pas le transfert de domaine lui-même en une attaque. Cela établit un point plus étroit: le transfert a modifié un contrôle logiciel matériel avant même que des sorties nuisibles ne soient observées. La responsabilité du site web commence par la question de savoir si ce changement matériel était détectable et révisable.

La livraison sélective rendait l'inspection occasionnelle peu fiable

Le 25 juin, Sansec a rapporté quecdn.polyfill.iolivrait du JavaScript modifié via des sites web qui l'intégraient. Le comportement observé redirigeait les visiteurs sélectionnés vers des domaines conçus pour ressembler à Google Analytics vers des destinations d'escroquerie ou de paris. Sansec décrivait des conditions incluant le ciblage mobile, des vérifications côté serveur et côté client, un comportement temporel, et l'évitement de certains contextes d'administrateur ou d'analyse. [1]

L'acte observé nécessite un nom précis. C'était une campagne de redirection livrée via du JavaScript modifié. L'enregistrement ne soutient pas l'élévation de cette observation à un vol d'identifiants, un vol de données de page, un compromis d'hôte, une exécution de code en dehors du navigateur ou une perte financière quantifiée. Un point d'accès de script contrôlé à distance pourrait, en principe, renvoyer du JavaScript capable d'une gamme beaucoup plus large d'actions de navigateur. CNCF TAG Security, CWE-830 et le modèle général d'exécution du navigateur soutiennent cette conclusion de capacité.

La capacité n'est pas une preuve que chaque action possible s'est produite. [8][16]

Cloudflare a déclaré que ses données Page Shield corroboraient les indicateurs et incluaient des correspondances dès le 8 juin. C'est la correspondance la plus précoce dans l'ensemble de données de Cloudflare décrit dans l'enregistrement source. Ce n'est pas une preuve que toute l'activité malveillante a commencé à cette date, que la même branche a atteint chaque site en continu à partir de ce moment, ou qu'aucune livraison antérieure n'a eu lieu en dehors de la visibilité de Cloudflare. [5]

Akamai a décrit séparément un modèle en deux étapes dans lequel la sélection côté serveur basée sur les en-têtes de requête pouvait déterminer ce qui était envoyé, suivie de vérifications côté client avant la redirection. Cette architecture explique pourquoi une inspection ordinaire pouvait manquer le problème. Un développeur demandant le script depuis un navigateur de bureau pouvait recevoir un polyfill attendu. Un visiteur mobile avec des en-têtes, un emplacement, un moment ou un état de page différents pouvait recevoir ou activer une autre branche. [9]

La livraison sélective modifie la charge probatoire. Un seul téléchargement propre ne prouve pas la sécurité historique. Une comparaison de code source depuis un navigateur à un moment donné peut ne montrer que la réponse sélectionnée pour cette requête. Un robot d'exploration de moteur de recherche, un moniteur de disponibilité ou un scanner de sécurité peut avoir des caractéristiques délibérément exclues par la logique de livraison. Un administrateur testant alors qu'il est connecté peut voir un comportement différent d'un visiteur pour la première fois.

Cela ne signifie pas que la détection était impossible. Cela signifie que la surveillance devait correspondre à la variabilité de la dépendance. Une observation utile échantillonnerait les navigateurs, appareils, emplacements et conditions de requête; préserverait les corps de réponse et les hachages au fil du temps; détecterait les nouveaux domaines et chaînes de redirection; et comparerait le comportement vu par les vrais clients avec le but déclaré du service. La surveillance côté client jouait un rôle important car le programme conséquent était assemblé et exécuté dans le navigateur.

L'incident illustre également comment l'optimisation peut devenir un camouflage. Le ciblage dynamique du navigateur faisait partie du modèle de service légitime de Polyfill.io: le service sélectionnait le code de compatibilité en fonction des capacités du navigateur. Une branche malveillante pouvait exploiter l'attente selon laquelle les réponses diffèrent naturellement. La variabilité elle-même n'était pas une preuve d'abus. Elle rendait un modèle simple de "hachage connu égale service sûr" plus difficile à appliquer et donnait à la livraison sélective une marge de manœuvre pour se cacher dans un modèle de fonctionnement accepté.

La responsabilité dépend donc de la définition de la variabilité attendue. Un site web devrait être capable de déclarer quels attributs de requête le fournisseur utilise légitimement, quelles familles de code peuvent être renvoyées, quelles destinations le script peut contacter et quelles actions de page sont en dehors du but. Sans cette base de référence, la surveillance peut observer un changement sans savoir si le changement est autorisé.

L'échantillonnage côté serveur complique également l'enquête rétrospective. Le dépôt statique d'un site peut contenir seulement l'URL du script, pas les octets malveillants qu'un visiteur a reçus. Les octets provenaient d'un autre système au moment de la requête et peuvent ne plus être disponibles après le confinement. La télémétrie du navigateur, les journaux du CDN, les réponses sauvegardées, les rapports de sécurité du contenu et les enregistrements du point d'accès peuvent être les seules preuves pour reconstruire la portée.

Si ces enregistrements n'ont jamais été collectés ou ont été conservés trop brièvement, un site peut être incapable de répondre quels visiteurs ont rencontré la branche.

Cette incertitude ne devrait pas être cachée avec une affirmation large selon laquelle tout le monde était en sécurité ou tout le monde était compromis. Une déclaration d'incident responsable peut plutôt définir ce qui a été trouvé: le point d'accès était référencé; un chemin conditionnel particulier était accessible ou non; la télémétrie couvrait des dates et populations spécifiées; les redirections observées correspondaient ou non aux indicateurs connus; et des lacunes subsistent pour les requêtes en dehors des preuves conservées.

La livraison sélective est donc centrale au test de responsabilité. Elle explique comment une sortie nuisible pouvait coexister avec une inspection bénigne, pourquoi les références de point d'accès ne sont pas des décomptes de victimes, et pourquoi une remédiation vérifiée nécessite plus que de charger la page une fois après que le domaine a été suspendu.

Les estimations d'échelle n'étaient pas des décomptes de victimes

Sansec décrivait plus de 100 000 sites comme intégrant ou utilisant le service. Cloudflare citait des estimations selon lesquelles Polyfill.io apparaissait sur près de quatre pour cent des sites web. Ces chiffres transmettent l'ampleur potentielle d'un service largement réutilisé. Ils ne partagent pas le même dénominateur, et aucun n'établit un ensemble complet de compromissions confirmées. [1][5]

Plusieurs populations doivent rester séparées. L'une est l'ensemble des sites web dont le code actuel ou historique référençait un point d'accès Polyfill.io. Une autre est l'ensemble pour lequel le chemin d'inclusion pertinent était accessible en production. Une troisième est l'ensemble qui a demandé une réponse malveillante pendant la campagne. Une quatrième est l'ensemble dont les visiteurs satisfaisaient les conditions côté serveur et côté client. Une cinquième est les visiteurs qui ont effectivement été redirigés. Une sixième est toute population qui a subi une perte mesurable ultérieure.

L'enregistrement public disponible ne fournit pas de décompte vérifié pour la plupart de ces groupes. Il serait donc inexact d'appeler chaque référence une victime, chaque site incluant compromis ou chaque visiteur exposé. Il serait également inexact de rejeter les références comme inoffensives simplement parce que la livraison sélective empêchait une observation universelle. Une référence établit un chemin de confiance. Des preuves supplémentaires sont nécessaires pour établir l'accessibilité, la livraison et l'impact.

Ce vocabulaire est important pour les avis en aval. "Notre code contenait une référence" est différent de "notre télémétrie montre que le script a été demandé." Les deux diffèrent de "nous avons observé la branche malveillante" et de "un visiteur a signalé une redirection." Les combiner peut créer une alarme inutile ou une fausse réassurance. Les séparer permet aux utilisateurs de comprendre ce que l'organisation sait.

Le traitement par Wordfence des modèles de plugins WordPress affectés renforce cette frontière. Son catalogue identifiait les utilisations de Polyfill.io mais avertissait de supposer que chaque instance de plugin livrait du contenu malveillant. Les plugins pouvaient introduire le point d'accès dans de nombreux sites, rendant le travail d'inventaire urgent, tandis que la présence du code était encore insuffisante pour prouver l'exécution malveillante dans chaque installation. [14]

Les rapports gouvernementaux répétaient la préoccupation sérieuse d'échelle tout en concentrant les opérateurs sur la suppression et l'enquête. CERT-AGID décrivait l'acquisition et la livraison dépendante des en-têtes et se référait au chiffre de plus de 100 000. Cet avertissement indépendant soutient une attention défensive large, mais il ne transforme pas le dénominateur en visiteurs affectés confirmés. [21]

La déclaration d'échelle la plus forte est donc aussi la plus bornée: le point d'accès avait une grande empreinte en aval, et la campagne sélective observée créait un risque à travers cette empreinte. L'impact exact devait être établi site par site et population de visiteurs par population de visiteurs.

Le confinement a changé le chemin; il n'a pas achevé la remédiation

La réponse impliquait des parties avec différents types de contrôle. Cloudflare a automatiquement réécrit les références Polyfill.io sur les pages client proxifiées vers un miroir hébergé par Cloudflare. L'entreprise expliquait que simplement bloquer le domaine original pourrait casser les sites dépendant encore du service. La réécriture tentait de préserver la compatibilité attendue tout en supprimant la dépendance immédiate au point d'accès modifié. [5]

Cette intervention illustre un véritable compromis opérationnel. Les équipes de sécurité préfèrent souvent la suppression immédiate d'une ressource suspecte. Les équipes produit savent que supprimer brusquement une couche de compatibilité peut rendre un site inutilisable pour certains visiteurs. La position de Cloudflare dans la chaîne de livraison lui permettait de substituer une source différente sans attendre que chaque propriétaire de site déploie un changement.

La substitution était un confinement, pas une preuve de réparation complète. Elle changeait l'opérateur de confiance et le chemin de réponse pour le trafic couvert par le mécanisme. Elle n'établissait pas que le remplacement avait un comportement identique pour chaque navigateur, que toutes les pages et chemins de livraison étaient couverts, ou que les dépôts en aval ne contenaient plus l'ancienne référence. Elle ne répondait pas non plus à ce que les visiteurs avaient reçu avant la réécriture.

Namecheap a ensuite mis le domaine Polyfill.io en attente, et les avis gouvernementaux décrivaient le point d'accès comme suspendu d'ici le 27 juin. L'action au niveau du domaine supprimait le chemin de service immédiat mais pouvait aussi casser les sites qui attendaient encore une réponse. La mise en attente était un levier de confinement important détenu par le bureau d'enregistrement. Elle n'a pas nettoyé les modèles en aval, les paramètres de plugins, les pages en cache, les configurations de gestionnaire de balises ou les produits fournisseurs. [6][10]

La différence devient plus claire lorsque le domaine est indisponible. Un site peut sembler protégé parce que le navigateur ne peut plus récupérer le script suspect. Pourtant, la référence obsolète reste une dépendance non résolue. Si le statut de contrôle change à nouveau, si un nom d'hôte alternatif persiste, ou si une copie interne n'a pas été examinée, le problème de gouvernance sous-jacent demeure. Même un point d'accès définitivement mort peut imposer des coûts de performance, de gestion des erreurs et de compatibilité.

CERT-FR et la Western Australia Cyber Security Unit conseillaient aux opérateurs d'identifier et de supprimer les références, de passer à une alternative contrôlée si nécessaire, et de considérer les contrôles de navigateur tels que Subresource Integrity et Content Security Policy. Semgrep se concentrait également sur la détection à l'échelle du dépôt plutôt que de traiter la suspension du domaine comme suffisante. [6][7][20]

Cette séquence suggère quatre revendications de fermeture distinctes. "Confiné" signifie que le chemin de livraison nuisible connu a été interrompu. "Supprimé" signifie que la référence en aval et les chemins d'insertion transitifs ont disparu. "Enquêté" signifie que les preuves disponibles ont été utilisées pour évaluer la portée et l'impact historiques. "Vérifié" signifie que les tests et la surveillance démontrent que le site actuel ne dépend plus de l'ancien chemin et que le remplacement se comporte dans son cadre prévu.

Un propriétaire de site web pouvait compter sur un fournisseur d'infrastructure pour la première revendication tout en possédant les trois autres. Cloudflare pouvait réécrire le trafic qu'il voyait. Namecheap pouvait suspendre un domaine qu'il enregistrait. Aucun ne pouvait connaître chaque endroit où un client avait intégré l'URL, chaque chemin de navigateur conditionnel à l'intérieur d'un plugin, ou chaque population de visiteurs que le site web devait enquêter.

Cette séparation protège également contre la surestimation de l'intervention tierce. Une mise en attente par un bureau d'enregistrement n'est pas une conclusion d'attribution. Une réécriture automatique n'établit pas que chaque client protégé avait servi la branche malveillante. Une correspondance d'indicateur d'un fournisseur de détection n'est pas un rapport médico-légal complet pour chaque site. Chaque action doit être décrite selon le contrôle qu'elle exerçait et les preuves qu'elle produisait.

Opérationnellement, la remédiation en aval devrait commencer par une recherche complète. Le nom d'hôte littéral peut apparaître dans les fichiers source, les bundles générés, les champs de gestion de contenu, le code de plugin, les gestionnaires de balises, les modèles, les configurations archivées ou les réponses fournisseurs. Les outils de recherche peuvent trouver les chaînes connues, mais un inventaire des dépendances doit également expliquer qui a introduit la référence et quel chemin de construction ou d'exécution l'a rendue active.

La suppression nécessite ensuite une décision fonctionnelle. Si le polyfill n'est plus nécessaire, l'éliminer est la réduction d'autorité la plus nette. Si le support des navigateurs hérités reste requis, un bundle local révisé ou un fournisseur explicitement approuvé peut être approprié. Le remplacement ne doit pas être choisi simplement parce que son URL est pratique. Son opérateur, son processus de mise à jour, sa variabilité de réponse et son modèle de surveillance deviennent partie de la nouvelle base de confiance.

Enfin, l'évaluation historique nécessite des preuves proportionnelles au risque du site. Les observations côté navigateur, les journaux réseau, les rapports de sécurité, les plaintes des clients et les réponses de script préservées peuvent aider à déterminer si des indicateurs de redirection connus sont apparus. L'absence de preuve doit être liée à la couverture. Un site sans télémétrie client conservée peut dire qu'il n'a trouvé aucun rapport ou indicateur dans les enregistrements disponibles; il ne peut pas convertir des enregistrements manquants en preuve qu'aucun visiteur n'a reçu la branche.

Fides a montré pourquoi une branche conditionnelle compte encore

CVE-2024-38537 enregistre un problème en aval dans Fides. Le cheminfides.jspertinent pouvait charger Polyfill.io pour les navigateurs hérités. L'enregistrement identifie les versions affectées et dit que la version 2.39.1 a supprimé l'exposition. Il préserve également une frontière importante: aucune exploitation via Fides n'avait été identifiée. [11][12]

Ce cas est utile car il résiste à deux erreurs opposées. La première serait de rejeter le problème parce que seul un chemin de navigateur plus ancien chargeait le point d'accès. L'accessibilité conditionnelle est toujours une accessibilité. Si une page de production pouvait demander du JavaScript distant pour une population de visiteurs prise en charge, la dépendance appartenait à l'inventaire de sécurité du produit même si la plupart des développeurs ne la déclenchaient jamais.

La seconde erreur serait de traiter le CVE comme une preuve que les utilisateurs de Fides ont été exploités. Un enregistrement de vulnérabilité peut établir un chemin d'inclusion dangereux et des versions affectées sans établir que la branche malveillante a atteint un déploiement particulier. "Pouvait charger" et "a été observé en train d'exploiter" répondent à des questions différentes. L'enregistrement Fides maintenait explicitement cette distinction.

La remédiation démontre également pourquoi la réparation versionnée est importante. Supprimer la dépendance distante dans une version nommée donne aux opérateurs en aval une action concrète et une frontière traçable. Ils peuvent identifier les versions déployées, mettre à niveau, rechercher les références restantes et tester le chemin hérité. Un avertissement général de "faire attention avec Polyfill.io" ne fournirait pas la même preuve de fermeture.

La condition héritée devrait façonner la vérification. Tester seulement un navigateur de bureau moderne pourrait ne jamais exécuter la branche affectée. La vérification devrait reproduire ou inspecter la condition qui l'a originalement sélectionnée. Cela peut nécessiter de réviser le code groupé, de simuler un agent utilisateur plus ancien, de vérifier les requêtes réseau et de confirmer que la version réparée ne construit ni ne demande plus le point d'accès.

Le bulletin de SingCERT discutait également du cas Fides en aval et conservait la frontière d'absence d'exploitation observée. La répétition par un CERT national augmente la visibilité du problème; elle ne convertit pas la possibilité en exploitation observée. [22]

La leçon de Fides n'est donc pas que chaque demande conditionnelle à un tiers mérite la même sévérité. C'est qu'un mainteneur devrait connaître la condition, les versions affectées, la population accessible, la version de remédiation et la frontière de preuve. La responsabilité est la plus forte lorsqu'un enregistrement de vulnérabilité formel dit à la fois ce qui pouvait arriver et ce qui n'a pas été observé.

Jellyfish a montré comment tracer une dépendance transitive

L'avis de Jellyfish documentait un chemin différent. Son service dépendait d'un fournisseur qui pouvait charger Polyfill.io dans des conditions spéciales. Jellyfish a identifié la relation transitive, contacté le fournisseur, vérifié la suppression et délimité la population de navigateurs qui aurait pu atteindre le chemin. [13]

Cette séquence est un modèle pratique car elle commence par l'architecture plutôt que par l'accusation. Une organisation orientée client peut ne pas avoir placé directement la balise script dans son propre dépôt. La référence peut provenir d'un composant d'analyse, d'un outil de consentement, d'un plugin, d'un widget de support ou du code d'un autre fournisseur. La propriété directe de la ligne n'est pas la même que le contrôle sur l'expérience utilisateur.

Les dépendances transitives créent un problème de preuve. Une nomenclature logicielle orientée vers les paquets installés au moment de la construction peut ne pas inclure un domaine qu'un fournisseur demande dynamiquement dans le navigateur. Les inventaires contractuels peuvent nommer le fournisseur mais pas les propres fournisseurs de scripts du fournisseur. La surveillance réseau peut voir le nom d'hôte sans identifier le propriétaire commercial qui l'a introduit. Les trois vues sont nécessaires pour relier une demande à une relation responsable.

La séquence de réponse de Jellyfish comble ces lacunes. Premièrement, identifier que la dépendance existe et les conditions dans lesquelles elle peut être invoquée. Deuxièmement, la mapper à la relation fournisseur. Troisièmement, demander à la partie ayant le contrôle du code de la supprimer. Quatrièmement, vérifier le changement plutôt que de traiter l'assurance du fournisseur comme la fin de l'affaire. Cinquièmement, délimiter la population en utilisant les meilleures preuves de navigateur et de produit disponibles.

La vérification est particulièrement importante lorsque la condition est inhabituelle. Un fournisseur pourrait supprimer une référence visible tandis qu'un repli, un bundle plus ancien ou un actif en cache la contient encore. Le client devrait tester de l'extérieur aussi bien qu'accepter la confirmation interne. La capture réseau sur les navigateurs pertinents, les scans de dépôt ou de bundle, et la surveillance côté client peuvent montrer si la requête a effectivement disparu.

La population délimitée devrait conserver son dénominateur. Si seulement certaines versions de navigateur ou flux de page pouvaient déclencher le chemin fournisseur, l'enquête peut réduire la portée potentielle. Elle ne devrait pas impliquer que chaque membre de ce groupe de navigateurs a reçu du contenu malveillant. Inversement, le fait qu'un chemin soit rare n'excuse pas de ne pas le supprimer. Les chemins rares reçoivent souvent moins de tests de routine, ce qui peut en faire des endroits attrayants pour que les dépendances persistent inaperçues.

Jellyfish démontre également une responsabilité partagée mais non fongible. Le fournisseur contrôlait son code et pouvait supprimer l'inclusion. Jellyfish contrôlait l'escalade fournisseur, l'enquête orientée client et l'acceptation de la réparation. Les fournisseurs d'infrastructure et de sécurité pouvaient contribuer à la télémétrie. Aucune de ces parties ne pouvait se substituer complètement à une autre.

Ce modèle s'étend au-delà de cet incident. Une organisation en aval a besoin d'une voie d'escalade pour tout fournisseur capable d'introduire du code exécutable. Le contrat ou le processus d'intégration technique devrait identifier qui peut répondre aux questions urgentes sur les dépendances, à quelle vitesse un script tiers peut être désactivé, quels journaux sont disponibles et comment le client peut vérifier un changement.

Les plugins WordPress ont montré pourquoi les références et l'exploitation doivent rester séparées

Wordfence a catalogué l'utilisation de Polyfill.io dans divers modèles de plugins WordPress. Ce type d'inventaire est précieux car les plugins peuvent distribuer une dépendance externe unique à travers de nombreux sites web exploités indépendamment. Une petite décision de mainteneur peut devenir une large relation de confiance en aval sans que chaque propriétaire de site ajoute consciemment le point d'accès. [14]

Le catalogue portait également un avertissement crucial: l'utilisation du point d'accès ne prouvait pas que chaque plugin ou site livrait du contenu malveillant. La référence identifiait un chemin d'exécution potentiel. Que ce chemin soit actif dépendait de la version du plugin, de la configuration, du rendu de la page, de la mise en cache, des conditions du navigateur et de la réponse distante au moment considéré.

Pour un propriétaire de site WordPress, la réponse correcte n'est pas de débattre pour savoir si l'auteur du plugin ou l'opérateur du service est "la" partie responsable. Les tâches immédiates sont locales: identifier les versions installées et actives, déterminer quelles pages rendent la référence, mettre à jour ou supprimer les composants affectés, effacer les actifs générés si nécessaire, et vérifier le comportement réseau du site public.

Le mainteneur du plugin a un ensemble différent de tâches. Il peut supprimer la dépendance, publier une version corrigée, expliquer les conditions affectées, mettre à jour la documentation et notifier les utilisateurs. Un dépôt de plugin ou un service de sécurité peut distribuer des avertissements. Le propriétaire du site doit encore déployer le changement. Une version corrigée restant non installée ne modifie pas le chemin du navigateur.

C'est une autre raison pour laquelle les chiffres d'échelle ne doivent pas être lus comme un décompte d'organisations lésées. Un plugin peut créer des milliers de références; un site peut contenir plusieurs plugins avec le même nom d'hôte; un plugin dormant ou désactivé peut rester sur le disque sans rendre le script; et une page publique en cache peut continuer à servir une ancienne référence après des modifications du code source. Compter les chaînes, les installations, les requêtes actives et les livraisons malveillantes produit des nombres différents.

Un écosystème responsable maintient ces mesures étiquetées. L'intelligence de sécurité peut publier une liste d'exposition large pour accélérer l'action. Les mainteneurs peuvent indiquer les versions affectées. Les propriétaires de sites peuvent rapporter l'accessibilité déployée. Les enquêteurs d'incident peuvent rapporter les indicateurs observés. Aucun ne devrait emprunter la certitude des autres.

SRI et CSP étaient des contrôles, pas des réponses magiques

Subresource Integrity, ou SRI, permet à un auteur de page de fournir un digest cryptographique pour une ressource externe. Un navigateur compatible peut récupérer la ressource et refuser de l'exécuter si les octets renvoyés ne correspondent pas au digest attendu. La spécification du W3C et les conseils de mise en œuvre de MDN présentent SRI comme un moyen d'empêcher un hôte tiers compromis de modifier silencieusement une ressource que le site incluant s'attend à voir fixe. [18][19]

C'est un contrôle fort pour un script stable. Il convertit une délégation ouverte en approbation d'octets spécifiques. Si l'hôte renvoie autre chose, le navigateur bloque l'exécution. Le site web peut alors mettre à jour le digest via son propre processus de déploiement après avoir examiné une nouvelle version.

La conception légitime de Polyfill.io complique ce modèle car le service générait intentionnellement des bundles différents selon les capacités du navigateur et les paramètres de requête. Un digest stable ne peut pas approuver de nombreuses séquences d'octets valides à moins que le site ne change la façon dont il consomme le service. Une équipe pourrait précalculer et approuver un ensemble limité de ressources fixes dans certaines architectures, mais attacher un hachage à un point d'accès dont le but est la sélection dynamique de réponse casserait probablement le comportement attendu ou laisserait une variation importante non liée.

La conclusion correcte n'est pas que SRI est inutile. C'est que le choix du contrôle doit correspondre au modèle de ressource. Si un site veut un épinglage d'intégrité, il peut avoir besoin d'arrêter de demander à un service distant de générer des octets arbitraires spécifiques à une requête. L'auto-hébergement d'un bundle révisé, le service de variantes versionnées fixes ou le rétrécissement des navigateurs pris en charge peuvent rendre l'approbation au niveau des octets pratique.

Content Security Policy, ou CSP, traite d'une couche différente. Une politique peut restreindre les origines autorisées à fournir des scripts et peut utiliser des nonces, des hachages ou des directives connexes pour contraindre l'exécution. Elle peut bloquer les domaines inattendus et réduire la liberté du balisage injecté de charger de nouvelles ressources. Mais sicdn.polyfill.ioest explicitement autorisé comme une origine de script de confiance, une réponse malveillante approuvée par l'origine n'est pas rendue digne de confiance par son apparition sur la liste blanche.

CSP peut toujours aider à contenir le comportement secondaire. Une politique soigneusement conçue peut restreindre les connexions, les cadres ou les navigations impliqués dans une chaîne d'attaque, et les rapports de violation peuvent ajouter des preuves de détection. L'effet exact dépend de la politique et du comportement du navigateur. La limitation centrale demeure: l'approbation de l'origine répond d'où le code peut venir, pas si l'opérateur approuvé renverra toujours un code acceptable.

La mise en miroir déplace à nouveau la frontière de confiance. Un site web ou un fournisseur d'infrastructure récupère ou maintient une copie et la sert depuis un emplacement contrôlé. Cela peut empêcher le domaine original de modifier les octets au moment de la requête. Cela crée également des obligations sur la façon dont le miroir est sourcé, révisé, mis à jour et sécurisé. La réécriture automatique vers le miroir de Cloudflare était un confinement utile, mais elle sélectionnait Cloudflare comme nouvelle autorité opérationnelle; elle n'éliminait pas le concept de confiance.

L'auto-hébergement donne au propriétaire du site web un contrôle plus direct sur la livraison. Il peut réviser une version, la déployer avec l'application et surveiller les changements via son processus de publication normal. L'auto-hébergement ne garantit pas un code sécurisé. Il réduit qui peut modifier la réponse de production et rend les octets déployés plus faciles à lier à une version.

La suppression est plus forte lorsque la fonction est inutile. Si le support actuel du navigateur ne nécessite plus un service de polyfill, le script distant le moins risqué est celui que la page ne demande pas. C'est pourquoi la révision du cycle de vie appartient aux côtés des contrôles de sécurité. Les décisions de compatibilité prises des années plus tôt ne devraient pas devenir des octrois d'autorité permanents.

Le sandboxing peut réduire une partie de l'influence tierce lorsque la fonctionnalité peut fonctionner dans un cadre contraint ou un contexte isolé. Tous les scripts ne peuvent pas y être déplacés sans modifier le produit. Un polyfill destiné à modifier l'environnement JavaScript de la page est particulièrement lié au contexte d'exécution principal, ce qui limite l'utilité de l'isolation. Cette limitation devrait influencer si la commodité vaut toujours l'autorité.

Les outils d'analyse de code aident à trouver les références connues. Les conseils spécifiques à Polyfill de CodeQL mettent l'accent sur la diligence de propriété, la révision des journaux, l'auto-hébergement et les limites des contrôles d'intégrité pour le contenu dynamique. Semgrep proposait des recherches dans les dépôts et des règles pour identifier l'utilisation de Polyfill.io après l'incident. [15][20]

Le balayage statique seul est incomplet car l'injection au moment de l'exécution peut provenir de systèmes de contenu, de gestionnaires de balises ou de fournisseurs. L'observation au moment de l'exécution seule est incomplète car des conditions rares peuvent ne pas se produire pendant l'échantillon. Une pile de contrôle mature combine le balayage des sources et des bundles, un inventaire des scripts tiers, la surveillance du DNS et de la propriété, la télémétrie côté navigateur, la révision des changements et un mécanisme de désactivation d'urgence.

La pile devrait également spécifier le comportement en cas d'échec. Si un polyfill échoue à charger, la page perd-elle une amélioration mineure, devient-elle inutilisable ou empêche-t-elle une transaction critique? Les équipes qui comprennent l'impact d'un échec peuvent supprimer ou bloquer rapidement une ressource suspecte sans improviser pendant un incident. Si la continuité dépend de la ressource, un repli local testé est plus sûr que de découvrir la dépendance lorsqu'un bureau d'enregistrement suspend le domaine.

Les contrôles ne sont donc pas un menu à partir duquel un acronyme à la mode peut être sélectionné. Ils sont une séquence de décisions: supprimer l'autorité inutile, rendre le code nécessaire fixe si possible, contraindre d'où il peut venir, observer ce qu'il fait, préserver les preuves et maintenir un chemin testé pour le désactiver ou le remplacer.

La responsabilité devrait suivre les contrôles que chaque partie détenait

L'incident impliquait un opérateur de service, des propriétaires de sites web, des fournisseurs d'infrastructure, un bureau d'enregistrement, des chercheurs en sécurité, des mainteneurs de plugins et de produits, et des fournisseurs dont le code introduisait le point d'accès. Leurs responsabilités se chevauchaient, mais elles n'étaient pas interchangeables.

L'opérateur contrôlant le service hébergé Polyfill.io détenait l'autorité la plus directe sur la réponse renvoyée par ce service. C'est différent de maintenir le code open source original. La responsabilité à cette couche concerne la garde du domaine et du chemin de déploiement, le contrôle des changements, l'intégrité de la réponse, la visibilité dans la livraison et la communication précise sur le fonctionnement. L'enregistrement disponible ne devrait pas être étiré en une conclusion sur chaque acteur individuel, relation d'entreprise ou devoir légal.

Fastly et Cloudflare détenaient des capacités d'infrastructure et de substitution. Leurs avis de février pouvaient avertir et offrir des alternatives. La position ultérieure de Cloudflare permettait la réécriture automatique et la télémétrie côté client pour le trafic couvert. Ces contrôles étaient significatifs, mais ils ne donnaient à aucun des deux fournisseurs une connaissance complète de la source, de la configuration ou de l'impact sur les visiteurs de chaque site en aval. [2][3][5]

Namecheap détenait un levier de confinement au niveau du bureau d'enregistrement. Mettre le domaine en attente interrompait la résolution ou l'utilisation du point d'accès. Cette action réduisait l'exposition immédiate tout en cassant potentiellement les sites dépendants. Le contrôle du bureau d'enregistrement pouvait arrêter un chemin; il ne pouvait pas corriger les applications ni établir la livraison historique pour chaque site web. [10]

Les chercheurs en sécurité et les répondants gouvernementaux détenaient des capacités de détection, d'analyse et d'avertissement. Sansec publiait des indicateurs et un comportement observé. Akamai et Cloudflare ajoutaient des perspectives de télémétrie. CERT-FR, Western Australia, CERT-AGID et SingCERT traduisaient l'incident en conseils aux opérateurs pour leurs publics. Ces parties pouvaient augmenter la visibilité et recommander des contrôles; elles ne pouvaient pas déployer de correctifs sur chaque site. [1][5][6][7][9][21][22]

Les mainteneurs de plugins, de bibliothèques et de fournisseurs contrôlaient le code qui pouvait introduire la dépendance de manière transitive. Leurs actions responsables incluaient l'identification des versions et conditions affectées, la suppression du point d'accès, la publication d'un correctif, la communication de la portée et la préservation de la distinction entre exposition potentielle et exploitation observée. Les enregistrements Fides et WordPress montrent pourquoi la version et les preuves d'accessibilité sont importantes. [11][12][14]

Les propriétaires de sites web contrôlaient la décision d'inclusion finale, même lorsque son exécution nécessitait qu'un fournisseur ou un mainteneur modifie le code. Ils pouvaient définir les navigateurs pris en charge, approuver les fournisseurs de scripts tiers, maintenir des inventaires, surveiller la propriété, bloquer ou réécrire les ressources, auto-héberger du code révisé, conserver des preuves de navigateur, enquêter sur les plaintes et communiquer avec les visiteurs.

Cela n'implique pas un blâme égal. Un petit opérateur de site peut avoir beaucoup moins de visibilité et d'expertise qu'une entreprise d'infrastructure mondiale. Un fournisseur peut être la seule partie capable de changer un repli groupé. Un bureau d'enregistrement peut être la seule partie capable de suspendre rapidement un domaine. La responsabilité suit le contrôle pratique et les preuves disponibles pour l'exercer, pas une supposition que chaque entité avait la même capacité.

Une carte des devoirs utiles peut être organisée autour de six questions.

Premièrement, qui pouvait prévenir l'exposition inutile? Les propriétaires de sites et de produits pouvaient revoir le support du navigateur et supprimer la dépendance. Les mainteneurs pouvaient cesser de la recommander ou de la regrouper. Les fournisseurs pouvaient offrir des chemins de migration plus sûrs.

Deuxièmement, qui pouvait détecter un changement de confiance? Les surveillants de domaine et d'infrastructure pouvaient observer les changements de propriété, de DNS et de routage. Les mainteneurs de projet pouvaient suivre le contrôle des comptes et la documentation. Les propriétaires de sites pouvaient s'abonner aux avis pertinents et réviser les dépendances à haute autorité lorsque leur opérateur changeait.

Troisièmement, qui pouvait observer une livraison nuisible? L'opérateur du service et les fournisseurs d'infrastructure pouvaient voir les réponses côté serveur. Les propriétaires de sites et les services de sécurité côté client pouvaient voir le comportement du navigateur. Les chercheurs pouvaient comparer des échantillons entre conditions. Aucune vue unique ne couvrait nécessairement toute la campagne.

Quatrièmement, qui pouvait contenir le chemin? L'opérateur pouvait arrêter la livraison, le bureau d'enregistrement pouvait suspendre le domaine, les fournisseurs d'infrastructure pouvaient réécrire ou bloquer le trafic, les mainteneurs pouvaient publier des correctifs, et les propriétaires de sites pouvaient désactiver ou supprimer les références.

Cinquièmement, qui pouvait enquêter sur l'impact? Chaque propriétaire de site détenait sa propre architecture de page, ses enregistrements de visiteurs, ses plaintes et son historique de déploiement. Les fournisseurs détenaient des informations sur les conditions transitives. Les fournisseurs d'infrastructure détenaient une télémétrie sélectionnée du trafic et des réponses. L'enquête nécessitait une coopération sans prétendre que l'ensemble de données d'une partie représentait tous les visiteurs.

Sixièmement, qui pouvait vérifier la réparation et la communiquer? Les mainteneurs pouvaient lier les correctifs aux versions. Les fournisseurs pouvaient montrer la suppression. Les propriétaires de sites pouvaient tester le chemin public et déclarer ce que leurs preuves couvraient. Les organismes gouvernementaux et de sécurité pouvaient mettre à jour les conseils. La vérification devait rester limitée à la visibilité de la partie.

Cette carte rend la responsabilité testable. Au lieu de demander seulement qui a causé l'incident, elle demande quelle partie pouvait répondre à chaque question de prévention, détection, confinement, enquête et réparation. Elle expose également les lacunes de contrôle. Si personne ne surveillait la propriété du domaine pour un script avec une autorité au niveau de la page, la lacune existait avant l'apparition de la branche malveillante.

Ce qu'un site web en aval devrait être capable de prouver

Une réponse en aval crédible peut être exprimée comme une chaîne de preuves plutôt qu'une assurance générique.

La chaîne commence par l'inventaire. L'organisation devrait identifier chaque référence directe et transitive à Polyfill.io, le composant ou fournisseur qui l'a introduite, les pages qui la rendaient et les conditions de navigateur qui la rendaient accessible. Les résultats de recherche devraient être connectés au comportement déployé, pas laissés comme une liste de fichiers correspondants.

Ensuite vient la nécessité. Le propriétaire devrait documenter si la fonction de compatibilité reste requise pour les navigateurs qu'il supporte intentionnellement. Si non, la suppression devrait être préférée. Si elle est requise, l'organisation devrait expliquer pourquoi le remplacement choisi ou la version auto-hébergée est proportionné au besoin.

La troisième étape est la réévaluation de la confiance. L'enregistrement devrait montrer quand l'organisation a appris la transition de propriété ou l'incident de juin, qui a pris la décision de continuer, bloquer, remplacer ou supprimer le service, et quelles preuves soutenaient cette décision. Une révision de février et une réponse d'urgence de juin sont des événements différents et ne devraient pas être confondus.

La quatrième étape est la portée historique. L'organisation devrait déclarer quelles dates, populations de visiteurs et sources de télémétrie elle a examinées. Elle devrait séparer les références de point d'accès, les requêtes, les correspondances d'indicateurs connus, les redirections et les préjudices signalés. Si des journaux manquent, l'écart devrait rester explicite.

La cinquième étape est la réparation. Le propriétaire devrait lier le changement à une version, une configuration ou une confirmation de fournisseur. Il devrait tenir compte des actifs générés, des caches, des plugins, des gestionnaires de balises et des branches conditionnelles. Observer simplement que le domaine suspendu ne répond plus n'est pas une preuve de suppression.

La sixième étape est la vérification. Les tests devraient couvrir les conditions de navigateur pertinentes et confirmer que la page publique ne fait aucune requête à l'ancien point d'accès. La surveillance devrait rechercher une réintroduction, des origines de script inattendues et un comportement de redirection. Là où un fournisseur a fourni le correctif, le client devrait vérifier le résultat externe.

La septième étape est la communication. Un avis devrait utiliser des définitions stables et éviter de convertir l'utilisation en victimisation. Il devrait expliquer quelle dépendance existait, si elle était accessible, quelles preuves de livraison malveillante ont été ou non trouvées, ce qui a changé et quelles incertitudes subsistent. Les utilisateurs ont besoin de faits pratiques, pas d'une déclaration large que le problème a été "résolu."

Enfin, le propriétaire devrait mettre à jour ses contrôles de cycle de vie. Les scripts distants à haute autorité ont besoin de propriétaires nommés, de dates de révision, d'enregistrements de base de confiance, de surveillance du domaine et de l'opérateur, de chemins de désactivation d'urgence et de conservation de preuves de navigateur utiles. Sinon, le même échec de gouvernance peut se reproduire sous un nom d'hôte différent.

Ces preuves ne nécessitent pas la divulgation de détails défensifs sensibles. Elles nécessitent suffisamment de spécificité pour rendre la réponse falsifiable. Un visiteur, client ou réviseur devrait pouvoir distinguer "nous avons supprimé la chaîne" de "nous avons trouvé chaque chemin actif," et "nous n'avons vu aucune exploitation" de "nos preuves l'excluent pour la population couverte."

Un transfert de domaine peut être un changement logiciel

Polyfill.io a rendu difficile à ignorer un principe simple: lorsqu'un domaine renvoie du code exécutable, la propriété du domaine fait partie de l'état de sécurité du logiciel. L'URL peut rester stable tandis que le fournisseur effectif change. Un dépôt peut rester public tandis que la réponse hébergée passe sous un contrôle différent. HTTPS peut rester valide tandis que la base de confiance qui justifiait l'inclusion n'existe plus.

Les avis de février ont montré que ce changement était visible et actionnable. Les rapports de juin ont montré pourquoi il comptait. La livraison sélective de redirection exploitait un modèle dans lequel différents visiteurs pouvaient légitimement recevoir un code différent, rendant l'inspection occasionnelle une assurance faible. Plus tard, la réécriture et la suspension du domaine ont contraint le chemin, mais seul l'inventaire en aval, la suppression, l'enquête et la vérification pouvaient fermer la part de chaque site dans le problème.

L'incident ne justifie pas d'appeler plus de 100 000 sites des victimes confirmées. Il ne prouve pas que chaque référence a servi du contenu malveillant, que chaque visiteur a été exposé ou que chaque produit en aval a été exploité. Il ne justifie pas non plus de décrire le code open source original comme universellement malveillant ou de traiter une copie auto-hébergée comme identique à la relation hébergée compromise.

L'incident ne soutient pas non plus un verdict juridique ou une histoire d'attribution complète à partir de l'enregistrement disponible. La responsabilité ici est plus étroite et plus opérationnelle. C'est l'obligation d'expliquer pourquoi une autorité exécutable a été déléguée, comment un changement de contrôle a été détecté, quelles preuves ont établi la portée, quelle action a réduit l'exposition et comment la réparation a été vérifiée.

L'opérateur de service, les entreprises d'infrastructure, le bureau d'enregistrement, les mainteneurs, les fournisseurs et les propriétaires de sites web détenaient chacun différentes pièces de cette réponse. La responsabilité était partagée parce que le système était partagé, mais elle n'était pas fongible. Un bureau d'enregistrement pouvait suspendre un domaine et laisser encore du code obsolète derrière lui. Un fournisseur pouvait supprimer une référence et manquer encore de la télémétrie des visiteurs du client. Un site web pouvait enquêter sur ses utilisateurs et dépendre encore d'une partie en amont pour modifier un composant groupé.

Pour les propriétaires en aval, la norme durable est directe: connaître chaque partie externe qui peut choisir du code pour vos visiteurs; surveiller les faits qui rendaient cette partie digne de confiance; supprimer l'autorité qui ne sert plus une fonction nécessaire; et conserver suffisamment de preuves pour distinguer l'exposition, la livraison et le préjudice.

Une balise script peut être une ligne de HTML, mais elle crée une relation opérationnelle. Lorsque le propriétaire derrière cette ligne change, la relation logicielle change aussi. La responsabilité du site web commence par reconnaître ce changement avant qu'un visiteur ait à le révéler.

Sources

  1. https://sansec.io/research/polyfill-supply-chain-attack
  2. https://blog.cloudflare.com/polyfill-io-now-available-on-cdnjs-reduce-your-supply-chain-risk/
  3. https://community.fastly.com/t/new-options-for-polyfill-io-users/2540
  4. https://github.com/formatjs/formatjs/issues/4363
  5. https://blog.cloudflare.com/automatically-replacing-polyfill-io-links-with-cloudflares-mirror-for-a-safer-internet/
  6. https://cert.ssi.gouv.fr/actualite/CERTFR-2024-ACT-030/
  7. https://soc.cyber.wa.gov.au/advisories/20240626004-JavaScript-Polyfill-Supply-Chain-Attack/
  8. https://tag-security.cncf.io/community/catalog/compromises/2024/polyfill/
  9. https://www.akamai.com/blog/security/polyfill-supply-chain-attack-what-to-know
  10. https://socket.dev/blog/namecheap-takes-down-polyfill-io-service-following-supply-chain-attack
  11. https://www.cve.org/CVERecord?id=CVE-2024-38537
  12. https://nvd.nist.gov/vuln/detail/cve-2024-38537
  13. https://jellyfish.co/library/jellyfish-security-advisory-june-27-2024/
  14. https://www.wordfence.com/threat-intel/vulnerabilities/detail/various-plugins-various-version-use-of-polyfillio
  15. https://codeql.github.com/codeql-query-help/javascript/js-functionality-from-untrusted-domain/
  16. https://cwe.mitre.org/data/definitions/830.html
  17. https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html
  18. https://www.w3.org/TR/SRI/
  19. https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/SRI
  20. https://semgrep.dev/blog/2024/protect-your-code-from-the-polyfill-supply-chain-attack/
  21. https://cert-agid.gov.it/news/scoperto-un-grave-attacco-alla-supply-chain-del-servizio-polyfill-io-piu-di-100-000-i-siti-coinvolti/
  22. https://isomer-user-content.by.gov.sg/36/8bee5efc-3166-44a1-89ae-0f0b095ecb17/03-July-2024.pdf