Maison  >  Article  >  interface Web  >  Exécution de code JavaScript non fiable

Exécution de code JavaScript non fiable

WBOY
WBOYoriginal
2024-07-22 07:10:291191parcourir

Running Untrusted JavaScript Code

IMPORTANT : Il s'agit uniquement d'exécuter du code JavaScript et TypeScript. Cela étant dit, l'écriture peut également être la direction pour exécuter d'autres codes dans d'autres langues.

Permettre aux utilisateurs d'exécuter leur code dans votre application ouvre un monde de personnalisation et de fonctionnalités, mais cela expose également votre plate-forme à des menaces de sécurité importantes.

Étant donné qu'il s'agit d'un code utilisateur, tout est attendu, de l'arrêt des serveurs (il pourrait s'agir de boucles infinies) jusqu'au vol d'informations sensibles.

Cet article explorera diverses stratégies pour atténuer l'exécution du code utilisateur, notamment les Web Workers, l'analyse de code statique, et bien plus encore…

Tu devrais t'en soucier

Il existe de nombreux scénarios dans lesquels vous devez exécuter du code fourni par l'utilisateur, allant des environnements de développement collaboratifs comme CodeSandbox et StackBiltz aux plates-formes API personnalisables comme January. Même les terrains de jeux de code sont sensibles aux risques.

À savoir, les deux avantages essentiels de l’exécution en toute sécurité du code fourni par l’utilisateur sont :

  1. Gagner la confiance de votre utilisateur : même si l'utilisateur est digne de confiance, il peut exécuter du code copié par d'autres personnes intentionnellement malveillantes.
  2. Sécurisez votre environnement : la dernière chose dont vous avez besoin est un morceau de code qui arrête votre serveur. Réfléchissez pendant que (vrai) {}

Définir les « informations sensibles »

L'exécution de code utilisateur n'est pas dangereuse à moins que vous craigniez que cela puisse entraîner le vol de certaines données. Toutes les données qui vous préoccupent seront considérées comme des informations sensibles. Par exemple, dans la plupart des cas, JWT est une information sensible (peut-être lorsqu'elle est utilisée comme mécanisme d'authentification)

Qu'est-ce qui pourrait mal se passer

Considérez les risques potentiels de JWT stocké dans les cookies envoyés à chaque demande. Un utilisateur pourrait par inadvertance déclencher une requête qui envoie le JWT à un serveur malveillant, et...

  • Scripts intersites (XSS).
  • Attaques par déni de service (DoS).
  • Exfiltration de données. Sans mesures de protection appropriées, ces menaces peuvent compromettre l'intégrité et les performances de votre application.

Méthodes

L'évaluation maléfique

Le plus simple de tous, mais le plus risqué.

eval('console.log("I am dangerous!")');

Lorsque vous exécutez ce code, il enregistre ce message. Essentiellement, eval est un interpréteur JS capable d'accéder à la portée globale/fenêtre.

const res = await eval('fetch(`https://jsonplaceholder.typicode.com/users`)');
const users = await res.json();

Ce code utilise fetch qui est défini dans la portée globale. L’interprète ne le sait pas, mais comme eval peut accéder à une fenêtre, il le sait. Cela implique que l'exécution d'une évaluation dans le navigateur est différente de son exécution dans un environnement de serveur ou de travail.

eval(`document.body`);

Et ça...

eval(`while (true) {}`);

Ce code arrêtera l'onglet du navigateur. Vous pourriez vous demander pourquoi un utilisateur se ferait cela. Eh bien, ils copient peut-être du code sur Internet. C'est pourquoi il est préférable de faire une analyse statique avec/ou de chronométrer l'exécution.

Vous voudrez peut-être consulter MDN Docs à propos de l'évaluation

L'exécution de la boîte de temps peut être effectuée en exécutant le code dans un Web Worker et en utilisant setTimeout pour limiter le temps d'exécution.

async function timebox(code, timeout = 5000) {
  const worker = new Worker('user-runner-worker.js');
  worker.postMessage(code);

  const timerId = setTimeout(() => {
    worker.terminate();
    reject(new Error('Code execution timed out'));
  }, timeout);

  return new Promise((resolve, reject) => {
    worker.onmessage = event => {
      clearTimeout(timerId);
      resolve(event.data);
    };
    worker.onerror = error => {
      clearTimeout(timerId);
      reject(error);
    };
  });
}

await timebox('while (true) {}');

Constructeur de fonction

Ceci est similaire à eval mais c'est un peu plus sûr car il ne peut pas accéder à la portée englobante.

const userFunction = new Function('param', 'console.log(param);');
userFunction(2);

Ce code en enregistrera 2.

Remarque : Le deuxième argument est le corps de la fonction.

Le constructeur de la fonction ne peut pas accéder à la portée englobante, de sorte que le code suivant génère une erreur.

function fnConstructorCannotUseMyScope() {
  let localVar = 'local value';
  const userFunction = new Function('return localVar');
  return userFunction();
}

Mais il peut accéder à la portée globale donc l'exemple de récupération ci-dessus fonctionne.

Travailleur Web

Vous pouvez exécuter « Function Constructor et eval sur un WebWorker, ce qui est un peu plus sûr car il n'y a pas d'accès au DOM.

Pour mettre en place davantage de restrictions, envisagez d'interdire l'utilisation d'objets globaux tels que fetch, XMLHttpRequest, sendBeacon. Consultez cet écrit pour savoir comment procéder.

VM isolée

Isolated-VM est une bibliothèque qui vous permet d'exécuter du code dans une VM distincte (interface Isolate de la v8)

import ivm from 'isolated-vm';

const code = `count += 5;`;

const isolate = new ivm.Isolate({ memoryLimit: 32 /* MB */ });
const script = isolate.compileScriptSync(code);
const context = isolate.createContextSync();

const jail = context.global;
jail.setSync('log', console.log);

context.evalSync('log("hello world")');

Ce code enregistrera Bonjour tout le monde

Assemblage Web

Il s'agit d'une option intéressante car elle fournit un environnement en bac à sable pour exécuter du code. Une mise en garde est que vous avez besoin d'un environnement avec des liaisons Javascript. Cependant, un projet intéressant appelé Extisme facilite cela. Vous voudrez peut-être suivre leur tutoriel.

Ce qui est fascinant, c'est que vous utiliserez eval pour exécuter le code, mais étant donné la nature de WebAssembly, le DOM, le réseau, le système de fichiers et l'accès à l'environnement hôte ne sont pas possibles (bien qu'ils puissent différer en fonction de le runtime wasm).

