初心者のための WebAssembly パート 3: WASM の移植性とセキュリティの仕組み

この初心者向けガイドで、WebAssembly (WASM) の移植性とセキュリティ モデルがどのように機能するかを確認してください。

どちらも高度な WebAssembly (WASM) トピックです。 WebAssembly for Beginner シリーズの前の 2 つのトピックを読むことをお勧めします。

• 初心者のための WebAssembly – パート 1: WASM の概要
• 初心者のための WebAssembly – パート 2: 目標、重要な概念、使用例

始めましょう。

WebAssembly の移植性

WebAssembly は移植性があるため、Web にすぐに使用できます。実際、WASM をポータブルなサンドボックス プラットフォームとして定義できます。

さらに、そのバイナリ形式により、さまざまな命令セット アーキテクチャおよびオペレーティング システムで実行できます。これは、WASM を Web 上だけでなく Web 以外でも使用できることを意味します。

WASM の移植性を理解するために、以下について説明します。

• ローカルで限定された非決定的な環境。
• 特定の実行環境の特性
• WASM Web および非 Web の移植性

ローカル、限定的、非決定的

WASM には、効率的な実行と、ローカルで限定された非決定性の適切な環境が必要です。非決定性とは、同じ入力に対してもアルゴリズム/コンパイラー/環境が異なる動作や結果を出力することを指定するコンピューティングです。これは決定論的アルゴリズムの逆です。

他の 2 つの側面、 limited と local は 、非決定的実行に関連付けられています。非決定的実行を機能させるには、「 限定的 」で明確に定義されたユースケースが必要です。

また、これらの実行は「 ローカル 」であり、環境外には影響しません。詳細については 、WebAssembly ドキュメントの公式の非決定性を 読んでください。

特定の実行環境の特性

WebAssembly を移植可能にするために、実行環境が次の特性を備えていることを前提としています。

• バイト メモリ粒度のアドレス指定可能性と 8 ビット バイト。
• 32 ビットの 2 の補数の符号付き整数。オプションで 64 ビット。
• ソフトウェア エミュレーションは、非整列メモリ アクセスまたは信頼性の高いトラップによって可能です。
• IEEE 754-2008 で定義されている 32 ビットおよび 64 ビット浮動小数点のサポート。
• すべてのスレッドを順方向に実行することを保証します。
• 64 ビット アクセスの場合、wasm64 はロックフリーのアトミック メモリ オペレーターを提供する必要があります。
• ロックフリーのアトミック メモリ オペレータには、8、16、および 32 ビット アクセスが含まれます。
• wasm64 は、64 ビットのインデックスまたはポインターを備えた 4 GiB を超えるリニア メモリをサポートします。
• リトルエンディアンのバイトオーダー。

Chrome、Edge、Firefox、WebKit などの主要なブラウザはすべて、これらの環境要件をすべてサポートしています。

さらに、WebAssembly は急速に進化しています。 WASM コミュニティ グループと W3C WebAssembly ワーキング グループは、その標準化に向けて取り組んでいます。つまり、これらの要件は将来変更される可能性があります。

WASM Web および非 Web の移植性

WebAssembly の主な目的は、Web および Web 以外での移植性とネイティブ パフォーマンスを提供することです。このセクションでは、WASM がそれをどのように実現するかを見ていきます。

#1. ウェブ埋め込み

WASM は、Web のセキュリティ モデル、Web ポータビリティ、Web API などの Web エコシステムとうまく統合します。さらに、将来的に創造的な開発を行うための十分な余地がなければなりません (WebAssembly for Beginners – Part 2 を読んで、その目標を理解してください)

では、WASM はどのようにして Web との互換性を実現するのでしょうか? JavaScript API を利用しているため、開発者は JavaScript を使用して WebAssembly モジュールを簡単にコンパイルできます。また、コンパイラー モジュールの保存と取得、コンパイラー モジュールからのインポートの管理、メモリの管理なども行います。

WASM が高レベルの Web 互換性を実現する方法の詳細については、「 Web 埋め込み – WebAssembly」 を参照してください。

#2. 非 Web 埋め込み

前述したように、WASM は非 Web 環境でも動作します。開発者または企業は、高パフォーマンスのアプリケーションを作成したり、パフォーマンスの調整が必要なアプリケーションのセクションを作成したりできます。たとえば、IoT デバイス、データセンター サーバー、デスクトップ/モバイル アプリで使用できます。

非 Web アプリケーションは Web API を使用できないため、 WASM の動的リンク に依存します。また、機能の複数のバリエーションをテストして、ユーザー エクスペリエンスにとって最適なものを確認するソフトウェア開発プロセスである機能テストを使用する必要もあります。さらに、開発者は JavaScript VM を使用して、Web 以外の埋め込みを簡素化したり、JavaScript VM を使用せずにアプリを開発したりできます。

詳細については、 「非 Web 埋め込み – WebAssembly」 を参照してください。

WebAssembly のセキュリティ

WebAssembly は、ネイティブのようなパフォーマンスを提供するバイナリ形式のソリューションです。 Web ではうまく機能しますが、Web 以外の埋め込みでも動作するように微調整することもできます。これにより、WASM はサービス、ソリューション、プロセス全体で広く利用できるようになります。ただし、これはセキュリティ上の課題が増えることを意味します。

