Confira como funcionam os modelos de portabilidade e segurança do WebAssembly (WASM) neste guia para iniciantes.
Ambos são tópicos avançados de WebAssembly (WASM). Recomendamos que você leia os dois tópicos anteriores em nossa série WebAssembly for Beginner.
Vamos começar.
últimas postagens
Portabilidade WebAssembly
A portabilidade do WebAssembly o torna pronto para a Web. Na verdade, você pode definir o WASM como uma plataforma de sandbox portátil.
Além disso, seu formato binário permite a execução em várias arquiteturas de conjunto de instruções e sistemas operacionais. Isso significa que você pode usar o WASM não apenas na Web, mas também fora dela.
Para entender a portabilidade do WASM, discutiremos o seguinte:
- Ambiente local, limitado e não determinístico.
- Características específicas do ambiente de execução
- Portabilidade web e não-web WASM
Local, limitado e não determinístico
O WASM precisa de uma execução eficiente e ambientes adequados que sejam locais, limitados e não determinísticos. O não determinismo é a computação que especifica que um algoritmo/compilador/ambiente produz diferentes comportamentos ou resultados, mesmo para a mesma entrada. É o oposto de um algoritmo determinístico.
Os dois outros aspectos, limitado e local, estão associados à execução não determinística. Para fazer a execução não determinística funcionar, você precisa de casos de uso bem definidos que sejam “limitados”.
Além disso, essas execuções são “locais” sem efeito fora do ambiente. Leia seu não determinismo oficial no documento do WebAssembly para aprender mais sobre ele.
Características Específicas do Ambiente de Execução
Para tornar o WebAssembly portátil, ele assume que o ambiente de execução oferece as seguintes características:
- Capacidade de endereçamento de granularidade de memória de bytes e bytes de 8 bits.
- Inteiros com sinal de complemento de dois de 32 bits. Opcionalmente 64 bits.
- A emulação de software é possível por meio de acessos de memória não alinhados ou interceptação confiável.
- Suporte para pontos flutuantes de 32 bits e 64 bits, conforme definido no IEEE 754-2008.
- Garanta a execução de todos os threads com progresso progressivo.
- Para acesso de 64 bits, wasm64 deve fornecer operadores de memória atômica sem bloqueio.
- Os operadores de memória atômica livre de bloqueio incluem acessos de 8, 16 e 32 bits.
- wasm64 suporta memória linear superior a 4 GiB com índices ou ponteiros de 64 bits.
- Ordenação de bytes Little-endian.
Todos os principais navegadores, incluindo Chrome, Edge, Firefox e WebKit, suportam todos esses requisitos ambientais.
Além disso, o WebAssembly está evoluindo rapidamente. O WASM Community Group e o W3C WebAssembly Working Group estão trabalhando para sua padronização. Isso significa que qualquer um desses requisitos pode mudar no futuro.
Portabilidade Web e não Web WASM
O objetivo principal do WebAssembly é fornecer portabilidade e desempenho nativo na Web e fora da Web. Nesta seção, veremos como o WASM consegue isso.
#1. Incorporação na Web
O WASM integra-se bem com o ecossistema da Web, incluindo o modelo de segurança da Web, portabilidade da Web e APIs da Web. Além disso, deve ter espaço suficiente para o desenvolvimento criativo no caminho (leia WebAssembly para iniciantes – Parte 2 para entender seus objetivos)
Então, como o WASM consegue compatibilidade com a Web? Ele utiliza APIs JavaScript, permitindo que os desenvolvedores usem JavaScript para compilação de módulos WebAssembly facilmente. Ele também se encarrega de armazenar e recuperar os módulos do compilador, gerenciar as importações dos módulos do compilador, gerenciar a memória e assim por diante.
Para saber mais sobre como o WASM alcança compatibilidade de alto nível com a Web, leia isto: Web Embedding – WebAssembly.
#2. Incorporação não Web
Conforme mencionado anteriormente, o WASM também funciona com ambientes não web. Como desenvolvedor ou empresa, você pode criar aplicativos de alto desempenho ou escrever seções de seu aplicativo que precisam de ajuste de desempenho. Por exemplo, você pode usá-lo em dispositivos IoT, servidores de data center e aplicativos de desktop/móveis.
Como os aplicativos não-web não podem usar APIs da web, eles contam com o link dinâmico do WASM. Você também precisa usar o teste de recursos, um processo de desenvolvimento de software que testa as múltiplas variações dos recursos para ver o que é melhor para a experiência do usuário. Além disso, os desenvolvedores podem usar VMs JavaScript para simplificar a incorporação não-web ou desenvolver seus aplicativos sem ela.
Para saber mais, leia Non-Web Embeddings – WebAssembly.
Segurança do WebAssembly
O WebAssembly é uma solução de formato binário que oferece desempenho semelhante ao nativo. Ele funciona muito bem na Web, mas também pode ser ajustado para funcionar em incorporações fora da Web. Isso torna o WASM amplamente disponível em serviços, soluções e processos. No entanto, isso significa mais desafios de segurança.
Desafios e riscos de segurança do WASM
Embora o WebAssembly seja considerado seguro e eficiente, ele apresenta vários riscos de segurança, incluindo:
- Caixa de areia do WebAssembly
- Gerenciamento de memória
- Ofuscação de código
- verificações de integridade
#1. Sandbox WebAssembly
O WASM é executado no navegador da Web, assim como o JavaScript. Ele utiliza a mesma máquina virtual (VM) que o JavaScript. A caixa de areia fornece efetivamente um ambiente de execução seguro e dificulta o que está sendo executado sob o capô.
Portanto, se o código JavaScript/WebAssembly contiver código malicioso, é difícil detectá-lo, pois é uma caixa preta. Além disso, o código WASM está em formato binário pronto para execução; ele roda mais rápido, tornando difícil para as soluções antivírus procurar por qualquer código malicioso. Por exemplo, o código pode conter anúncios indesejados ou a capacidade de redirecionar usuários para sites de malware indesejados.
Além disso, o excesso de confiança do WebAssembly no JavaScript para ser executado na Web também significa que ele herda as vulnerabilidades do JavaScript. É por isso que, como desenvolvedor, você deve seguir as precauções e medidas de segurança do JavaScript ao codificar o WASM.
#2. Gerenciamento de memória
O gerenciamento de memória no WASM é complicado. Em primeiro lugar, ele não acessa diretamente a memória física enquanto é executado na VM. É por isso que ele usa a memória da máquina host.
Em segundo lugar, limpar a memória no WASM requer um processo explícito, enquanto, em comparação, o JavaScript limpa a si mesmo.
Além disso, quando uma função WASM retorna a saída para JavaScript, ela retorna um ponteiro para a posição dentro do espaço de memória WASM alocado. Portanto, se a memória declarada ficar cheia, o programa WASM pode travar, arruinando a experiência do usuário. Para evitá-lo, os programadores precisam usar desinfetantes para depurar seu código ou usar cadeias de ferramentas como emscripten.
#3. Ofuscação de código
A execução do sandbox do WASM torna seu código ofuscado. Além disso, o formato binário WASM também não é legível por humanos, dificultando a engenharia reversa, necessária para identificar códigos maliciosos.
Isso torna o código do WebAssembly difícil de depurar devido à falta de formato legível por humanos. Isso abre muitas brechas de segurança, incluindo a capacidade dos hackers de ocultar códigos que roubam informações confidenciais ou injetam códigos para assumir o controle da máquina host.
#4. Verificações de Integridade
Quaisquer dados transferidos pela Web são vulneráveis à manipulação de dados. Por exemplo, os hackers podem realizar um ataque man-in-the-middle para alterar os valores dos dados. É um problema para o WASM, considerando que não há uma maneira adequada de fazer verificações de integridade.
No entanto, ele pode trabalhar com JavaScript para realizar verificações de integridade. Outra maneira de identificar possíveis vulnerabilidades do código WASM é usar ferramentas de integração como o Jit. Ele garante que o código esteja livre de agentes mal-intencionados e não afete os aplicativos ou a infraestrutura de nuvem ao redor.
Compreendendo o modelo de segurança WASM
O WebAssembly leva a segurança a sério. É por isso que, nos documentos oficiais do WASM, eles mencionaram que seu modelo de segurança atende a dois objetivos importantes:
O modelo de segurança WASM sabe que os aplicativos WebAssembly são executados de forma independente, sem conseguir escapar de seu ambiente de sandbox. No entanto, as APIs podem abrir uma maneira de atacar o ambiente do host.
Outra técnica tolerante a falhas inclui a execução de aplicativos de forma determinística com expectativas limitadas. Ao garantir ambas as condições, a maioria das execuções de aplicativos é considerada segura.
Para melhorar a segurança, os desenvolvedores devem impor a política de mesma origem para o fluxo de informações. Se você estiver desenvolvendo para fora da Web, deverá usar o modelo de segurança POSIX. Se você quiser ler mais sobre seu modelo de segurança, confira: Security – WebAssembly.
A interface do sistema WebAssembly (WASI)
WASI (The WebAssembly System Interface) também desempenha um papel crucial na incorporação não-web do WASM, pois melhora a segurança. É uma interface de sistema modular que oferece excelentes características de segurança e portabilidade.
Na verdade, ele agora faz parte da Carta do Subgrupo de Interface do Sistema WebAssembly e, portanto, é padronizado. Devido ao WASI, o WASM é amplamente adotado em diferentes áreas de computação de borda/servidor. Além disso, o WASI simplifica a segurança ao mudar para uma incorporação não-web de um ambiente de incorporação da web.
Palavras Finais
A portabilidade e a segurança do WebAssembly são dois grandes tópicos. Na parte 3 do WebAssembly para iniciantes, tentamos simplificá-lo e dividi-lo, especialmente para iniciantes.
Em seguida, você pode conferir as folhas de dicas do JavaScript para desenvolvedores e alunos.