WebAssembly Untuk Pemula Bagian 3: Cara Kerja Portabilitas dan Keamanan WASM

Lihat cara kerja model portabilitas dan keamanan WebAssembly (WASM) dalam panduan pemula ini.

Keduanya adalah topik WebAssembly (WASM) lanjutan. Kami menyarankan Anda membaca dua topik sebelumnya di seri WebAssembly for Beginner kami.

• WebAssembly untuk Pemula – Bagian 1: Pengantar WASM
• WebAssembly untuk Pemula – Bagian 2: Sasaran, Konsep Utama, dan Kasus Penggunaan

Mari kita mulai.

Portabilitas WebAssembly

Portabilitas WebAssembly membuatnya siap untuk Web. Faktanya, Anda dapat mendefinisikan WASM sebagai platform kotak pasir portabel.

Selain itu, format binernya memungkinkannya untuk mengeksekusi di berbagai arsitektur set instruksi dan sistem operasi. Ini berarti Anda dapat menggunakan WASM tidak hanya di Web tetapi juga di luar Web.

Untuk memahami portabilitas WASM, kita akan membahas hal berikut:

• Lingkungan lokal, terbatas, dan nondeterministik.
• Karakteristik lingkungan eksekusi khusus
• Portabilitas web dan non-web WASM

Lokal, Terbatas, dan Nondeterministik

WASM membutuhkan eksekusi yang efisien dan lingkungan yang tepat yang bersifat lokal, terbatas, dan nondeterminisme. Nondeterminisme adalah komputasi yang menentukan bahwa suatu algoritma/kompiler/lingkungan menghasilkan perilaku atau hasil yang berbeda bahkan untuk input yang sama. Ini adalah kebalikan dari algoritma deterministik.

Dua aspek lainnya, limited dan local , terkait dengan eksekusi nondeterministik. Agar eksekusi nondeterministik berhasil, Anda memerlukan kasus penggunaan yang terdefinisi dengan baik yang “ terbatas ”.

Juga, eksekusi ini bersifat “ lokal ” tanpa efek di luar lingkungan. Baca nondeterminisme resmi mereka di dokumen WebAssembly untuk mempelajarinya lebih lanjut.

Karakteristik Lingkungan Eksekusi Spesifik

Untuk menjadikan WebAssembly portabel, diasumsikan bahwa lingkungan eksekusi menawarkan karakteristik berikut:

• Pengalamatan perincian memori byte dan byte 8-bit.
• Pelengkap 32-bit dua bilangan bulat bertanda tangan. Opsional 64 bit.
• Emulasi perangkat lunak dimungkinkan melalui akses memori yang tidak selaras atau perangkap yang andal.
• Dukungan untuk floating point 32-bit dan 64-bit sebagaimana didefinisikan dalam IEEE 754-2008.
• Jaminan untuk mengeksekusi semua utas dengan kemajuan maju.
• Untuk akses 64-bit, wasm64 harus menyediakan operator memori atom bebas kunci.
• Operator memori atom bebas kunci mencakup akses 8, 16, dan 32-bit.
• wasm64 mendukung memori linier lebih tinggi dari 4 GiB dengan indeks atau pointer 64-bit.
• Pengurutan byte Little-endian.

Semua browser utama, termasuk Chrome, Edge, Firefox, dan WebKit, mendukung semua persyaratan lingkungan ini.

Selain itu, WebAssembly berkembang dengan sangat cepat. Kelompok Komunitas WASM dan Kelompok Kerja W3C WebAssembly sedang bekerja menuju standarisasinya. Itu berarti salah satu dari persyaratan ini dapat berubah di masa mendatang.

Portabilitas Web dan Non-Web WASM

Tujuan utama WebAssembly adalah untuk memberikan portabilitas dan kinerja asli di Web dan non-web. Di bagian ini, kita akan melihat bagaimana WASM mencapainya.

#1. Penyematan Web

