Polyfill.io: propriété de domaine et responsabilité des sites web

Résumé

Un site qui chargeaitcdn.polyfill.ione se contentait pas de citer un projet open-source. Il permettait à un service distant en direct de sélectionner du JavaScript et de le retourner 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, et non 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 à l'époque, 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 signalé le 25 juin que le service retournait sélectivement du JavaScript modifié qui redirigeait les visiteurs éligibles. Cloudflare a déclaré que les indicateurs de Page Shield incluaient des correspondances dès le 8 juin, tandis qu'Akamai a décrit un échantillonnage côté serveur suivi de vérifications côté client. Ces observations établissent une campagne de redirection, pas chaque action que la fourniture de JavaScript à distance pourrait théoriquement effectuer. [1][5][9]
L'estimation de Sansec de plus de 100 000 sites faisait référence aux sites intégrant ou utilisant le service. Cloudflare a cité une estimation d'utilisation approchant quatre pour cent des sites Web. Aucun chiffre n'est un nombre vérifié de sites ayant servi la branche malveillante, redirigé des visiteurs ou subi une perte. [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'investigation 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 atteignable, tracer un fournisseur transitif, vérifier la suppression et éviter de traiter une référence au point de terminaison 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 local, la surveillance de la propriété, l'observation côté navigateur, l'investigation, la réparation et la communication.

Une balise script a délégué l'autorité, pas seulement la commodité

La décision technique centrale semblait ordinaire. Un site 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 demande 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 retourner 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 fait que la réponse restait dynamique. Le site ne se contentait pas de télécharger un package fixe pendant le développement et de déployer des octets examinés à partir de 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, DNS, routage, hébergement, certificats, accès au déploiement et des personnes ou organisations capables de modifier la réponse. Un site peut faire confiance au code public tout en ne parvenant pas à examiner si le point de terminaison servant ses visiteurs reste sous le même contrôle, suit le même processus ou retourne 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 d'une 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 retourné 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 incluse. 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. CWE-830 du MITRE décrit ce type d'inclusion comme un transfert de confiance vers du code provenant d'un autre domaine, et OWASP considère 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 CodeQL de GitHub appliquent la même logique aux fonctionnalités chargées depuis un domaine non fiable. [15][16][17]

C'est pourquoi l'incident ne doit pas être réduit à « l'open-source est devenu dangereux ». Le code open-source original, une copie auto-hébergée examinée et un service en direct contrôlé par un domaine étaient des objets de confiance distincts. Un site utilisant une copie locale fixe ne faisait pas la même délégation d'exécution qu'un site 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 chaque bibliothèque externe. C'est de savoir si le site 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 l'atteindre, quelle fonction commerciale le nécessitait et qui contrôlait actuellement le point de terminaison.

Ces questions appartiennent au propriétaire du site parce que le site a rendu l'inclusion effective. Un visiteur n'a pas négocié avec Polyfill.io ni choisi son opérateur. Le visiteur a demandé une page au site et a raisonnablement vécu les scripts retournés comme faisant partie de cette page. Même lorsqu'un thème, un plugin, un gestionnaire de balises ou un fournisseur a inséré 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 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 la première partie. L'opérateur du service pouvait choisir la réponse. Le propriétaire du site 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 a été un événement de gouvernance logicielle

La chronologie publique fournit un intervalle d'avertissement exceptionnellement 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 d'information conventionnel, un transfert de domaine peut principalement changer l'autorité de publication. Pour un domaine qui retourne du JavaScript exécutable à d'autres sites web, le transfert change qui peut influencer le logiciel s'exécutant sur ces pages en aval. Cela fait de l'information de propriété une partie de l'état de dépendance. Un nouveau propriétaire du point de terminaison 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 a annoncé des domaines de remplacement et a donné 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. 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 une raison 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 de terminaison. Cet enregistrement est important car il montre un mainteneur agissant sur une dépendance de documentation avant une campagne malveillante signalée publiquement. Retirer une recommandation ne répare pas chaque site web qui l'a précédemment suivie, 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 sites 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. Elles établissent que le changement de propriété était observable, que des alternatives étaient disponibles et que certaines parties responsables ont réévalué le point de terminaison des mois avant le rapport d'incident.

Cette distinction est essentielle à la responsabilité. Un devoir de surveillance ne signifie pas 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 propriété de domaine, DNS ou d'hébergement. Pour un paquet versionné, les flux de versions et de vulnérabilités peuvent être les signaux importants. Pour un point de terminaison 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 ponctuelle du 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 du 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 attendues de la réponse, 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 alors ou au 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 dû également ê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é 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 n'est propriétaire 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 de terminaison et si un bundle local plus petit pouvait répondre au besoin restant.

