初心者向け WebAssembly パート 3: WASM の移植性とセキュリティのしくみ

公開: 2023-01-05

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

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

  • 初心者のための WebAssembly – パート 1: WASM の紹介
  • 初心者のための WebAssembly – パート 2: 目標、主要な概念、および使用例

始めましょう。

WebAssembly の移植性

WebAssembly の移植性により、Web の準備が整います。 実際、WASM をポータブルなサンドボックス プラットフォームとして定義できます。

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

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

  • 局所的で限定的で非決定的な環境。
  • 特定の実行環境の特徴
  • WASM Web および非 Web 移植性

局所的、限定的、非決定的

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

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

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

特定の実行環境の特性

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 Community Group と W3C WebAssembly Working Group は、その標準化に取り組んでいます。 つまり、これらの要件は将来変更される可能性があります。

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 コードはすぐに実行できるバイナリ形式です。 より高速に実行されるため、ウイルス対策ソリューションが悪意のあるコードを探すのが難しくなります。 たとえば、コードには不要な広告や、ユーザーを不要なマルウェア サイトにリダイレクトする機能が含まれている可能性があります。

感染-ブラウザ-クリプトマイニング-WASM

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

＃2。 メモリ管理

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

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

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

wasm-リニアメモリ

＃3。 コードの難読化

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

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

＃4。 整合性チェック

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

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

中間者攻撃

WASM セキュリティ モデルについて

WebAssembly はセキュリティを真剣に考えています。 そのため、WASM の公式ドキュメントで、彼らのセキュリティ モデルは 2 つの重要な目標に対応していると述べています。

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

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

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

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

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

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

実際、それは現在 WebAssembly System Interface Subgroup Charter の一部であり、標準化されています。 WASI により、WASM はさまざまなエッジ/サーバー コンピューティング分野で広く採用されています。 また、WASI は、Web 埋め込み環境から非 Web 埋め込み環境に移行する際のセキュリティを簡素化します。

最後の言葉

WebAssembly の移植性とセキュリティは、2 つの大きなトピックです。 初心者向け WebAssembly のパート 3 では、特に初心者向けに、単純化して分解しようとしました。

次に、開発者と学習者向けの JavaScript チート シートをご覧ください。