WebAssembly pour les débutants, partie 3 : Comment fonctionnent la portabilité et la sécurité de WASM

Découvrez comment fonctionnent les modèles de portabilité et de sécurité WebAssembly (WASM) dans ce guide du débutant.

Les deux sont des sujets WebAssembly avancés (WASM). Nous vous recommandons de lire les deux rubriques précédentes de notre série WebAssembly for Beginner.

• WebAssembly pour les débutants - Partie 1 : Une introduction à WASM
• WebAssembly pour les débutants - Partie 2 : Objectifs, concepts clés et cas d'utilisation

Commençons.

Portabilité WebAssembly

La portabilité de WebAssembly le rend prêt pour le Web. En fait, vous pouvez définir WASM comme une plate-forme portable en bac à sable.

De plus, son format binaire lui permet de s'exécuter sur diverses architectures de jeu d'instructions et systèmes d'exploitation. Cela signifie que vous pouvez utiliser WASM non seulement sur le Web, mais également en dehors du Web.

Pour comprendre la portabilité WASM, nous aborderons les points suivants :

• Environnement local, limité et non déterministe.
• Caractéristiques spécifiques de l'environnement d'exécution
• Portabilité Web et non Web WASM

Local, limité et non déterministe

WASM a besoin d'une exécution efficace et d'environnements appropriés qui sont locaux, limités et non déterministes. Le non-déterminisme est un calcul qui spécifie qu'un algorithme/compilateur/environnement produit des comportements ou des résultats différents même pour la même entrée. C'est le contraire d'un algorithme déterministe.

Les deux autres aspects, limité et local , sont associés à une exécution non déterministe. Pour que l'exécution non déterministe fonctionne, vous avez besoin de cas d'utilisation bien définis qui sont « limités ».

De plus, ces exécutions sont « locales » sans effet en dehors de l'environnement. Lisez leur non-déterminisme officiel dans la documentation WebAssembly pour en savoir plus à ce sujet.

Caractéristiques spécifiques de l'environnement d'exécution

Pour rendre WebAssembly portable, il suppose que l'environnement d'exécution offre les caractéristiques suivantes :

• Adressabilité de la granularité de la mémoire en octets et octets de 8 bits.
• Entiers signés complément à deux 32 bits. Optionnellement 64 bits.
• L'émulation logicielle est possible via des accès mémoire non alignés ou un piégeage fiable.
• Prise en charge des virgules flottantes 32 bits et 64 bits comme défini dans IEEE 754-2008.
• Garantit l'exécution de tous les threads avec une progression vers l'avant.
• Pour un accès 64 bits, wasm64 devrait fournir des opérateurs de mémoire atomique sans verrouillage.
• Les opérateurs de mémoire atomique sans verrouillage incluent des accès 8, 16 et 32 ​​bits.
• wasm64 prend en charge la mémoire linéaire supérieure à 4 Gio avec des index ou des pointeurs 64 bits.
• Ordre des octets petit boutien.

Tous les principaux navigateurs, y compris Chrome, Edge, Firefox et WebKit, prennent en charge toutes ces exigences environnementales.

De plus, WebAssembly évolue à un rythme rapide. Le groupe communautaire WASM et le groupe de travail W3C WebAssembly travaillent à sa standardisation. Cela signifie que chacune de ces exigences peut changer à l'avenir.

Portabilité Web et non Web WASM

L'objectif principal de WebAssembly est de fournir une portabilité et des performances natives sur le Web et hors du Web. Dans cette section, nous verrons comment WASM y parvient.

#1. Intégration Web

WASM s'intègre bien à l'écosystème Web, y compris le modèle de sécurité Web, la portabilité Web et les API Web. De plus, il doit avoir suffisamment de place pour un développement créatif ultérieur (lisez WebAssembly for Beginners - Part 2 pour comprendre ses objectifs)

Alors, comment WASM parvient-il à la compatibilité avec le Web ? Il utilise des API JavaScript, permettant aux développeurs d'utiliser facilement JavaScript pour la compilation de modules WebAssembly. Il s'occupe également du stockage et de la récupération des modules du compilateur, de la gestion des importations à partir des modules du compilateur, de la gestion de la mémoire, etc.

Pour en savoir plus sur la façon dont WASM atteint une compatibilité Web de haut niveau, lisez ceci : Web Embedding – WebAssembly.

#2. Intégration non Web

Comme mentionné précédemment, WASM fonctionne également avec des environnements non Web. En tant que développeur ou entreprise, vous pouvez créer des applications hautes performances ou écrire des sections de votre application qui nécessitent un réglage des performances. Par exemple, vous pouvez l'utiliser sur des appareils IoT, des serveurs de centres de données et des applications de bureau/mobiles.

Comme les applications non Web ne peuvent pas utiliser les API Web, elles s'appuient sur la liaison dynamique de WASM. Vous devez également utiliser les tests de fonctionnalités, un processus de développement logiciel qui teste les multiples variantes des fonctionnalités pour déterminer ce qui convient le mieux à l'expérience utilisateur. De plus, les développeurs peuvent utiliser des machines virtuelles JavaScript pour simplifier l'intégration non Web ou développer leurs applications sans elle.

Pour en savoir plus, lisez Non-Web Embeddings – WebAssembly.

Sécurité WebAssembly

WebAssembly est une solution au format binaire qui offre des performances de type natif. Il fonctionne très bien sur le Web, mais peut également être ajusté pour fonctionner sur des incorporations non Web. Cela rend WASM largement disponible dans tous les services, solutions et processus. Cependant, cela signifie plus de problèmes de sécurité.