WASM セキュリティの課題とリスク

WebAssembly は安全で効率的であると考えられていますが、次のような複数のセキュリティ リスクが伴います。

• WebAssembly サンドボックス
• メモリ管理
• コードの難読化
• 整合性チェック

#1. WebAssembly サンドボックス

WASM は、JavaScript と同様に Web ブラウザ内で実行されます。 JavaScript と同じ仮想マシン (VM) を利用します。サンドボックスは安全な実行環境を効果的に提供し、内部で実行されているものを妨げます。

したがって、JavaScript/WebAssembly コードに悪意のあるコードが含まれている場合、それはブラック ボックスであるため、検出するのは困難です。また、WASM コードはすぐに実行できるバイナリ形式です。実行速度が速くなるため、ウイルス対策ソリューションが悪意のあるコードを探すのが難しくなります。たとえば、コードには、不要な広告や、ユーザーを不要なマルウェア サイトにリダイレクトする機能が含まれる可能性があります。

さらに、WebAssembly は Web 上で実行するために JavaScript に過度に依存しているため、JavaScript の脆弱性が引き継がれます。そのため、開発者は WASM をコーディングする際に JavaScript の安全上の注意事項と対策に従う必要があります。

#2. メモリ管理

WASM でのメモリ管理は注意が必要です。まず、VM 内で実行されるため、物理メモリに直接アクセスしません。そのため、ホスト マシンのメモリが使用されます。

第 2 に、WASM でメモリをクリーンアップするには明示的なプロセスが必要ですが、それに比べて、JavaScript は自動的にクリーンアップします。

さらに、WASM 関数が出力を JavaScript に返すとき、割り当てられた WASM メモリ空間内の位置へのポインタを返します。したがって、宣言されたメモリがいっぱいになると、WASM プログラムがクラッシュし、ユーザー エクスペリエンスが台無しになる可能性があります。これを防ぐには、プログラマーはサニタイザーを使用してコードをデバッグするか、 emscripten などのツールチェーンを使用する必要があります。

#3. コードの難読化

WASM のサンドボックス実行により、コードが難読化されます。さらに、WASM バイナリ形式も人間が判読できないため、悪意のあるコードを特定するために必要なリバース エンジニアリングが困難になります。

これらにより、WebAssembly コードには人間が判読できる形式がないため、デバッグが困難になります。これにより、機密情報を盗むコードを隠したり、ホスト マシンを乗っ取るコード インジェクションを実行したりするハッカーの能力など、多くのセキュリティの抜け穴が開かれます。

#4. 整合性チェック

Web 経由で転送されるデータはすべて、データ改ざんに対して脆弱です。たとえば、ハッカーは中間者攻撃を実行してデータ値を変更する可能性があります。 WASM には整合性チェックを行う適切な方法がないため、これは WASM にとって問題です。

ただし、JavaScript と連携して整合性チェックを実行できます。 WASM コードの潜在的な脆弱性を特定するもう 1 つの方法は、Jit などの統合ツールを使用することです。これにより、コードに悪意のある者が含まれていないことが保証され、アプリや周囲のクラウド インフラストラクチャに影響を与えることができなくなります。

WASM セキュリティ モデルを理解する

WebAssembly はセキュリティを重視しています。そのため、WASM の公式ドキュメントでは、セキュリティ モデルが次の 2 つの重要な目標を達成していると述べられています。

1. バグのあるモジュールや悪意のあるモジュールがユーザーに影響を与えないようにする
2. 開発者がポイント 1 を常に維持しながら、セキュリティ リスクを軽減し、安全なアプリケーションを作成できるようにします。

WASM セキュリティ モデルは、WebAssembly アプリがサンドボックス環境から抜け出すことができない一方で、独立して実行されることを認識しています。ただし、API はホスト環境を攻撃する手段を開く可能性があります。

もう 1 つのフォールト トレラント手法には、限られた期待のもとでアプリを決定論的に実行することが含まれます。両方の条件を確保することで、ほとんどのアプリの実行は安全であると見なされます。

セキュリティを向上させるために、開発者は情報フローに対して同一生成元ポリシーを適用する必要があります。非 Web 向けに開発している場合は、POSIX セキュリティ モデルを使用する必要があります。そのセキュリティ モデルについて詳しく知りたい場合は、 「セキュリティ – WebAssembly」 を参照してください。

WebAssembly システム インターフェイス (WASI)

WASI (WebAssembly System Interface) も、セキュリティを向上させるため、WASM 非 Web 埋め込みにおいて重要な役割を果たします。これは、エキサイティングなセキュリティ特性と移植性を提供するモジュラー システム インターフェイスです。

実際、これは現在 WebAssembly システム インターフェイス サブグループ憲章 の一部となっており、標準化されています。 WASI のおかげで、WASM はさまざまなエッジ/サーバー コンピューティング分野で広く採用されています。また、WASI は、Web 埋め込み環境から非 Web 埋め込み環境に移行する際のセキュリティを簡素化します。

最後の言葉

WebAssembly の移植性とセキュリティは 2 つの大きなトピックです。初心者向け WebAssembly のパート 3 では、特に初心者向けに、WebAssembly を簡略化し、細分化することに努めました。

次に、開発者と学習者向けの JavaScript チートシートを確認してください。