Seal Security — Exemple JavaScript (npm)

Une application Node.js/Express minimale, intentionnellement vulnérable, utilisée pour démontrer, de bout en bout, comment Seal Security corrige un CVE connu en remplaçant une dépendance vulnérable par une version scellée (rétroportée, plug-and-play) — sans aucune modification de vos plages de versions déclarées ni de votre code.

Elle est conçue comme un test de fumée global pour le CLI Seal en CI/CD : exécutez l'application, déclenchez une véritable exploitation, exécutez Seal, et voyez la même exploitation être bloquée.

Ce que cet exemple démontre

L'application inclut également d'autres dépendances vulnérables bien connues (lodash 4.17.5, json5 0.5.1, got 6.7.1), chacune étant également corrigée par Seal vers une version scellée.

Comment fonctionne l'exploitation

L'application insère l'intégralité de la chaîne de requête URL directement dans l'appel de rendu EJS :

const data = { name: 'World', ...req.query };
res.render('page', data, ...)

EJS accepte un objet settings['view options'] dont la valeur outputFunctionName est écrite — non assainie — dans le corps de la fonction de modèle compilée. Un attaquant peut donc injecter du JavaScript arbitraire qui s'exécute sur le serveur avec les privilèges du processus Node.js.

Requête normale

/?name=alice

affiche Hello alice!.

Requête d'exploitation

/?name=Hacker&settings[view%20options][outputFunctionName]=x;setTimeout(function()%7Bprocess.exit(1)%7D,3000);s

Le serveur exécute setTimeout(function(){ process.exit(1) }, 3000). La page se charge d'abord et indique clairement que l'RCE a réussi ; rechargez quelques secondes plus tard et vous obtiendrez ERR_CONNECTION_REFUSED — le code injecté a tué le serveur, prouvant que du code arbitraire a été exécuté.

Le délai de 3 secondes est intentionnel : il permet à la réponse d'atteindre le navigateur avant que le processus ne se termine, afin que vous voyiez la page "exploitation réussie" puis un plantage propre plutôt qu'un onglet gelé.

Structure du dépôt

.
├── index.js                       # l'application Express vulnérable
├── views/                         # templates EJS
├── package.json / package-lock.json
├── Jenkinsfile                    # exemple de pipeline Jenkins (Groovy) avec l'étape Seal
└── .github/workflows/
    ├── build-and-run.yml          # build + exposition de l'application pour les tests navigateur
    └── seal-security.yml          # exécuter la correction Seal, puis démarrer l'application

Prérequis

Seal est SaaS, hébergé par Seal — rien n'est installé dans votre environnement, et tout le trafic est HTTPS sortant sur TCP 443 uniquement. Pour exécuter la correction, vous avez besoin de :

Configurez-les dans Settings → Secrets and variables → Actions (GitHub) ou Manage Jenkins → Credentials (Jenkins). Ne commettez jamais les jetons dans le dépôt.

Liste blanche de ces hôtes Seal pour le trafic sortant 443 : app.sealsecurity.io, authorization.sealsecurity.io, cli.sealsecurity.io, et — pour les paquets npm scellés — npm.sealsecurity.io. Le binaire CLI est téléchargé depuis github.com / objects.githubusercontent.com.

Exécution locale

npm install
npm start           # → http://localhost:3001

Ouvrez http://localhost:3001/?name=alice (fonctionne), puis l'URL d'exploitation ci-dessus (plante le serveur).

Corriger avec Seal

Le CLI Seal s'exécute comme une étape supplémentaire, après npm install et avant l'empaquetage. Il analyse les dépendances résolues et réécrit les dépendances vulnérables vers leurs versions scellées, en utilisant le mode de correction à distance (la politique est gérée centralement dans l'interface Seal).

Option A — GitHub Actions

Utilise seal-community/cli-action :

- uses: seal-community/cli-action@latest
  with:
    mode: fix
    fix_mode: remote
    token: ${{ secrets.SEAL_TOKEN }}
    target: package-lock.json     # le fichier lock pour cet écosystème

Exécutez-le via Actions → “Seal Security Remediation” → Run workflow. Voir .github/workflows/seal-security.yml.

Option B — Jenkins (Groovy pipeline)

Une seule étape ajoutée, après l'installation et avant l'empaquetage. Voir Jenkinsfile :

stage('Seal') {
  steps {
    sh '''
      curl -fsSL https://github.com/seal-community/cli/releases/download/latest/seal-linux-amd64-latest -o seal
      chmod +x seal
      ./seal fix --mode remote "$SEAL_MANIFEST"   # SEAL_MANIFEST=package-lock.json
    '''
  }
}

SEAL_TOKEN provient du credential Jenkins seal-token ; définissez SEAL_PROJECT sur votre ID de projet Seal.

Ce que Seal modifie

Après seal fix, les dépendances vulnérables résolvent vers des versions scellées du registre Seal — vos plages de versions package.json restent les mêmes :

Une version scellée est le même paquet avec le correctif de sécurité rétroporté, donc c'est un remplacement plug-and-play — aucune modification de code, aucune mise à jour de version majeure.

Vérifier la correction

Réexécutez l'URL d'exploitation contre l'application corrigée. L'injection ne s'exécute plus : le ejs scellé rejette le outputFunctionName malveillant et l'application répond avec “Invalid parameter” au lieu d'exécuter la charge utile. Le serveur reste actif.

Comment ajouter Seal à votre propre projet

1. Ajoutez une étape à votre pipeline, après l'installation des dépendances et avant l'empaquetage/regroupement.
2. Pointez seal fix vers le fichier manifeste/verrou spécifique — package-lock.json pour npm. Pour un dépôt avec plusieurs manifestes, exécutez un seal fix par manifeste.
3. Utilisez le mode de correction à distance afin que votre équipe de sécurité gère la politique de correction centralement dans l'interface Seal — rien n'est commis dans le dépôt.
4. Fournissez le jeton Seal via votre magasin de secrets CI (secret GitHub / credential Jenkins).

Voilà toute l'intégration — une étape, sortant uniquement, aucune modification du code de l'application.