Web Assembly est un format d'instructions binaires pour les machines virtuelles basées sur une pile qui permet l'exécution haute performance de code dans les navigateurs Web. Bien qu'il s'exécute dans un environnement sandboxé, les considérations de sécurité incluent une validation appropriée des entrées et la sécurité de la mémoire. Les modules Wasm doivent être traités avec le même niveau de sécurité que les autres codes côté client.
WebAssembly, souvent abrégé en Wasm, est un format d'instructions binaire et portable pour une machine virtuelle à pile qui s'exécute dans les navigateurs web aux côtés de JavaScript. Des langages comme C, C++ et Rust se compilent en modules Wasm compacts qui s'exécutent à une vitesse quasi native, ce qui le rend bien adapté aux travaux gourmands en CPU tels que le traitement vidéo, les jeux, la cryptographie et les outils de CAO dans le navigateur. Wasm ne remplace pas JavaScript ; les deux interopèrent, JavaScript chargeant généralement un module et appelant ses fonctions exportées tandis que le module rappelle des fonctions hôtes importées. Les modules s'exécutent dans le même bac à sable du navigateur que le script de la page et, par conception, n'ont aucun accès direct au DOM, au système de fichiers ou au réseau, si ce n'est via JavaScript et les API du navigateur.
Le bac à sable et le modèle de mémoire linéaire confèrent à WebAssembly une base solide : un module ne peut pas atteindre l'extérieur de sa propre mémoire ni invoquer des capacités hôtes arbitraires sans un import explicite. Mais Wasm reste du code, et sa forme binaire le rend bien plus difficile à examiner pour les humains et pour de nombreux scanneurs que du JavaScript lisible, ce que les attaquants exploitent pour dissimuler de la logique comme des cryptomineurs ou des routines de skimming obfusquées. Des bugs de sécurité mémoire présents dans le C ou le C++ d'origine peuvent survivre à la compilation et être corrompus au sein de la propre mémoire du module. Et comme Wasm n'atteint le monde extérieur qu'à travers ses liaisons JavaScript, un code de liaison faible ou non validé entre les deux est un endroit courant où l'injection et le détournement peuvent se glisser.
Traitez les modules Wasm avec la même vigilance que n'importe quel autre code côté client : compilez-les à partir de sources en lesquelles vous avez confiance, épinglez et vérifiez ce que vous expédiez, et appliquez la Subresource Integrity lorsque vous chargez des modules depuis un CDN afin qu'un binaire altéré soit rejeté. Validez toutes les données qui franchissent la frontière entre JavaScript et Wasm dans les deux sens, et maintenez la page environnante sous une Content Security Policy stricte, qui régit les origines à partir desquelles Wasm peut être instancié. Compilez avec les protections de sécurité mémoire qu'offre votre chaîne d'outils. WebAssembly est une technologie neutre de la plateforme web, si bien que cside n'y est pas spécifiquement lié ; lorsqu'une charge utile Wasm malveillante ou dissimulée arrive via un script tiers, le proxy et l'analyse de charge utile de cside peuvent détecter et bloquer le comportement de ce script.
Il s'exécute dans le même bac à sable du navigateur avec un modèle de mémoire qui limite ce qu'un module peut atteindre, ce qui constitue une base solide. Mais son format binaire est plus difficile à auditer que JavaScript, si bien qu'une logique malveillante peut se dissimuler plus facilement, et que des bugs de mémoire issus du langage source peuvent persister. Plus sûr à certains égards, pas universellement.
Non. Un module Wasm n'a aucun accès direct au DOM, au système de fichiers ou au réseau. Il n'atteint le monde extérieur qu'à travers JavaScript et les API du navigateur qui lui sont explicitement fournies comme imports. Cette frontière est une force sur le plan de la sécurité, mais le code de liaison JavaScript qui l'entoure doit toujours valider ce qui la traverse.
We answer client-side security questions every day. Bring yours.