WASM terintegrasi dengan baik dengan ekosistem Web, termasuk model keamanan Web, portabilitas web, dan API web. Selain itu, ia harus memiliki ruang yang cukup untuk pengembangan kreatif di masa mendatang (baca WebAssembly untuk Pemula – Bagian 2 untuk memahami tujuannya)

Jadi, bagaimana WASM mencapai kompatibilitas dengan Web? Itu menggunakan API JavaScript, memungkinkan pengembang untuk menggunakan JavaScript untuk kompilasi modul WebAssembly dengan mudah. Itu juga menangani penyimpanan dan pengambilan modul kompiler, mengelola impor dari modul kompiler, mengelola memori, dan sebagainya.

Untuk mempelajari lebih lanjut tentang bagaimana WASM mencapai kompatibilitas Web tingkat tinggi, baca ini: Penyematan Web – WebAssembly.

#2. Penyematan Non-Web

Seperti disebutkan sebelumnya, WASM juga berfungsi dengan lingkungan non-web. Sebagai pengembang atau bisnis, Anda dapat membuat aplikasi berperforma tinggi atau menulis bagian aplikasi yang memerlukan penyempurnaan kinerja. Misalnya, Anda dapat menggunakannya di perangkat IoT, server pusat data, dan aplikasi desktop/seluler.

Karena aplikasi non-web tidak dapat menggunakan API web, mereka bergantung pada penautan dinamis WASM. Anda juga perlu menggunakan pengujian fitur, proses pengembangan perangkat lunak yang menguji berbagai variasi fitur untuk melihat apa yang terbaik untuk pengalaman pengguna. Selain itu, developer dapat menggunakan VM JavaScript untuk menyederhanakan penyematan non-web atau mengembangkan aplikasi mereka tanpa itu.

Untuk mempelajari lebih lanjut, baca Non-Web Embeddings – WebAssembly.

Keamanan Majelis Web

WebAssembly adalah solusi format biner yang menawarkan kinerja mirip asli. Ini berfungsi dengan baik di Web tetapi juga dapat disesuaikan untuk bekerja pada penyematan non-web. Ini membuat WASM tersedia secara luas di seluruh layanan, solusi, dan proses. Namun, ini berarti lebih banyak tantangan keamanan.

Tantangan dan Risiko Keamanan WASM

Meskipun WebAssembly dianggap aman dan efisien, ada beberapa risiko keamanan, termasuk:

• Kotak pasir perakitan Web
• Manajemen memori
• Kebingungan kode
• Pemeriksaan integritas

#1. Kotak Pasir Perakitan Web

WASM dijalankan di dalam browser web, seperti halnya JavaScript. Ini menggunakan Mesin Virtual (VM) yang sama dengan JavaScript. Kotak pasir secara efektif menyediakan lingkungan eksekusi yang aman dan menghalangi apa yang berjalan di bawah tenda.

Jadi, jika kode JavaScript/WebAssembly berisi kode berbahaya, sulit dideteksi karena merupakan kotak hitam. Selain itu, kode WASM dalam format biner yang siap dijalankan; itu bekerja lebih cepat, mempersulit solusi antivirus untuk mencari kode berbahaya apa pun. Misalnya, kode dapat berisi iklan yang tidak diinginkan atau kemampuan untuk mengalihkan pengguna ke situs malware yang tidak diinginkan.

Selain itu, ketergantungan WebAssembly pada JavaScript untuk berjalan di Web juga berarti ia mewarisi kerentanan JavaScript. Itu sebabnya, sebagai pengembang, Anda harus mengikuti tindakan pencegahan dan tindakan keamanan JavaScript saat membuat kode WASM.

#2. Manajemen memori

Manajemen Memori di WASM itu rumit. Pertama, itu tidak secara langsung mengakses memori fisik saat dijalankan dalam VM. Itu sebabnya ia menggunakan memori mesin host.

Kedua, membersihkan memori di WASM membutuhkan proses eksplisit, sedangkan JavaScript membersihkan dirinya sendiri.

