ソース:
訳:
今日は、設定ミスのポストメッセージ機能を通じて DOM ベースの XSS を悪用する方法について説明し。
2 つのサイトは、同じプロトコル、ホスト名、およびポートを持っている場合にのみ相互に通信できて。
2 つのサイトに上記の類似のプロパティがない場合、 同一生成元ポリシーがトリガーされて。
をバイパスする方法はいくつかあります 同一生成元ポリシー 。
その 1 つは postMessage 関数で。
postMessage メソッドは、次の間のクロスオリジン通信を安全に有効にし。 Window
オブジェクト。
postMessage は 2 つのメソッドを使用してウィンドウ間の相互通信を行って。
それらは次のとおりで。
- window.addeventListener
- postMessage()
ここでは、関数 postMessage() が誤って構成され、DOM ベースの XSS に対して脆弱になるさまざまなシナリオを示し。
シナリオ 1:- オリジン検証チェックなし
このシナリオでは、送信元のチェック/検証はなく。
つまり、アプリケーションは postMessage() 関数を使用している任意のドメインからメッセージを受信し。
脆弱なコード
コード スニペットからわかるように、発行元の検証は実装されていなく。
このシナリオでは、攻撃者はクロスオリジン通信を可能にする postMessage() 関数を使用してエクスプロイトを構築し、攻撃者は XSS ペイロードを被害者/メイン アプリケーションに配信できるようになり。
エクスプロイトコード
シナリオ 2: アプリケーションが indexOf()関数を使用している オリジン検証に
このシナリオでは、アプリケーションはオリジン検証にindexOf()関数を使用し。
この場合、関数はホワイトリストに登録されたドメインがオリジンに含まれていることを確認し。
オリジン検証に IndexOf() 関数を使用することは、悪い習慣で。
これは、indexOf() 関数で指定された文字列で始まるサブドメインを作成することで回避できるためで。
脆弱なコード
上記のコードからわかるように、アプリケーションは発信元の検証に IndexOf() 関数を使用していて。
この構成ミスを悪用するために、エクスプロイト コードをホストするサブドメインを作成し。
エクスプロイトコード
シナリオ :3 ホワイトリストに登録されたオリジン/ドメインは、反映/保存された XSS により脆弱です
上記のコード スニペットからわかるように、addEventListener() がプロトコル、ホスト名/IP、およびポート番号を検証していることがわかって。
これは、関数がhttp://149.28.205.217:8083から送信されるメッセージを受信することを意味して。
場合はどうなりますか http://149.28.205.217:8083 に対して脆弱であるがStored/Reflected XSS ?
![](https://miro.medium.com/v2/resize:fit:700/1*555kw7LKHnE6eirG_i6Wgg.png)
これは Reflected XSS に対して脆弱であるため、これを使用して postMessage() エクスプロイト コードを挿入できて。
![](https://miro.medium.com/v2/resize:fit:700/1*_so4F-rE8amd-ym9OFYimg.png)
悪用する
修理
- window.addEventListener 関数のホワイトリスト オリジン。
- ドメインをホワイトリストに登録する際には、適切な正規表現を使用してください。
- ドメイン/ホストを機能にホワイトリストに登録する前に、すべてのページでクロスサイト スクリプティング関連のテスト ケースを実行します。
ほなほな。