WebAssemblyの安全性は？ WebAssembly特有の5つのセキュリティ上の懸念

WebAssembly（Wasmとも呼ばれます）は、Webブラウザーの仮想マシン（VM）で実行される、移植可能な低レベルのバイナリーコード命令形式です。さまざまなプログラミング言語で高パフォーマンスなコードを記述でき、JavaScriptと並行して実行できます。

開発者は、複雑なアルゴリズムの高速化、ゲームやマルチメディアアプリケーションの実現、信頼できないコードを実行するための安全なサンドボックス環境の提供を可能にするWebAssemblyを積極的に活用しています。しかし、WebAssemblyを導入する前に、セキュリティへの影響とリスクを軽減する方法を検討することが重要です。

WebAssemblyに関する主なセキュリティ上の懸念

開発者は、さまざまな最新のプログラミング言語をWebAssemblyにコンパイルできます。しかし、その利点がある一方で、WebAssemblyは従来のセキュリティ対策を回避し、ブラウザー上で悪意のあるコードを実行する可能性があります。

オープンソースのWebフレームワークBlazorを使ってサンプルアプリを構築し、WebAssembly特有のセキュリティ上の問題を詳しく見ていきましょう。Blazorを使うと、Webページの作成にJavaScriptではなくC#コードを使用できます。C#コードは動的リンクライブラリ（DLL）とWebAssembly（.wasm）ファイルにビルドされ、クライアントのブラウザー上で実行されます。

前提条件

このチュートリアルを始める前に、以下を用意してください。

• Visual StudioまたはVS Codeをダウンロードしてインストールします。WebAssemblyコードの作成と実行に使用する統合開発環境（IDE）です。VS Codeを選んだ場合は、続けて.NET SDKとC# extensionをダウンロードしてインストールしてください。

• Visual Studio extensionまたはVS Code用のSnyk extensionをインストールします。このプラグインでWebAssemblyコードをスキャンし、セキュリティ分析を実行できます。

• サンプルプロジェクトをダウンロードします。

サンプルプロジェクトを実行する

IDEにVisual Studioを選んだ場合は、Visual Studio Installerを開き、.NET WebAssembly Build Toolsオプションにチェックを入れます。

Tools > Options > Snykメニューを開き、General Settingsを選択します。次に、Connect Visual Studio to Snyk.ioボタンをクリックします。

IDEにVS Codeを選んだ場合は、左側のツールバーにあるSnykアイコンをクリックします。次に、Trust workspace and connectをクリックします。

Visual StudioまたはVS Codeでプログラムを実行してサンプルアプリを起動します。次のスクリーンショットのように、「Human Resources」というタイトル、画像、テキストが表示されます。

セキュリティ上の懸念 #1：WebAssemblyモジュールの分離

この技術を使用するWebアプリケーションのセキュリティを維持するには、WebAssemblyモジュールを分離する必要があります。モジュール同士、およびホスト環境から分離することで、それぞれが独立して動作し、ほかのモジュールやホストアプリケーションの挙動に干渉しなくなります。信頼できないコードを実行する際、モジュールの分離は不可欠です。悪意のあるコードが機密データやリソースにアクセスするのを防ぎます。

モジュール分離を実装するためのベストプラクティスは、サンドボックス化とコンパートメント化の2つです。

サンドボックス化では、各モジュールを個別の隔離された環境に配置し、ホストシステムやほかのモジュールへのアクセスを制限します。下の画像は、2つのWebAssemblyモジュール（FinanceとHuman Resources）を含むプロジェクトを示しています。プロジェクトをコンパイルしてWebブラウザーにデプロイすると、WebAssemblyモジュールはホストランタイムから分離されたサンドボックス環境内で実行されます。

コンパートメント化では、ホストアプリケーションとそのモジュールを個別のコンパートメントに分割します。それぞれが独自のリソースとアクセス権限を持ちます。

サンドボックス化とコンパートメント化はいずれも、ホストシステムやほかのモジュールのセキュリティを損なうことなく信頼できないコードを実行できる、安全な環境を作り出します。

次に、Snyk Visual Studio Code extensionを使って、WebAssemblyコードに脆弱性がないか確認します。Extensions > Snykメニューを開き、Scanをクリックします。

Snykはファイルを分析し、既知のWebAssemblyのコード品質に関する問題や、オープンソースおよびコードセキュリティに関連する脆弱性を特定します。問題や脆弱性が見つかった場合は、詳細と修正方法の推奨事項を提示します。

セキュリティ上の懸念 #2：WebAssemblyのリニアメモリモデル

リニアメモリモデルは、単一の連続したアドレス空間を使ってメモリを構成するアドレス指定方式です。この方式では、処理装置がメモリ上の位置に直接、順次アクセスできます。下の画像は、JavaScriptとWebAssemblyのコードで共有されるオブジェクトが、リニアメモリ上の領域を使用している様子を示しています。

WebAssemblyのリニアメモリモデルでは、従来の配列と同様に、モジュールが連続したメモリブロックを割り当ててアクセスできます。このモデルはWebAssemblyアプリケーションのメモリを高速かつ効率的に管理できる一方で、セキュリティリスクも生じさせます。

たとえば、モジュールが割り当てられた範囲外のメモリにアクセスすると、ほかのモジュールやホストシステムのメモリを破損する可能性があります。その結果、クラッシュやセキュリティ侵害につながる恐れがあります。

WebAssemblyアプリケーションのリニアメモリモデルに関連するセキュリティリスクを軽減するには、次のベストプラクティスに従ってください。