Rien de tout cela ne prouve que chaque site conservant la référence ait agi par négligence, et cela ne transforme pas le transfert de domaine lui-même en 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 a rendu l'inspection occasionnelle peu fiable

Le 25 juin, Sansec a signalé quecdn.polyfill.iolivrait du JavaScript modifié via des sites web qui l'avaient intégré. Le comportement observé redirigeait certains visiteurs vers des domaines conçus pour ressembler à Google Analytics vers des destinations d'escroquerie ou de paris. Sansec a décrit des conditions incluant le ciblage mobile, des vérifications côté serveur et côté client, un comportement basé sur le temps et l'évitement de certains contextes d'administrateur ou d'analytique. [1]

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

La capacité n'est pas la 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 la preuve que toute l'activité malveillante a commencé à cette date, que la même branche a atteint chaque site en continu à partir de là 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 à partir d'un navigateur à un moment donné peut montrer seulement la réponse sélectionnée pour cette requête. Un robot 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 tout en étant 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, les appareils, les emplacements et les conditions de requête; conserverait les corps de réponse et les hachages au fil du temps; détecterait les nouveaux domaines et les chaînes de redirection; et comparerait le comportement vu par les clients réels 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 pour se cacher dans un modèle opérationnel 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 retourné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'investigation 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 CDN, les réponses sauvegardées, les rapports de sécurité du contenu et les enregistrements de points de terminaison 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 doit pas être cachée avec une affirmation large que tout le monde était en sécurité ou que tout le monde était compromis. Une déclaration d'incident responsable peut plutôt définir ce qui a été trouvé: le point de terminaison était référencé; un chemin conditionnel particulier était atteignable 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 points de terminaison ne sont pas des décomptes de victimes et pourquoi une correction vérifiée nécessite plus que de charger la page une fois après la suspension du domaine.

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

Sansec a décrit plus de 100 000 sites comme intégrant ou utilisant le service. Cloudflare a cité 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 de terminaison Polyfill.io. Une autre est l'ensemble pour lequel le chemin d'inclusion pertinent était atteignable 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 aux 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 tout aussi 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'atteignabilité, 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 contre l'hypothèse que chaque instance de plugin livrait du contenu malveillant. Les plugins pouvaient introduire le point de terminaison dans de nombreux sites, rendant le travail d'inventaire urgent, tandis que la présence du code ne prouvait pas encore l'exécution malveillante dans chaque installation. [14]

Les rapports gouvernementaux ont répété la préoccupation sérieuse d'échelle tout en concentrant les opérateurs sur la suppression et l'investigation. CERT-AGID a décrit l'acquisition et la livraison dépendante des en-têtes et a fait référence au chiffre de plus de 100 000. Cet avertissement indépendant soutient une large attention défensive, 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 de terminaison avait une grande empreinte en aval, et la campagne sélective observée a créé un risque sur 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 terminé la correction

La réponse a impliqué des parties avec différents types de contrôle. Cloudflare a automatiquement réécrit les références Polyfill.io sur les pages clients proxysées vers un miroir hébergé par Cloudflare. L'entreprise a expliqué que simplement bloquer le domaine original pouvait casser des 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 de terminaison 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 qu'éliminer 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 a changé l'opérateur de confiance et le chemin de réponse pour le trafic couvert par le mécanisme. Elle n'a pas établi 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 n'a pas non plus répondu 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 ont décrit le point de terminaison comme suspendu à partir du 27 juin. L'action au niveau du domaine a supprimé le chemin de service immédiat mais pouvait également 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 mises en cache, les configurations de gestionnaires 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é car 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 de terminaison définitivement mort peut imposer des coûts de performance, de gestion d'erreurs et de compatibilité.

CERT-FR et l'unité de cybersécurité d'Australie-Occidentale ont conseillé 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 des contrôles de navigateur tels que l'intégrité des sous-ressources (SRI) et la politique de sécurité du contenu (CSP). Semgrep s'est également concentré 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 affirmations de clôture distinctes. « Contenu » 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. « Investigé » 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 pouvait compter sur un fournisseur d'infrastructure pour la première affirmation 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 devait investiguer.

Cette séparation protège également contre la surestimation de l'intervention tierce. Une mise en attente par le 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 forensique 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 correction 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 de fournisseurs. Les outils de recherche peuvent trouver des chaînes connues, mais un inventaire de 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 propre. Si le support des navigateurs legacy reste requis, un bundle local examiné 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 proportionnées 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 les indicateurs de redirection connus sont apparus. L'absence de preuves 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 les enregistrements manquants en preuve qu'aucun visiteur n'a reçu la branche.

