PostMessage Vulnerabilities
Last updated
Last updated
AWS ハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCP ハッキングを学び、実践する: HackTricks Training GCP Red Team Expert (GRTE)
PostMessageは、メッセージを送信するために次の関数を使用します:
注意してください、targetOrigin は '*' または https://company.com のようなURLである可能性があります。 第二のシナリオでは、メッセージはそのドメインにのみ送信される（ウィンドウオブジェクトのオリジンが異なっていても）。 ワイルドカードが使用されている場合、メッセージは任意のドメインに送信される可能性があり、ウィンドウオブジェクトのオリジンに送信されます。
このレポートで説明されているように、iframed（X-Frame-Header保護なし）できるページを見つけ、ワイルドカード（*）を使用してpostMessage経由で機密メッセージを送信している場合、iframeのオリジンを変更し、あなたが制御するドメインに機密メッセージを漏洩させることができます。
ページがiframedできるが、targetOriginがワイルドカードではなくURLに設定されている場合、このトリックは機能しません。
addEventListener は、JSが**postMessages**を期待する関数を宣言するために使用する関数です。
次のようなコードが使用されます：
注意すべきは、コードが最初に行うことはオリジンの確認です。これは、受信した情報で何か敏感なこと（パスワードの変更など）を行う場合に非常に重要です。オリジンを確認しないと、攻撃者が被害者に任意のデータをこのエンドポイントに送信させ、被害者のパスワードを変更させることができます（この例では）。
現在のページでイベントリスナーを見つけるために、次のことができます：
JSコードを検索してwindow.addEventListenerや$(window).on（JQueryバージョン）を探す
開発者ツールのコンソールで実行: getEventListeners(window)
ブラウザの開発者ツールでElements --> Event Listenersに移動する
https://github.com/benso-io/postaやhttps://github.com/fransr/postMessage-trackerのようなブラウザ拡張機能を使用する。このブラウザ拡張機能は、すべてのメッセージを傍受し、表示します。
**event.isTrusted**属性は、ユーザーの正当なアクションによって生成されたイベントに対してのみTrueを返すため、安全と見なされます。正しく実装されていればバイパスは難しいですが、セキュリティチェックにおけるその重要性は注目に値します。
**indexOf()**を使用したPostMessageイベントのオリジン検証は、バイパスされる可能性があります。この脆弱性を示す例は次のとおりです：
**search()**メソッドはString.prototype.search()からのもので、正規表現用に設計されています。正規表現以外のものを渡すと、暗黙的に正規表現に変換されるため、このメソッドは潜在的に安全ではありません。これは、正規表現ではドット（.）がワイルドカードとして機能し、特別に作成されたドメインで検証をバイパスできるためです。例えば：
**match()**関数は、search()と同様に正規表現を処理します。正規表現が不適切に構造化されている場合、バイパスされる可能性があります。
**escapeHtml**関数は、文字をエスケープすることで入力をサニタイズすることを目的としています。しかし、新しいエスケープされたオブジェクトを作成するのではなく、既存のオブジェクトのプロパティを上書きします。この動作は悪用される可能性があります。特に、オブジェクトが操作され、その制御されたプロパティがhasOwnPropertyを認識しない場合、escapeHtmlは期待通りに機能しません。以下の例で示されています：
期待される失敗：
エスケープをバイパス：
この脆弱性の文脈において、Fileオブジェクトはその読み取り専用のnameプロパティのために特に悪用されやすいです。このプロパティはテンプレートで使用されるとき、escapeHtml関数によってサニタイズされず、潜在的なセキュリティリスクを引き起こします。
JavaScriptのdocument.domainプロパティは、スクリプトによってドメインを短縮するために設定でき、同じ親ドメイン内での同一オリジンポリシーの適用を緩和します。
%%%%%%を使用してサンドボックス化されたiframe内にウェブページを埋め込む際、iframeのオリジンはnullに設定されることを理解することが重要です。これは、サンドボックス属性とそのセキュリティおよび機能への影響を扱う際に特に重要です。
サンドボックス属性に**allow-popupsを指定すると、iframe内から開かれたポップアップウィンドウは親のサンドボックス制限を継承します。これは、allow-popups-to-escape-sandbox**属性も含まれていない限り、ポップアップウィンドウのオリジンも同様にnullに設定され、iframeのオリジンと一致することを意味します。
したがって、これらの条件下でポップアップが開かれ、iframeからポップアップに**postMessageを使用してメッセージが送信されると、送信側と受信側の両方のオリジンがnullに設定されます。この状況は、e.origin == window.origin**が真（null == null）と評価されるシナリオを引き起こします。なぜなら、iframeとポップアップは同じオリジン値nullを共有しているからです。
詳細については読む：
Bypassing SOP with Iframes - 1メッセージがスクリプトがリスニングしている同じウィンドウから来たかどうかを確認することが可能です（特にブラウザ拡張のコンテンツスクリプトがメッセージが同じページから送信されたかどうかを確認するのに興味深いです）：
メッセージの e.source を null にするには、postMessage を 送信 し、すぐに削除される iframe を作成します。
詳細については、読んでください:
Bypassing SOP with Iframes - 2これらの攻撃を実行するには、理想的には 被害者のウェブページ を iframe 内に配置できる必要があります。しかし、X-Frame-Header のようなヘッダーは、その 動作 を 防ぐ ことがあります。
そのようなシナリオでは、あまりステルス性のない攻撃を使用することができます。脆弱なウェブアプリケーションを新しいタブで開き、それと通信することができます:
以下のページでは、データを送信する前にメインページをブロックし、子でXSSを悪用してデータを漏洩させることで、子iframeに送信された機密のpostmessageデータをどのように盗むことができるかを示しています：
Blocking main page to steal postmessageX-Frame-Headerがないウェブページをiframeできる場合、別のiframeを含む場合、その子iframeの位置を変更することができます。もしそれがワイルドカードを使用して送信されたpostmessageを受信している場合、攻撃者はそのiframeのオリジンを彼が制御するページに変更し、メッセージを盗むことができます：
Steal postmessage modifying iframe locationpostMessageを通じて送信されたデータがJSによって実行されるシナリオでは、ページをiframeし、postMessageを介してエクスプロイトを送信することでプロトタイプ汚染/XSSを悪用できます。
postMessageを通じての非常に良く説明されたXSSのいくつかは、https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.htmlで見つけることができます。
iframeへのpostMessageを通じてプロトタイプ汚染を悪用し、その後XSSを行うエクスプロイトの例：
For more information:
Link to page about prototype pollution
Link to page about XSS
Link to page about client side prototype pollution to XSS
To practice: https://github.com/yavolo/eventlistener-xss-recon
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