Selain itu, saat fungsi WASM mengembalikan output ke JavaScript, ia mengembalikan penunjuk ke posisi dalam ruang memori WASM yang dialokasikan. Jadi, jika memori yang dinyatakan penuh, program WASM bisa macet, merusak pengalaman pengguna. Untuk mencegahnya, programmer perlu menggunakan pembersih untuk men-debug kode mereka atau menggunakan toolchain seperti emscripten.

#3. Kebingungan Kode

Eksekusi kotak pasir WASM membuat kodenya dikaburkan. Selain itu, format biner WASM juga tidak dapat dibaca oleh manusia, sehingga sulit untuk membalikkan rekayasa, yang diperlukan untuk mengidentifikasi kode berbahaya.

Ini membuat kode WebAssembly sulit untuk di-debug karena kurangnya format yang dapat dibaca manusia. Ini membuka banyak celah keamanan, termasuk kemampuan peretas untuk menyembunyikan kode yang mencuri informasi sensitif atau melakukan injeksi kode untuk mengambil alih mesin host.

#4. Pemeriksaan Integritas

Setiap data yang ditransfer melalui Web rentan terhadap tempering data. Misalnya, peretas dapat melakukan serangan man-in-the-middle untuk mengubah nilai data. Ini adalah masalah bagi WASM, mengingat tidak ada cara yang tepat untuk melakukan pemeriksaan integritas.

Namun, ini dapat bekerja dengan JavaScript untuk melakukan pemeriksaan integritas. Cara lain untuk mengidentifikasi potensi kerentanan kode WASM adalah dengan menggunakan alat integrasi seperti Jit. Ini memastikan kode bebas dari aktor jahat dan tidak dapat memengaruhi aplikasi atau infrastruktur cloud di sekitarnya.

Memahami Model Keamanan WASM

WebAssembly memperhatikan keamanan dengan serius. Itu sebabnya, pada dokumen resmi WASM, mereka menyebutkan bahwa model keamanan mereka menangani dua tujuan penting:

1. Pastikan tidak ada modul buggy atau berbahaya yang memengaruhi pengguna
2. Pastikan pengembang dapat memitigasi risiko keamanan apa pun dan membuat aplikasi yang aman sembari memastikan bahwa poin 1 selalu dipertahankan.

Model keamanan WASM mengetahui bahwa aplikasi WebAssembly dijalankan secara independen tanpa dapat keluar dari lingkungan kotak pasirnya. Namun, API dapat membuka jalan untuk menyerang lingkungan host.

Teknik toleran kesalahan lainnya termasuk menjalankan aplikasi secara deterministik dengan ekspektasi terbatas. Dengan memastikan kedua kondisi tersebut, sebagian besar eksekusi aplikasi dianggap aman.

Untuk meningkatkan keamanan, developer harus menerapkan kebijakan asal yang sama untuk aliran informasi. Jika Anda mengembangkan untuk non-web, Anda harus menggunakan model keamanan POSIX. Jika Anda ingin membaca lebih lanjut tentang model keamanannya, lihat: Keamanan – WebAssembly.

Antarmuka Sistem WebAssembly (WASI)

WASI (Antarmuka Sistem WebAssembly) juga memainkan peran penting dalam penyematan non-web WASM karena meningkatkan keamanan. Ini adalah antarmuka sistem modular yang menawarkan karakteristik keamanan dan portabilitas yang menarik.

Bahkan, sekarang menjadi bagian dari Piagam Subkelompok Antarmuka Sistem WebAssembly dan karenanya distandarisasi. Karena WASI, WASM diadopsi secara luas di area komputasi edge/server yang berbeda. Selain itu, WASI menyederhanakan keamanan saat beralih ke penyematan non-web dari lingkungan penyematan web.

Kata Akhir

Portabilitas dan keamanan WebAssembly adalah dua topik besar. Di bagian 3 WebAssembly untuk pemula, kami mencoba menyederhanakan dan memecahnya, terutama untuk pemula.

Selanjutnya, Anda dapat melihat lembar contekan JavaScript untuk pengembang dan pelajar.