博士

やあ、ロボ子。今日はMicrosoftのpostMessageに関するセキュリティのお話のじゃ。

ロボ子

postMessage、ですか。異なるオリジン間で安全に通信するためのものですよね。

博士

そうじゃ、ロボ子。でも、設定を間違えると大変なことになるのじゃ。トークンを盗まれたり、XSS攻撃を受けたり、権限を奪われたりする可能性があるのじゃぞ！

ロボ子

それは怖いですね。具体的には、どのようなミスが起こりやすいのでしょうか？

博士

一番多いのは、送信元や受信元のオリジン検証を怠ることじゃな。例えば、`targetOrigin`に`*`を使ってしまうと、誰でもメッセージを受け取れてしまうのじゃ。

ロボ子

記事にも、Bing Travelやweb.kusto.windows.netの事例が挙げられていますね。どちらも`targetOrigin`に`*`を使用していたために、脆弱性が生まれたと。

博士

その通り！Bing Travelではアクセストークンが盗まれる可能性があり、web.kusto.windows.netでは`user_impersonation`スコープを持つトークンが漏洩する危険があったのじゃ。

ロボ子

Microsoft 365、Azure、Dynamics 365全体で、テナント固有ではなくサービスレベルのオリジン検証を使用していることも問題だと指摘されていますね。

博士

そうじゃ。攻撃者は、信頼されたドメインでのXSS、放置されたドメインの乗っ取り、設計によるカスタムコードの悪用といった手口で、postMessageの脆弱性を悪用してくるのじゃ。

ロボ子

Microsoft TeamsアプリにおけるpostMessageの脆弱性についても言及されていますね。`isFullTrust`がtrueに設定され、`validDomains`リストが広すぎる場合に発生しやすいと。

博士

Power Virtual Agents（現Microsoft Copilot Studio）では、実際に0クリックXSSが発生したのじゃ。`isFullTrust: true`と広範な`validDomains`リストが悪用されたのじゃな。

ロボ子

CVSSスコア9.3/8.1で「Critical」と評価されたのですね。かなり深刻な脆弱性だったのですね。

博士

Microsoftは、アプリ名の変更、`validDomains`リストからのワイルドカードエントリの削除、`isFullTrust`設定の見直しといった対策を講じたようじゃな。

ロボ子

私たちも、アプリマニフェストを監査し、`validDomains`を必要最小限に制限したり、`isFullTrust: true`の使用を制限したりする必要があるのですね。

博士

`postMessage`リスナーで`event.origin`を厳密に検証することも重要じゃ。未使用または放置されたドメインを削除したり、CodeQLと動的解析を活用したりするのも有効じゃぞ。

ロボ子

セキュア・バイ・デフォルトのアプローチも重要ですね。Microsoft自身も、ワイルドカードドメインのエントリの削除やオリジンの検証の強化に取り組む必要があると。

博士

そうじゃ。私たちも、CSPヘッダーを適用したり、独自のアプリマニフェストを監査したり、SDLプラクティスの一環としてXSS脆弱性の存在をチェックしたりする必要があるのじゃ。

ロボ子

postMessageは便利ですが、セキュリティリスクも考慮して慎重に扱う必要があるということですね。

博士

その通りじゃ、ロボ子！ところで、ロボ子はpostMessageで何を伝えたい？私は、今夜の夕食は何にするか、ロボ子に聞きたいのじゃ！

ロボ子

博士、セキュリティの話から夕食の話題に飛躍しすぎです！でも、今夜は手作りハンバーグはいかがでしょう？