Défis et risques de sécurité WASM

Même si WebAssembly est considéré comme sûr et efficace, il comporte de multiples risques de sécurité, notamment :

• Bac à sable WebAssembly
• Gestion de la mémoire
• Obfuscation de code
• Contrôles d'intégrité

#1. Bac à sable WebAssembly

WASM s'exécute dans le navigateur Web, tout comme JavaScript. Il utilise la même machine virtuelle (VM) que JavaScript. Le bac à sable fournit efficacement un environnement d'exécution sûr et entrave ce qui se passe sous le capot.

Ainsi, si le code JavaScript/WebAssembly contient du code malveillant, il est difficile à détecter car il s'agit d'une boîte noire. De plus, le code WASM est au format binaire prêt à l'emploi ; il s'exécute plus rapidement, ce qui rend difficile pour les solutions antivirus de rechercher tout code malveillant. Par exemple, le code peut contenir des publicités indésirables ou la possibilité de rediriger les utilisateurs vers des sites malveillants indésirables.

De plus, la dépendance excessive de WebAssembly vis-à-vis de JavaScript pour s'exécuter sur le Web signifie également qu'il hérite des vulnérabilités de JavaScript. C'est pourquoi, en tant que développeur, vous devez suivre les précautions et les mesures de sécurité de JavaScript lors du codage de WASM.

#2. Gestion de la mémoire

La gestion de la mémoire dans WASM est délicate. Premièrement, il n'accède pas directement à la mémoire physique car il s'exécute dans la VM. C'est pourquoi il utilise la mémoire de la machine hôte.

Deuxièmement, le nettoyage de la mémoire dans WASM nécessite un processus explicite, alors que, en comparaison, JavaScript se nettoie lui-même.

De plus, lorsqu'une fonction WASM renvoie une sortie à JavaScript, elle renvoie un pointeur vers la position dans l'espace mémoire WASM alloué. Ainsi, si la mémoire déclarée est pleine, le programme WASM peut planter, ruinant l'expérience de l'utilisateur. Pour l'empêcher, les programmeurs doivent utiliser des désinfectants pour déboguer leur code ou utiliser des chaînes d'outils telles que emscripten.

#3. Obfuscation de code

L'exécution du bac à sable de WASM rend son code obscurci. De plus, le format binaire WASM n'est pas non plus lisible par l'homme, ce qui rend difficile l'ingénierie inverse, qui est nécessaire pour identifier le code malveillant.

Ceux-ci rendent le code WebAssembly difficile à déboguer en raison de son manque de format lisible par l'homme. Cela ouvre de nombreuses failles de sécurité, y compris la capacité des pirates à cacher du code qui vole des informations sensibles ou qui injecte du code pour prendre le contrôle de la machine hôte.

#4. Contrôles d'intégrité

Toutes les données transférées via le Web sont vulnérables à la trempe des données. Par exemple, les pirates peuvent effectuer une attaque man-in-the-middle pour modifier les valeurs des données. C'est un problème pour WASM, étant donné qu'il n'a aucun moyen approprié d'effectuer des contrôles d'intégrité.

Cependant, il peut fonctionner avec JavaScript pour effectuer des contrôles d'intégrité. Une autre façon d'identifier les vulnérabilités potentielles du code WASM consiste à utiliser des outils d'intégration tels que Jit. Il garantit que le code est exempt d'acteurs malveillants et ne peut pas avoir d'impact sur les applications ou l'infrastructure cloud environnante.

Comprendre le modèle de sécurité WASM

WebAssembly prend la sécurité au sérieux. C'est pourquoi, dans la documentation officielle de WASM, ils ont mentionné que leur modèle de sécurité prend en charge deux objectifs importants :

1. Assurez-vous qu'aucun module bogué ou malveillant n'affecte les utilisateurs
2. Assurez-vous que les développeurs peuvent atténuer les risques de sécurité et créer des applications sûres tout en veillant à ce que le point 1 soit toujours maintenu.

Le modèle de sécurité WASM sait que les applications WebAssembly s'exécutent indépendamment sans pouvoir échapper à son environnement sandbox. Cependant, les API peuvent ouvrir un moyen d'attaquer l'environnement hôte.

Une autre technique tolérante aux pannes consiste à exécuter des applications de manière déterministe avec des attentes limitées. En garantissant les deux conditions, la plupart des exécutions d'applications sont considérées comme sûres.

Pour améliorer la sécurité, les développeurs doivent appliquer la politique de même origine pour le flux d'informations. Si vous développez pour des applications non Web, vous devez utiliser le modèle de sécurité POSIX. Si vous souhaitez en savoir plus sur son modèle de sécurité, consultez : Sécurité – WebAssembly.

L'interface système WebAssembly (WASI)

WASI (The WebAssembly System Interface) joue également un rôle crucial dans l'intégration non Web de WASM car il améliore la sécurité. Il s'agit d'une interface système modulaire qui offre des caractéristiques de sécurité et une portabilité intéressantes.

En fait, il fait désormais partie de la charte du sous-groupe d'interface système WebAssembly et est donc normalisé. Grâce à WASI, WASM est largement adopté dans différents domaines informatiques edge/server. En outre, WASI simplifie la sécurité lors du passage à une intégration non Web à partir d'un environnement d'intégration Web.

Derniers mots

La portabilité et la sécurité de WebAssembly sont deux grands sujets. Dans la partie 3 du WebAssembly pour les débutants, nous avons essayé de le simplifier et de le décomposer, en particulier pour les débutants.

Ensuite, vous pouvez consulter les feuilles de triche JavaScript pour les développeurs et les apprenants.