function evaluate() {
  const { code, input } = JSON.parse(Host.inputString());
  const func = eval(code);
  const result = func(input).toString();
  Host.outputString(result);
}

module.exports = { evaluate };

You'll have to compile the above code first using Extism, which will output a Wasm file that can be run in an environment that has Wasm-runtime (browser or node.js).

const message = {
  input: '1,2,3,4,5',
  code: `
        const sum = (str) => str
          .split(',')
          .reduce((acc, curr) => acc + parseInt(curr), 0);
        module.exports = sum;
`,
};

// continue running the wasm file

Docker

We're now moving to the server-side, Docker is a great option to run code in an isolation from the host machine. (Beware of container escape)

You can use dockerode to run the code in a container.

import Docker from 'dockerode';
const docker = new Docker();

const code = `console.log("hello world")`;
const container = await docker.createContainer({
  Image: 'node:lts',
  Cmd: ['node', '-e', code],
  User: 'node',
  WorkingDir: '/app',
  AttachStdout: true,
  AttachStderr: true,
  OpenStdin: false,
  AttachStdin: false,
  Tty: true,
  NetworkDisabled: true,
  HostConfig: {
    AutoRemove: true,
    ReadonlyPaths: ['/'],
    ReadonlyRootfs: true,
    CapDrop: ['ALL'],
    Memory: 8 * 1024 * 1024,
    SecurityOpt: ['no-new-privileges'],
  },
});

Keep in mind that you need to make sure the server has docker installed and running. I'd recommend having a separate server dedicated only to this that acts as a pure-function server.

Moreover, you might benefit from taking a look at sysbox, a VM-like container runtime that provides a more secure environment. Sysbox is worth it, especially if the main app is running in a container, which means that you'll be running Docker in Docker.

This was the method of choice at January but soon enough, the language capabilities mandated more than passing the code through the container shell. Besides, for some reason, the server memory spikes frequently; we run the code inside self-removable containers on every 1s debounced keystroke. (You can do better!)

Other options

  • Web Containers
  • MicroVM (Firecraker)
  • Deno subhosting
  • Wasmer
  • ShadowRealms

Safest option

I'm particularly fond of Firecracker, but it’s a bit of work to set up, so if you cannot afford the time yet, you want to be on the safe side, do a combination of static analysis and time-boxing execution. You can use esprima to parse the code and check for any malicious act.

How to run TypeScript code?

Well, same story with one (could be optional) extra step: Transpile the code to JavaScript before running it. Simply put, you can use esbuild or typescript compiler, then continue with the above methods.

async function build(userCode: string) {
  const result = await esbuild.build({
    stdin: {
      contents: `${userCode}`,
      loader: 'ts',
      resolveDir: __dirname,
    },
    inject: [
      // In case you want to inject some code
    ],
    platform: 'node',
    write: false,
    treeShaking: false,
    sourcemap: false,
    minify: false,
    drop: ['debugger', 'console'],
    keepNames: true,
    format: 'cjs',
    bundle: true,
    target: 'es2022',
    plugins: [
      nodeExternalsPlugin(), // make all the non-native modules external
    ],
  });
  return result.outputFiles![0].text;
}

Notes:

  • Rust-based bundlers usually offer a web assembly version, which means you can transpile the code in the browser. Esbuild does have a web assembly version.
  • Don't include user specified imports into the bundle unless you've allow-listed them.

Additionally, you can avoid transpiling altogether by running the code using Deno or Bun in a docker container since they support TypeScript out of the box.

Conclusion

Running user code is a double-edged sword. It can provide a lot of functionality and customization to your platform, but it also exposes you to significant security risks. It’s essential to understand the risks and take appropriate measures to mitigate them and remember that the more isolated the environment, the safer it is.

References

  • January instant compilation
  • Running untrusted JavaScript in Node.js
  • How do languages support executing untrusted user code at runtime?
  • Safely Evaluating JavaScript with Context Data

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!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn