クロスオリジン通信: PostMessage API を使用したセキュリティパターン

現代のウェブでは、アプリケーションが異なるオリジンからのリソースと対話する必要が頻繁にあります。同一オリジンポリシー (SOP) は、スクリプトが異なるオリジンからのリソースにアクセスすることを制限する、極めて重要なセキュリティメカニズムです。しかし、正当な理由でクロスオリジン通信が必要となるシナリオも存在します。postMessage APIはこれを実現するための制御されたメカニズムを提供しますが、その潜在的なセキュリティリスクを理解し、適切なセキュリティパターンを実装することが不可欠です。

同一オリジンポリシー (SOP) の理解

同一オリジンポリシーは、ウェブブラウザにおける基本的なセキュリティ概念です。これは、ウェブページがそのページを提供したドメインとは異なるドメインへのリクエストを行うことを制限します。オリジンは、スキーム (プロトコル)、ホスト (ドメイン)、およびポートによって定義されます。これらのいずれかが異なる場合、オリジンは異なると見なされます。例:

• https://example.com
• https://www.example.com
• http://example.com
• https://example.com:8080

これらはすべて異なるオリジンであり、SOPはこれらの間での直接的なスクリプトアクセスを制限します。

PostMessage APIの紹介

postMessage APIは、クロスオリジン通信のための安全で制御されたメカニズムを提供します。これにより、スクリプトはオリジンに関係なく、他のウィンドウ (例: iframe、新しいウィンドウやタブ) にメッセージを送信できます。受信側のウィンドウはこれらのメッセージを待ち受け、適切に処理することができます。

メッセージを送信するための基本的な構文は次のとおりです:

otherWindow.postMessage(message, targetOrigin);

• otherWindow: ターゲットウィンドウへの参照です (例: window.parent, iframe.contentWindow, または window.open から取得したウィンドウオブジェクト)。
• message: 送信したいデータです。シリアライズ可能な任意のJavaScriptオブジェクト (例: 文字列、数値、オブジェクト、配列) を指定できます。
• targetOrigin: メッセージを送信したいオリジンを指定します。これは極めて重要なセキュリティパラメータです。

受信側では、message イベントをリッスンする必要があります:

window.addEventListener('message', function(event) {
  // ...
});

event オブジェクトには、以下のプロパティが含まれています:

• event.data: 他のウィンドウから送信されたメッセージ。
• event.origin: メッセージを送信したウィンドウのオリジン。
• event.source: メッセージを送信したウィンドウへの参照。

セキュリティリスクと脆弱性

postMessageはSOPの制限を回避する方法を提供しますが、慎重に実装しないと潜在的なセキュリティリスクももたらします。以下は一般的な脆弱性です:

1. ターゲットオリジンの不一致

event.origin プロパティの検証を怠ることは、重大な脆弱性です。受信者がメッセージを盲目的に信頼すると、任意のウェブサイトが悪意のあるデータを送信できてしまいます。メッセージを処理する前に、必ず event.origin が期待されるオリジンと一致することを確認してください。

例 (脆弱なコード):

window.addEventListener('message', function(event) {
  // このような実装はしないでください！
  processMessage(event.data);
});

例 (安全なコード):

window.addEventListener('message', function(event) {
  if (event.origin !== 'https://trusted-origin.com') {
    console.warn('信頼できないオリジンからのメッセージを受信しました:', event.origin);
    return;
  }

  processMessage(event.data);
});

2. データインジェクション

受信したデータ (event.data) を実行可能なコードとして扱ったり、直接DOMに注入したりすると、クロスサイトスクリプティング (XSS) の脆弱性につながる可能性があります。使用する前に、必ず受信データをサニタイズし、検証してください。

例 (脆弱なコード):

window.addEventListener('message', function(event) {
  if (event.origin === 'https://trusted-origin.com') {
    document.body.innerHTML = event.data; // このような実装はしないでください！
  }
});

例 (安全なコード):

window.addEventListener('message', function(event) {
  if (event.origin === 'https://trusted-origin.com') {
    const sanitizedData = sanitize(event.data); // 適切なサニタイズ関数を実装する
    document.getElementById('message-container').textContent = sanitizedData;
  }
});

function sanitize(data) {
    // ここに堅牢なサニタイズ処理を実装します。
    // 例: DOMPurifyや同様のライブラリを使用する
    return DOMPurify.sanitize(data);
}

3. 中間者 (MITM) 攻撃

安全でないチャネル (HTTP) を介して通信が行われる場合、MITM攻撃者はメッセージを傍受し、改ざんする可能性があります。安全な通信のためには、常にHTTPSを使用してください。

4. クロスサイトリクエストフォージェリ (CSRF)

受信者が適切な検証なしに受信メッセージに基づいてアクションを実行する場合、攻撃者はメッセージを偽造して受信者を騙し、意図しないアクションを実行させる可能性があります。メッセージに秘密のトークンを含め、受信側でそれを検証するなど、CSRF保護メカニズムを実装してください。

5. targetOriginでのワイルドカードの使用

targetOriginを*に設定すると、どのオリジンでもメッセージを受信できるようになります。これはオリジンベースのセキュリティの目的を無効にするため、絶対に必要な場合を除き避けるべきです。*を使用しなければならない場合は、メッセージ認証コード (MAC) など、他の強力なセキュリティ対策を実装してください。

例 (これは避けるべき):

otherWindow.postMessage(message, '*'); // 絶対に必要な場合を除き、'*'の使用は避けてください

セキュリティパターンとベストプラクティス

postMessageに関連するリスクを軽減するために、以下のセキュリティパターンとベストプラクティスに従ってください:

1. 厳格なオリジン検証

受信側で常に event.origin プロパティを検証してください。信頼できるオリジンの事前定義済みリストと比較します。比較には厳密等価 (===) を使用してください。

2. データのサニタイズと検証

postMessage を通じて受信したすべてのデータは、使用する前にサニタイズし、検証してください。データがどのように使用されるかに応じて、適切なサニタイズ技術 (例: HTMLエスケープ、URLエンコーディング、入力検証) を使用します。HTMLのサニタイズにはDOMPurifyのようなライブラリを使用してください。

3. メッセージ認証コード (MAC)

メッセージの完全性と真正性を保証するために、メッセージにメッセージ認証コード (MAC) を含めます。送信者は共有秘密鍵を使用してMACを計算し、メッセージに含めます。受信者は同じ共有秘密鍵を使用してMACを再計算し、受信したMACと比較します。これらが一致すれば、メッセージは真正であり、改ざんされていないと見なされます。

例 (HMAC-SHA256を使用):

// 送信側
async function sendMessage(message, targetOrigin, sharedSecret) {
  const encoder = new TextEncoder();
  const data = encoder.encode(JSON.stringify(message));
  const key = await crypto.subtle.importKey(
    "raw",
    encoder.encode(sharedSecret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["sign"]
  );
  const signature = await crypto.subtle.sign("HMAC", key, data);
  const signatureArray = Array.from(new Uint8Array(signature));
  const signatureHex = signatureArray.map(b => b.toString(16).padStart(2, '0')).join('');

  const securedMessage = {
    data: message,
    signature: signatureHex
  };

  otherWindow.postMessage(securedMessage, targetOrigin);
}

// 受信側
async function receiveMessage(event, sharedSecret) {
  if (event.origin !== 'https://trusted-origin.com') {
    console.warn('信頼できないオリジンからのメッセージを受信しました:', event.origin);
    return;
  }

  const securedMessage = event.data;
  const message = securedMessage.data;
  const receivedSignature = securedMessage.signature;

  const encoder = new TextEncoder();
  const data = encoder.encode(JSON.stringify(message));
  const key = await crypto.subtle.importKey(
    "raw",
    encoder.encode(sharedSecret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["verify"]
  );
  const signature = await crypto.subtle.sign("HMAC", key, data);
  const signatureArray = Array.from(new Uint8Array(signature));
  const signatureHex = signatureArray.map(b => b.toString(16).padStart(2, '0')).join('');

  if (signatureHex === receivedSignature) {
    console.log('メッセージは真正です！');
    processMessage(message); // メッセージの処理を続行
  } else {
    console.error('メッセージ署名の検証に失敗しました！');
  }
}

重要: 共有秘密鍵は安全に生成・保管されなければなりません。コード内にキーをハードコーディングすることは避けてください。

4. ナンスとタイムスタンプの使用

リプレイ攻撃を防ぐために、メッセージにユニークなナンス (一度だけ使用される数値) とタイムスタンプを含めます。受信者は、そのナンスが以前に使用されていないこと、およびタイムスタンプが許容可能な時間枠内であることを検証できます。これにより、攻撃者が以前に傍受したメッセージを再送するリスクが軽減されます。

5. 最小権限の原則

他のウィンドウには、必要最小限の権限のみを付与してください。例えば、他のウィンドウがデータの読み取りしか必要としない場合、データの書き込みを許可しないでください。最小権限の原則を念頭に置いて通信プロトコルを設計してください。

6. コンテンツセキュリティポリシー (CSP)

コンテンツセキュリティポリシー (CSP) を使用して、スクリプトがロードできるソースやスクリプトが実行できるアクションを制限します。これは、postMessage データの不適切な処理から生じる可能性のあるXSS脆弱性の影響を軽減するのに役立ちます。

7. 入力検証

受信データの構造と形式を常に検証してください。明確なメッセージ形式を定義し、受信データがこの形式に準拠していることを確認します。これにより、予期しない動作や脆弱性を防ぐことができます。

8. 安全なデータシリアライゼーション

メッセージのシリアライズとデシリアライズには、JSONなどの安全なデータシリアライゼーション形式を使用してください。eval() や Function() のようにコード実行を許可する形式の使用は避けてください。

9. メッセージサイズの制限

postMessage を通じて送信されるメッセージのサイズを制限してください。大きなメッセージは過剰なリソースを消費し、サービス拒否 (DoS) 攻撃につながる可能性があります。

10. 定期的なセキュリティ監査

コードの定期的なセキュリティ監査を実施して、潜在的な脆弱性を特定し、対処してください。postMessage の実装に特に注意を払い、すべてのセキュリティベストプラクティスが遵守されていることを確認してください。

シナリオ例: iframeと親ページ間の安全な通信

https://iframe.example.comでホストされているiframeが、https://parent.example.comでホストされている親ページと通信する必要があるシナリオを考えます。iframeは、処理のためにユーザーデータを親ページに送信する必要があります。

Iframe (https://iframe.example.com):

// 共有秘密鍵を生成 (安全な鍵生成方法に置き換えてください)
const sharedSecret = 'YOUR_SECURE_SHARED_SECRET';

// ユーザーデータを取得
const userData = {
  name: 'John Doe',
  email: 'john.doe@example.com'
};

// ユーザーデータを親ページに送信
async function sendUserData(userData) {
  const encoder = new TextEncoder();
  const data = encoder.encode(JSON.stringify(userData));
  const key = await crypto.subtle.importKey(
    "raw",
    encoder.encode(sharedSecret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["sign"]
  );
  const signature = await crypto.subtle.sign("HMAC", key, data);
  const signatureArray = Array.from(new Uint8Array(signature));
  const signatureHex = signatureArray.map(b => b.toString(16).padStart(2, '0')).join('');

  const securedMessage = {
    data: userData,
    signature: signatureHex
  };
  parent.postMessage(securedMessage, 'https://parent.example.com');
}

sendUserData(userData);

親ページ (https://parent.example.com):

// 共有秘密鍵 (iframeの鍵と一致する必要があります)
const sharedSecret = 'YOUR_SECURE_SHARED_SECRET';

window.addEventListener('message', async function(event) {
  if (event.origin !== 'https://iframe.example.com') {
    console.warn('信頼できないオリジンからのメッセージを受信しました:', event.origin);
    return;
  }

  const securedMessage = event.data;
  const userData = securedMessage.data;
  const receivedSignature = securedMessage.signature;

  const encoder = new TextEncoder();
  const data = encoder.encode(JSON.stringify(userData));
  const key = await crypto.subtle.importKey(
    "raw",
    encoder.encode(sharedSecret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["verify"]
  );
  const signature = await crypto.subtle.sign("HMAC", key, data);
  const signatureArray = Array.from(new Uint8Array(signature));
  const signatureHex = signatureArray.map(b => b.toString(16).padStart(2, '0')).join('');


  if (signatureHex === receivedSignature) {
    console.log('メッセージは真正です！');
    // ユーザーデータを処理
    console.log('ユーザーデータ:', userData);
  } else {
    console.error('メッセージ署名の検証に失敗しました！');
  }
});

重要な注意点:

• YOUR_SECURE_SHARED_SECRETを、安全に生成された共有秘密鍵に置き換えてください。
• 共有秘密鍵は、iframeと親ページの両方で同じでなければなりません。
• この例では、メッセージ認証にHMAC-SHA256を使用しています。

結論

postMessage APIは、ウェブアプリケーションでクロスオリジン通信を可能にする強力なツールです。しかし、潜在的なセキュリティリスクを理解し、これらのリスクを軽減するために適切なセキュリティパターンを実装することが不可欠です。このガイドで概説したセキュリティパターンとベストプラクティスに従うことで、postMessageを安全に使用して、堅牢で安全なウェブアプリケーションを構築できます。

常にセキュリティを最優先し、ウェブ開発の最新のセキュリティベストプラクティスを常に把握しておくことを忘れないでください。アプリケーションが潜在的な脆弱性から保護されていることを確認するために、コードとセキュリティ構成を定期的に見直してください。