Prévenir les attaques de la chaîne d'approvisionnement contre l'écosystème JavaScript

Les attaques contre la chaîne d'approvisionnement constituent un gros problème pour l'écosystème JavaScript. Dans ce court article, je présenterai une mesure de sécurité simple qui peut être implémentée par tous les environnements d'exécution JavaScript, à la fois dans le navigateur et hors navigateur. Cela empêchera la plupart des attaques de la chaîne d’approvisionnement qui ravagent aujourd’hui l’écosystème JavaScript.

Problème : héritage des autorisations

Voici un incident récent au cours duquel des sites Web ont été piratés :

• Les chercheurs associent l'attaque de la chaîne d'approvisionnement Polyfill à un vaste réseau de sites de jeux de hasard

Le cœur du problème est que les modules JavaScript héritent des autorisations de l'application ou du module qui les a appelés. Il s'agit d'un problème à la fois pour les exécutions dans le navigateur et hors navigateur.

Ce problème est encore compliqué par le fait que la version du module dont dépend une application peut changer à l'insu de l'auteur de l'application. Ainsi, même si les codes de toutes les dépendances ont été minutieusement révisés (ce qui représente un énorme effort en soi), cet effort sera vain si les versions des dépendances n'ont pas été verrouillées.

Pourquoi ne pas verrouiller les versions et utiliser des dépendances basées sur Semver ? Eh bien, c'est principalement parce que si un éditeur de module publie des corrections de bugs, il est préférable d'utiliser le code corrigé. Et c'est l'une des principales raisons pour lesquelles les CDN JavaScript tels que esm.sh prennent en charge les semvers.

? Comment les sites Web sont impactés

Les navigateurs Web sont des environnements d'exécution en bac à sable, donc un module JavaScript tiers (3JM) importé par un site Web ne peut causer aucun dommage à l'appareil de l'utilisateur final.

Néanmoins, un 3JM peut utiliser les ressources de calcul de l'appareil et émettre des requêtes réseau pour le minage de Bitcoin, etc., sans le consentement du site Web.

? Comment les applications JavaScript hors navigateur sont affectées

Certains environnements d'exécution hors navigateur tels que Deno implémentent des mesures pour restreindre les autorisations accordées à une application JavaScript/TypeScript. Mais ces mesures échouent pour les raisons suivantes :

• Même si un système d'autorisation tel que celui de Deno est appliqué, il permet néanmoins aux modules JS d'hériter des autorisations de l'appelant sans restrictions. Cela signifie que si une application dispose d'autorisations d'écriture complètes, un validateur d'adresse e-mail qui ne devrait avoir accès à aucune ressource, à l'exception des ressources de calcul, peut supprimer les fichiers utilisateur à l'insu de l'utilisateur du système d'exploitation.
• Les applications s'exécutent souvent avec tous les privilèges de l'utilisateur du système d'exploitation. Par exemple, pour le code exécuté sous un outil tel que MDRB, il n'est actuellement pas possible de restreindre les autorisations sur le code en cours d'exécution.

La solution actuelle

Actuellement, les équipes de sécurité ont mis en place des processus automatisés pour rechercher des vulnérabilités dans les modules publiés sur des registres bien connus tels que NPM. Cette mesure de sécurité présente plusieurs défauts :

• L'analyse de toutes les versions de tous les modules connus qui ont été publiés demande incroyablement beaucoup de ressources.
• Il n'y a aucune garantie que tous les modules disponibles dans la nature ont été analysés.

? Solution : autorisations par module

Pour résoudre ces problèmes, je propose un nouveau système d'autorisations par module qui est rétrocompatible avec le fonctionnement actuel des applications JS/TS.

Cela implique une nouvelle configuration d'autorisations facultatives que chaque application et module peut déclarer dans leurs fichiers deno.json / deno.jsonc / package.json. les autorisations comportent 2 parties :

• permissions.self — C'est ici que l'application ou le module déclare les autorisations dont lui et ses dépendances ont besoin.
• permissions.imports — C'est ici que l'application ou le module déclare les autorisations qu'il accepte d'attribuer à ses dépendances. Il s'agit d'un surensemble des autorisations que chaque dépendance est autorisée à exiger.

Voici comment les autorisations seraient utilisées par le runtime JS/TS :

• Lorsqu'une application ou un module importe un module M, le runtime vérifie si les permissions.self de M sont dans les limites que l'importateur impose à M. L'importation renvoie une erreur (par exemple PermissionError) si ce n'est pas le cas.
• Une erreur d'exécution est également générée (par exemple PermissionError) lorsqu'un module ou une application tente de faire quelque chose qu'il n'est pas autorisé à faire. Cette erreur d'exécution peut être détectée et gérée sans abandonner l'application.

La valeur des autorisations ressemblerait à ceci :

{
  "self": {
    "read":  {"allow": [], "deny": []},
    "write": {"allow": [], "deny": []},
    "net":   {"allow": [], "deny": []},
    "env":   {"allow": [], "deny": []},
    "run":   {"allow": [], "deny": []}
  },

  "imports": {
    "jsr:@org/module@1.0.0": {
      "read":  {"allow": [], "deny": []},
      "write": {"allow": [], "deny": []},
      "net":   {"allow": [], "deny": []},
      "env":   {"allow": [], "deny": []},
      "run":   {"allow": [], "deny": []}
    },
    "https://cdn.example/org/module@1.0.0": {
      "read":  {"allow": [], "deny": []},
      "write": {"allow": [], "deny": []},
      "net":   {"allow": [], "deny": []},
      "env":   {"allow": [], "deny": []},
      "run":   {"allow": [], "deny": []}
    },
    "[default]": {
      "read":  {"allow": [], "deny": []},
      "write": {"allow": [], "deny": []},
      "net":   {"allow": [], "deny": []},
      "env":   {"allow": [], "deny": []},
      "run":   {"allow": [], "deny": []}
    }
  }
}

Par rapport à la solution actuelle, la solution que je propose présente plusieurs avantages :

• Léger — Les modules publiés n'ont pas besoin d'être analysés.
• Complète — Les autorisations sont appliquées au moment de l'exécution, donc si le bon moteur JS/TS est utilisé, même les modules inconnus ne peuvent pas passer entre les mailles du filet.

Cela semble très simple. Aucune modification n'est requise dans les langages JS/TS. Et si la configuration des autorisations est absente, alors nous revenons à la situation actuelle où l'application et son graphe de dépendances ont tous les autorisations qui ont été fournies par les arguments de ligne de commande ∎

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!