• 境界チェックを使用して、モジュールが割り当てられた範囲内のメモリにのみアクセスするようにします。

• メモリ破損の脆弱性を防ぐため、安全でない関数の使用を避けます。

• アドレス空間配置のランダム化（ASLR）やデータ実行防止（DEP）などのメモリ保護機構を実装します。

セキュリティ上の懸念 #3：WebAssemblyのJITコンパイル

WebAssemblyのジャストインタイム（JIT）コンパイルでは、Wasmコードを事前ではなく実行時にマシンコードへコンパイルします。この処理は大幅なパフォーマンス向上をもたらす一方で、潜在的なセキュリティリスクも生みます。

JITコンパイルは動的に行われるため、攻撃の検出と防止が難しくなります。攻撃者はコンパイル処理に悪意のあるコードを注入し、ホスト環境で実行させることができます。たとえば、ハッカーは高水準プログラミング言語で無害に見える定数を作成できます。

var a = (0x11223344^0x44332211^0x44332211^ ...);

次に、JITコンパイラーがその命令を一連のネイティブx86コード命令に変換します。

0000:  b8 44 33 22 11      mov $0x11223344,%eax    mov eax,0x11223344
0005:  35 11 22 33 44      xor $0x44332211,%eax    xor eax,0x44332211
000a:  35 11 22 33 44      xor $0x44332211,%eax    xor eax,0x44332211

攻撃者は既知のバグを利用して、実行ポインターをアドレス0001に移動させます。これにより、上記の定数に巧妙に仕込まれた悪意のある命令群が実行されます。

WebAssemblyアプリケーションにおけるJITコンパイルのセキュリティリスクを軽減するには、コンパイル処理を管理するための次のベストプラクティスを実践してください。

• 事前コンパイル（AOT）を使用して、実行前にWasmコードをマシンコードへコンパイルします。この方法により、動的コンパイルに伴うリスクを排除できます。

• JITコンパイラーの既知の脆弱性に対するセキュリティパッチを適用します。

セキュリティ上の懸念 #4：Web APIとクロスサイトスクリプティング（XSS）

WebAssemblyはWeb APIと連携し、Webブラウザー、サーバー、その他のプラットフォームからリソースやデータにアクセスできます。しかし、こうした連携によってクロスサイトスクリプティング（XSS）攻撃などのセキュリティリスクが生じることがあります。XSS攻撃では、ハッカーがWebページやアプリケーションに悪意のあるコードを注入します。その後、ユーザーが意図せずそのコードを実行し、不正アクセスやデータ窃取につながる恐れがあります。

WebAssemblyアプリケーションでXSS攻撃のリスクを軽減するには、入力検証と出力エンコードのベストプラクティスを実践してください。

• 入力検証では、ユーザー入力に悪意のあるコードや文字が含まれていないかを確認し、特定の基準を満たさない入力を拒否します。

• 出力エンコードでは、悪意のあるコードの実行を防ぐため、ユーザー入力や出力をエンコードします。

また、HTTPSを使用してサーバーとクライアント間でやり取りされるデータを暗号化し、攻撃者による通信中のデータの傍受や改ざんを防ぎます。

セキュリティ上の懸念 #5：安全でないWebAssemblyコンテンツ配信

WebAssemblyアプリケーションでは、安全なコンテンツ配信が不可欠です。信頼できる経路を通じて、真正で改変されていないコードをユーザーに届ける必要があります。安全でないコンテンツ配信は、中間者（MITM）攻撃やコードの改ざんなどのセキュリティリスクを招く可能性があります。

MITM攻撃では、サーバーとクライアント間でコードが送信される際に、攻撃者がそれを傍受して改ざんします。この手法により、攻撃者はアプリケーションに悪意のあるコードを注入でき、ブラウザーやWasmランタイムがそれを実行する可能性があります。

WebAssemblyアプリケーションのコンテンツ配信を保護するには、次のベストプラクティスに従ってください。

• HTTPSを使用してサーバーとクライアント間のデータを暗号化し、安全で改ざんされていないコードの送信を確保します。

• チェックサムやデジタル署名などのコンテンツ整合性チェックを使用して、コードの真正性を検証します。

• アクセス制御機構を実装し、許可されたユーザーのみにコードへのアクセスを制限します。

安全に組み立てる

開発者は、Webブラウザー内で高パフォーマンスなアプリケーションを作成できるWebAssemblyを積極的に採用しています。しかし、WebAssemblyには大きな利点がある一方で、重大なセキュリティ上の懸念も伴います。

この記事では、WebAssemblyに関するいくつかのセキュリティ上の問題を取り上げました。モジュールの分離が不適切であること、リニアメモリモデルの保護が不十分であること、JITコンパイラーの脆弱性、クロスサイトスクリプティング攻撃、安全でないWebAssemblyコンテンツ配信です。

幸い、WebAssemblyがもたらす脆弱性は、いくつかのベストプラクティスで軽減できます。こうしたセキュリティ対策に従うことで、ユーザーを保護し、WebAssemblyアプリを安全に保てます。

システムとユーザーを保護するには、WebAssemblyに影響を及ぼす最新のセキュリティ脅威を常に把握することも重要です。開発ツールも役立ちます。たとえば、Snykプラットフォームは既知の脆弱性を幅広く収録し、リスクを軽減するための実用的なインサイトを提供します。Snyk CodeやSnyk Open Sourceなどのツールを使えば、コードセキュリティの問題をすばやく検出して解決できます。今すぐ無料アカウントを作成しましょう。