Web Assembly es un formato de instrucción binario para máquinas virtuales basadas en pila que permite la ejecución de código de alto rendimiento en los navegadores web. Aunque se ejecuta en un entorno de espacio aislado, las consideraciones de seguridad incluyen la validación de entrada adecuada y la seguridad de la memoria. Los módulos de Wasm deben tratarse con el mismo escrutinio de seguridad que otro código del lado del cliente.
WebAssembly, a menudo abreviado como Wasm, es un formato binario portable de instrucciones para una máquina virtual basada en pila que se ejecuta en los navegadores web junto a JavaScript. Lenguajes como C, C++ y Rust compilan a módulos Wasm compactos que se ejecutan a una velocidad casi nativa, lo que lo hace muy adecuado para trabajo intensivo en CPU como el procesamiento de vídeo, los juegos, la criptografía y las herramientas CAD en el navegador. Wasm no reemplaza a JavaScript; ambos interoperan, y normalmente JavaScript carga un módulo y llama a sus funciones exportadas mientras el módulo hace llamadas de vuelta a funciones anfitrionas importadas. Los módulos se ejecutan dentro del mismo sandbox del navegador que el script de la página y, por diseño, no tienen acceso directo al DOM, al sistema de archivos ni a la red salvo a través de JavaScript y las APIs del navegador.
El sandbox y el modelo de memoria lineal dan a WebAssembly una base sólida: un módulo no puede alcanzar nada fuera de su propia memoria ni invocar capacidades arbitrarias del anfitrión sin un import explícito. Pero Wasm sigue siendo código, y su forma binaria hace que sea mucho más difícil de revisar para las personas y para muchos escáneres que el JavaScript legible, algo que los atacantes aprovechan para ocultar lógica como criptomineros o rutinas de skimming ofuscadas. Los errores de seguridad de memoria del C o C++ original pueden sobrevivir a la compilación y corromperse dentro de la propia memoria del módulo. Y como Wasm alcanza el mundo exterior solo a través de sus enlaces de JavaScript, un código de pegamento débil o sin validar entre ambos es un lugar habitual por el que se cuelan la inyección y el uso indebido.
Trata los módulos Wasm con el mismo escrutinio que cualquier otro código del lado del cliente: constrúyelos a partir de fuentes en las que confíes, fija y verifica lo que despliegas, y aplica Subresource Integrity al cargar módulos desde un CDN para que un binario manipulado sea rechazado. Valida todos los datos que crucen la frontera entre JavaScript y Wasm en ambas direcciones, y mantén la página circundante bajo una Content Security Policy estricta, que gobierna desde dónde se puede instanciar Wasm. Compila con las mitigaciones de seguridad de memoria que ofrezca tu cadena de herramientas. WebAssembly es una tecnología neutral de la plataforma web, así que cside no está ligado a él específicamente; cuando una carga Wasm maliciosa u oculta llega a través de un script de terceros, el proxy y el análisis de carga útil de cside pueden detectar y bloquear el comportamiento de ese script.
Se ejecuta en el mismo sandbox del navegador con un modelo de memoria que limita lo que un módulo puede alcanzar, lo que es una base sólida. Pero su formato binario es más difícil de auditar que JavaScript, así que la lógica maliciosa puede ocultarse más fácilmente, y los errores de memoria del lenguaje de origen pueden persistir. Más seguro en algunos aspectos, no de forma universal.
No. Un módulo Wasm no tiene acceso directo al DOM, al sistema de archivos ni a la red. Alcanza el mundo exterior solo a través de JavaScript y las APIs del navegador que se le dan explícitamente como imports. Esa frontera es una fortaleza de seguridad, pero el pegamento de JavaScript que la rodea todavía debe validar lo que pasa a través de ella.
We answer client-side security questions every day. Bring yours.