Fides a montré pourquoi une branche conditionnelle importe encore

CVE-2024-38537 enregistre un problème en aval dans Fides. Le cheminfides.jspertinent pouvait charger Polyfill.io pour les navigateurs legacy. L'enregistrement identifie les versions affectées et indique 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 consisterait à rejeter le problème parce que seul un chemin de navigateur plus ancien chargeait le point de terminaison. L'atteignabilité conditionnelle reste une atteignabilité. 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 consisterait à 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 correction 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, scanner les références restantes et tester le chemin legacy. Un avertissement général de « faire attention avec Polyfill.io » ne fournirait pas la même preuve de clôture.

La condition legacy devrait façonner la vérification. Tester seulement un navigateur de bureau moderne pourrait n'exécuter jamais la branche affectée. La vérification devrait reproduire ou inspecter la condition qui la sélectionnait à l'origine. Cela peut nécessiter de revoir 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 ou ne demande plus le point de terminaison.

Le bulletin de SingCERT discutait également du cas Fides en aval et conservait la frontière aucune-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 requête tierce conditionnelle mérite la même sévérité. C'est qu'un mainteneur devrait connaître la condition, les versions affectées, la population atteignable, la version de correction 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, a contacté le fournisseur, a vérifié la suppression et a 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é la balise script directement dans son propre dépôt. La référence peut provenir d'un composant analytique, 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 chose 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 de ce 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 requête à 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 disponibles de navigateur et de produit.

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 mis en cache la contient encore. Le client devrait tester de l'extérieur aussi bien qu'accepter la confirmation interne. La capture réseau à travers 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 seules certaines versions de navigateur ou flux de page pouvaient déclencher le chemin du fournisseur, l'investigation peut réduire la portée potentielle. Elle ne devrait pas impliquer que chaque membre de ce groupe de navigateurs a reçu un 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 avec le fournisseur, l'investigation 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 à travers divers modèles de plugins WordPress. Ce type d'inventaire est précieux car les plugins peuvent distribuer une dépendance externe unique sur de nombreux sites web exploités indépendamment. Une petite décision d'un mainteneur peut devenir une large relation de confiance en aval sans que chaque propriétaire de site ajoute consciemment le point de terminaison. [14]

Le catalogue portait également un avertissement crucial: l'utilisation du point de terminaison 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 à ce moment.

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 réellement 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 de tâches différent. 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 plugins 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 n'altère 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 compromises. 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 mise 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 large liste d'exposition pour accélérer l'action. Les mainteneurs peuvent déclarer les versions affectées. Les propriétaires de sites peuvent signaler l'atteignabilité déployée. Les investigateurs d'incidents peuvent signaler les indicateurs observés. Aucun ne devrait emprunter la certitude des autres.

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

L'intégrité des sous-ressources, ou SRI, permet à un auteur de page de fournir un condensat cryptographique pour une ressource externe. Un navigateur compatible peut récupérer la ressource et refuser de l'exécuter si les octets retournés ne correspondent pas au condensat attendu. La spécification du W3C et les conseils d'implémentation de MDN présentent le SRI comme un moyen d'empêcher un hôte tiers compromis de modifier silencieusement une ressource que le site incluant s'attend à voir rester fixe. [18][19]

C'est un contrôle fort pour un script stable. Il convertit une délégation ouverte en une approbation d'octets spécifiques. Si l'hôte retourne autre chose, le navigateur bloque l'exécution. Le site peut ensuite mettre à jour le condensat par 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 différents bundles en fonction des capacités du navigateur et des paramètres de requête. Un seul condensat stable ne peut pas approuver de nombreuses séquences d'octets valides à moins que le site ne change sa façon de consommer le service.

Une équipe pourrait précalculer et approuver un ensemble borné de ressources fixes dans certaines architectures, mais attacher un hachage à un point de terminaison dont le but est la sélection dynamique de réponse briserait probablement le comportement attendu ou laisserait une variation importante non liée.

La conclusion correcte n'est pas que le SRI est inutile. C'est que le choix de contrôle doit correspondre au modèle de ressource. Si un site souhaite 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 à la requête. L'auto-hébergement d'un bundle examiné, 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.

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

Le CSP peut encore 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é retournera 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 changer les octets au moment de la requête. Cela crée également des obligations quant à la manière dont le miroir est sourcé, examiné, mis à jour et sécurisé. La réécriture automatique vers le miroir de Cloudflare était un confinement utile, mais elle a sélectionné Cloudflare comme nouvelle autorité opérationnelle; elle n'a pas éliminé le concept de confiance.

