PostMessage Vulnerabilities
PostMessageの脆弱性
WhiteIntelは、ダークウェブを活用した検索エンジンで、企業やその顧客がスティーラーマルウェアによって侵害されていないかをチェックする無料機能を提供しています。
WhiteIntelの主な目標は、情報窃取マルウェアによるアカウント乗っ取りやランサムウェア攻撃と戦うことです。
彼らのウェブサイトをチェックして、無料でエンジンを試すことができます:
PostMessageを送信
PostMessageは、次の関数を使用してメッセージを送信します:
targetOriginは'*'または_https://company.com_のようなURLであることに注意してください。第2のシナリオでは、メッセージはそのドメインにのみ送信できます(ウィンドウオブジェクトのオリジンが異なっていても)。ワイルドカードが使用されると、メッセージは任意のドメインに送信され、ウィンドウオブジェクトのオリジンに送信されます。
iframeとtargetOriginでのワイルドカード攻撃
このレポートで説明されているように、X-Frame-Header保護がないページを見つけ、ワイルドカード(*)を使用してpostMessageを介して機密メッセージを送信している場合、iframeのoriginを変更して、機密メッセージを自分が制御するドメインに漏洩させることができます。ページがiframedであっても、targetOriginがURLに設定されていてワイルドカードではない場合、このトリックは機能しません。
addEventListenerの悪用
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
を返すため、セキュアと見なされます。正しく実装されていればバイパスするのは難しいですが、セキュリティチェックにおける重要性は顕著です。PostMessageイベントでのオリジン検証に**
indexOf()
**を使用することはバイパスされる可能性があります。この脆弱性を示す例は次のとおりです:
String.prototype.search()
の**search()
**メソッドは正規表現を想定しており、文字列ではありません。正規表現以外のものを渡すと、暗黙のうちに正規表現に変換され、メソッドが潜在的にセキュリティリスクを抱える可能性があります。これは、例えば次のように、特別に作成されたドメインで検証をバイパスできるようにするためです:
**
match()
**関数は、search()
と同様に正規表現を処理します。正規表現が適切に構造化されていない場合、バイパスされる可能性があります。**
escapeHtml
**関数は、文字をエスケープして入力を無害化することを意図しています。ただし、新しいエスケープされたオブジェクトを作成せず、既存のオブジェクトのプロパティを上書きします。この動作は悪用される可能性があります。特に、オブジェクトが操作され、その制御されたプロパティがhasOwnProperty
を認識しないようにできる場合、escapeHtml
は期待どおりに機能しません。以下の例で示されています:期待される失敗:
エスケープのバイパス:
この脆弱性の文脈では、File
オブジェクトは、読み取り専用のname
プロパティを持つため、特に悪用されやすいです。このプロパティは、テンプレートで使用される際にescapeHtml
関数によって無害化されず、潜在的なセキュリティリスクを引き起こす可能性があります。
JavaScriptの
document.domain
プロパティは、ドメインを短縮するためにスクリプトによって設定でき、同じ親ドメイン内でのより緩やかな同一オリジンポリシーの適用を可能にします。
e.origin == window.origin バイパス
%%%%%%を使用してサンドボックス化されたiframeにWebページを埋め込む場合、iframeのオリジンはnullに設定されることが重要です。これは、sandbox属性とそのセキュリティと機能への影響を考慮する際に特に重要です。
sandbox属性で**allow-popups
**を指定すると、iframe内から開かれたポップアップウィンドウは親のサンドボックス制限を継承します。これは、ポップアップウィンドウのオリジンが同様にnull
に設定されるため、iframeのオリジンと一致することを意味します。
したがって、これらの条件下でポップアップが開かれ、iframeからポップアップに**postMessage
を使用してメッセージが送信されると、送信元と受信先の両方のオリジンがnull
に設定されます。この状況では、iframeとポップアップがnull
という同じオリジン値を共有しているため、e.origin == window.origin
**がtrue(null == null
)に評価されます。
詳細については、以下を読んでください:
pageBypassing SOP with Iframes - 1e.sourceのバイパス
メッセージがスクリプトがリスニングしている同じウィンドウから送信されたかどうかを確認することが可能です(特にブラウザ拡張機能のContent Scriptsにとって興味深い)。
メッセージの**e.source
をnullにすることができます。iframeを作成し、postMessageを送信してすぐに削除**することで実現できます。
詳細は以下を読んでください:
pageBypassing SOP with Iframes - 2X-Frame-Header バイパス
これらの攻撃を実行するためには、理想的には被害者のウェブページをiframe
内に配置できると良いでしょう。しかし、X-Frame-Header
のようなヘッダーがその動作を防ぐことがあります。
そのようなシナリオでは、より控えめな攻撃を使用することができます。脆弱なウェブアプリケーションに新しいタブを開いて通信することができます。
メインページをブロックして子に送信されたメッセージを盗む
次のページでは、メインページをブロックしてからデータを送信する前に、子のiframeに送信された機密postmessageデータを盗む方法を見ることができます。そして、子のXSSを悪用して、データが受信される前にデータを漏洩させます:
pageBlocking main page to steal postmessageiframeの場所を変更してメッセージを盗む
もし、別のiframeを含むX-Frame-Headerのないウェブページをiframe化できる場合、その子iframeの場所を変更できます。そのため、ワイルドカードを使用して送信されたpostmessageを受信している場合、攻撃者はそのiframeのoriginを自分が制御するページに変更してメッセージを盗むことができます:
pageSteal postmessage modifying iframe locationpostMessageをプロトタイプ汚染および/またはXSSに
postMessage
を介して送信されたデータがJSによって実行されるシナリオでは、ページをiframe化してプロトタイプ汚染/XSSを悪用し、攻撃をpostMessage
経由で送信することができます。
postMessage
を介した非常によく説明されたXSSの例は、https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.html で見つけることができます。
プロトタイプ汚染を悪用してXSSを行う悪用の例を示す:
詳細情報:
プロトタイプ汚染に関するページへのリンク
XSSに関するページへのリンク
クライアントサイドのプロトタイプ汚染からXSSへに関するページへのリンク
参考文献
WhiteIntelは、ダークウェブを活用した検索エンジンで、企業やその顧客がスティーラーマルウェアによって侵害されていないかをチェックする無料の機能を提供しています。
WhiteIntelの主な目標は、情報窃取マルウェアによるアカウント乗っ取りやランサムウェア攻撃と戦うことです。
彼らのウェブサイトをチェックし、無料でエンジンを試すことができます:
Last updated