Explore o funcionamento da portabilidade e segurança do WebAssembly (WASM) com este guia introdutório.
Estes são temas avançados em WebAssembly (WASM). É recomendável que revise os dois artigos anteriores da nossa série “WebAssembly para Iniciantes”.
Vamos começar a análise.
Portabilidade do WebAssembly
A portabilidade é uma das características que tornam o WebAssembly uma tecnologia ideal para a web. De fato, o WASM pode ser considerado uma plataforma de “sandbox” com alta capacidade de movimentação.
Além disso, seu formato binário permite sua execução em diversas arquiteturas de conjuntos de instruções e sistemas operacionais. Isso significa que o WASM pode ser usado não apenas na web, mas também em outros contextos.
Para uma compreensão mais aprofundada da portabilidade do WASM, vamos abordar:
- Ambiente local, restrito e não determinístico.
- Propriedades específicas do ambiente de execução.
- Portabilidade do WASM para web e fora da web.
Local, Restrito e Não Determinístico
O WASM exige ambientes de execução eficientes, locais, restritos e não determinísticos. O não determinismo, neste contexto, refere-se à capacidade de um algoritmo, compilador ou ambiente produzir resultados ou comportamentos distintos, mesmo com as mesmas entradas. É o oposto de um algoritmo determinístico.
Os conceitos de ambiente restrito e local estão intrinsecamente ligados à execução não determinística. Para que a execução não determinística funcione corretamente, é preciso definir casos de uso bem específicos e “restritos”.
Ademais, essas execuções são “locais”, ou seja, não geram efeitos fora do ambiente em questão. Para entender melhor o não determinismo, consulte a documentação oficial do WebAssembly.
Características Particulares do Ambiente de Execução
Para assegurar a portabilidade do WebAssembly, presume-se que o ambiente de execução proporcione as seguintes características:
- Capacidade de endereçamento de memória com granularidade de byte e bytes de 8 bits.
- Inteiros de complemento de dois de 32 bits, com opção para 64 bits.
- Emulação de software por meio de acessos à memória não alinhados ou interceptação confiável.
- Suporte para pontos flutuantes de 32 e 64 bits, de acordo com a norma IEEE 754-2008.
- Garantia de progressão em todas as threads.
- Para acesso de 64 bits, o wasm64 deve fornecer operações de memória atômica sem bloqueio.
- Operações de memória atômica sem bloqueio, incluindo acessos de 8, 16 e 32 bits.
- O 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, como Chrome, Edge, Firefox e WebKit, suportam esses requisitos ambientais.
O WebAssembly está em constante evolução. O WASM Community Group e o W3C WebAssembly Working Group estão trabalhando em sua padronização. Isso implica que alguns desses requisitos podem ser modificados no futuro.
Portabilidade do WASM para Web e Fora da Web
O propósito primordial do WebAssembly é garantir portabilidade e desempenho nativo, tanto na web quanto fora dela. Nesta seção, exploraremos como o WASM alcança esse objetivo.
#1. Integração com a Web
O WASM se integra de maneira eficaz ao ecossistema da web, incorporando o modelo de segurança da web, portabilidade e APIs da web. Também deve existir espaço para desenvolvimentos inovadores (veja o artigo “WebAssembly para Iniciantes – Parte 2” para entender melhor seus objetivos).
Como o WASM consegue compatibilidade com a web? Ele utiliza as APIs JavaScript, permitindo que os desenvolvedores utilizem o JavaScript para facilitar a compilação de módulos WebAssembly. O JavaScript também cuida do armazenamento e recuperação de módulos, gerenciamento de importações, gerenciamento de memória, etc.
Para mais detalhes sobre a integração do WASM com a web, leia este artigo: “Web Embedding – WebAssembly”.
#2. Integração Fora da Web
Como mencionado anteriormente, o WASM também opera em ambientes fora da web. Desenvolvedores e empresas podem criar aplicativos de alto desempenho ou partes específicas de seus aplicativos que demandam otimização de performance. Por exemplo, pode ser usado em dispositivos IoT, servidores de data center e aplicativos para desktop/mobile.
Como os aplicativos fora da web não podem utilizar APIs da web, eles dependem do link dinâmico do WASM. Também é preciso empregar o teste de funcionalidades, um processo de desenvolvimento de software que testa as diferentes variações de funcionalidades para otimizar a experiência do usuário. Desenvolvedores podem usar VMs JavaScript para simplificar a incorporação fora da web ou desenvolver seus aplicativos sem elas.
Para mais informações, leia “Non-Web Embeddings – WebAssembly”.
Segurança do WebAssembly
O WebAssembly é um formato binário que proporciona desempenho próximo ao nativo. Funciona bem na web, mas também pode ser adaptado para incorporações fora da web. Isso faz com que o WASM seja amplamente disponível em serviços, soluções e processos, o que acarreta desafios de segurança.
Riscos e Desafios de Segurança do WASM
Embora o WebAssembly seja considerado seguro e eficiente, apresenta diversos riscos de segurança, incluindo:
- Sandbox do WebAssembly
- Gerenciamento de memória
- Ofuscação de código
- Verificações de integridade
#1. Sandbox do WebAssembly
O WASM é executado no navegador da web, similar ao JavaScript. Ele utiliza a mesma máquina virtual (VM) do JavaScript. O sandbox cria um ambiente de execução seguro e dificulta a análise do que está ocorrendo em segundo plano.
Assim, caso o código JavaScript/WebAssembly contenha código malicioso, sua detecção é difícil, pois se trata de uma “caixa preta”. Além disso, o código WASM está em formato binário, pronto para execução, o que o torna mais rápido e dificulta a ação de softwares antivírus na busca por códigos maliciosos. Por exemplo, o código pode conter anúncios indesejados ou direcionar usuários a sites maliciosos.
Além disso, a dependência do WebAssembly em relação ao JavaScript para executar na web também implica que ele herda as vulnerabilidades do JavaScript. Por isso, como desenvolvedor, é crucial adotar as precauções e medidas de segurança do JavaScript ao programar o WASM.
#2. Gerenciamento de Memória
O gerenciamento de memória no WASM é complexo. Primeiramente, ele não acessa diretamente a memória física enquanto é executado na VM. Em vez disso, utiliza a memória da máquina hospedeira.
Em segundo lugar, a limpeza da memória no WASM requer um processo explícito, enquanto o JavaScript faz a limpeza automaticamente.
Adicionalmente, quando uma função WASM retorna a saída para JavaScript, ela retorna um ponteiro para a posição na memória WASM alocada. Portanto, caso a memória declarada se esgote, o programa WASM pode falhar, prejudicando a experiência do usuário. Para evitar isso, programadores devem usar sanitizadores para depurar o código ou usar ferramentas como o emscripten.
#3. Ofuscação de Código
A execução em sandbox do WASM faz com que o código fique ofuscado. Além disso, o formato binário WASM não é legível por humanos, o que dificulta a engenharia reversa, essencial para identificar códigos maliciosos.
Isso torna a depuração do código WebAssembly difícil devido à falta de um formato legível. Isso cria diversas brechas de segurança, como a capacidade de hackers ocultarem códigos para roubar informações confidenciais ou injetarem códigos para assumir o controle da máquina hospedeira.
#4. Verificações de Integridade
Quaisquer dados transferidos na web estão sujeitos à manipulação de dados. Por exemplo, hackers podem realizar ataques “man-in-the-middle” para modificar os valores dos dados. Isso é um problema para o WASM, já que não há uma maneira adequada de realizar verificações de integridade.
No entanto, é possível trabalhar com JavaScript para realizar verificações de integridade. Outra maneira de identificar vulnerabilidades no código WASM é o uso de ferramentas de integração como o Jit, que garante que o código esteja livre de agentes mal-intencionados e não afete aplicativos ou a infraestrutura na nuvem.
Entendendo o Modelo de Segurança WASM
O WebAssembly leva a segurança a sério. Nos documentos oficiais do WASM, é explicitado que seu modelo de segurança atende a dois objetivos principais:
O modelo de segurança WASM reconhece que aplicativos WebAssembly são executados de forma independente, sem conseguir escapar do ambiente de sandbox. Entretanto, as APIs podem abrir caminhos para ataques ao ambiente hospedeiro.
Outra técnica de tolerância a falhas é a execução determinística de aplicativos, com expectativas limitadas. Ao garantir ambas as condições, a maioria das execuções de aplicativos é considerada segura.
Para aumentar a segurança, desenvolvedores devem aplicar a política de mesma origem para o fluxo de informações. Ao desenvolver fora da web, o modelo de segurança POSIX deve ser utilizado. Para saber mais sobre seu modelo de segurança, veja: “Security – WebAssembly”.
A Interface do Sistema WebAssembly (WASI)
A WASI (WebAssembly System Interface) tem um papel fundamental na incorporação do WASM fora da web, pois aprimora a segurança. É uma interface de sistema modular que oferece excelente segurança e portabilidade.
Na verdade, agora faz parte da Carta do Subgrupo de Interface do Sistema WebAssembly e, portanto, é padronizada. Graças à WASI, o WASM está sendo amplamente adotado em diversas áreas de computação de borda e servidor. Além disso, a WASI simplifica a segurança ao mudar de um ambiente de incorporação web para um ambiente fora da web.
Considerações Finais
A portabilidade e segurança do WebAssembly são temas complexos. Na parte 3 de “WebAssembly para Iniciantes”, procuramos simplificar e detalhar esses conceitos, especialmente para aqueles que estão começando.
Para aprofundar, consulte os resumos de JavaScript para desenvolvedores e estudantes.