L'auto-hébergement donne au propriétaire du site un contrôle plus direct sur la livraison. Il peut examiner une version, la déployer avec l'application et surveiller les changements par 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 n'est pas nécessaire. Si le support actuel du navigateur ne nécessite plus un service de polyfill, le script distant le plus sûr est celui que la page ne demande pas. C'est pourquoi la revue de 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 délégations d'autorité permanentes.

Le sandboxing peut réduire certaines influences tierces lorsque la fonctionnalité peut s'exécuter dans un cadre contraint ou un contexte isolé. Tous les scripts ne peuvent pas y être déplacés sans changer 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 de scan de code aident à trouver des références connues. Les conseils spécifiques à Polyfill de CodeQL mettent l'accent sur la diligence de propriété, la revue de logs, l'auto-hébergement et les limites des contrôles d'intégrité pour le contenu dynamique. Semgrep a proposé des recherches de dépôt et des règles pour identifier l'utilisation de Polyfill.io après l'incident. [15][20]

Le scan 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 scan de code source et de bundle, un inventaire de scripts tiers, la surveillance DNS et de propriété, la télémétrie côté navigateur, la revue des changements et un mécanisme d'arrêt d'urgence.

La pile devrait également spécifier le comportement en cas d'échec. Si un polyfill ne se charge pas, 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 des défaillances peuvent supprimer ou bloquer une ressource suspecte rapidement 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 parmi lequel 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 dans la mesure du possible, contraindre d'où il peut venir, observer ce qu'il fait, conserver 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 de terminaison. 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 retournée par ce service. Cela est différent de la maintenance du 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é sur la livraison et la communication précise sur le fonctionnement. L'enregistrement disponible ne doit 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 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 de terminaison. 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 patcher les applications ou é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 a publié des indicateurs et un comportement observé. Akamai et Cloudflare ont ajouté des perspectives de télémétrie. CERT-FR, l'Australie-Occidentale, CERT-AGID et SingCERT ont traduit l'incident en conseils opérationnels 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 des conditions affectées, la suppression du point de terminaison, 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. Fides et les enregistrements de plugins WordPress montrent pourquoi les preuves de version et d'atteignabilité 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 le code examiné, conserver les preuves du navigateur, investiguer 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 mondiale d'infrastructure. Un fournisseur peut être la seule partie capable de modifier 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 hypothèse que chaque entité avait la même capacité.

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

Premièrement, qui pouvait prévenir une 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 moniteurs 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 du compte et la documentation. Les propriétaires de sites pouvaient s'abonner aux avis pertinents et revoir 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 dans différentes 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 investiguer 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'investigation 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 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, investigation et réparation. Elle expose également les lacunes de contrôle. Si personne ne surveillait la propriété du domaine pour un script avec 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 atteignable. Les résultats de recherche devraient être connectés au comportement déployé, pas laissés comme une liste de fichiers correspondants.

Vient ensuite 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 le transfert 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 revue de février et une réponse d'urgence en 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 indiquer 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 points de terminaison, les requêtes, les correspondances d'indicateurs connus, les redirections et les préjudices signalés. Si des journaux manquent, la lacune 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. Simplement observer 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 de terminaison. La surveillance devrait rechercher une réintroduction, des origines de script inattendues et un comportement de redirection. Lorsqu'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 atteignable, quelles preuves de livraison malveillante ont été trouvées ou non, ce qui a changé et quelles incertitudes subsistent. Les utilisateurs ont besoin de faits pratiques, pas d'une déclaration large selon laquelle 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 d'arrêt d'urgence et de conservation de preuves utiles du navigateur. Sinon, le même échec de gouvernance peut se reproduire sous un nom d'hôte différent.

Ces preuves n'exigent pas la divulgation de détails défensifs sensibles. Elles exigent 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é tous les chemins actifs », 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 retourne 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 importait. La livraison de redirection sélective exploitait un modèle dans lequel différents visiteurs pouvaient légitimement recevoir un code différent, rendant l'inspection occasionnelle une faible assurance. La réécriture ultérieure et la suspension du domaine ont contraint le chemin, mais seulement l'inventaire en aval, la suppression, l'investigation et la vérification pouvaient fermer la part de chaque site web 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 un 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'événement 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 l'autorité exécutable a été déléguée, comment le 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 du 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 investiguer ses utilisateurs et dépendre encore d'une partie 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 de fonction nécessaire; et conserver suffisamment de preuves pour distinguer exposition, livraison et préjudice.

Une balise script peut être une seule 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 n'ait à le révéler.

Polyfill.io a fait de la propriété de domaine un test de responsabilité pour les sites web en aval