web-dev-qa-db-ja.com

Access-Control-Allow-Origin：nullのFacebookオリジナルの脆弱性はどのようにしてクロスオリジンアクセスを許可しましたか？

最近、クロスオリジンを介してユーザーのプライベートメッセージにアクセスする攻撃を可能にするFacebookのメッセンジャーアプリの脆弱性AJAXがパッチされ、開示されました。

シンプルなバグにより、ハッカーはあなたのプライベートFacebookメッセンジャーチャットをすべて読むことができます

この問題の原因は、攻撃者がFacebookのチャットサーバードメインでクロスオリジンヘッダーの実装を誤って構成したことで、これにより攻撃者はOriginのチェックをバイパスし、外部WebサイトからFacebookメッセージにアクセスできました。

screenshot

「Originull」の名前とスクリーンショットは、問題が次のヘッダーであることを示しているようです。

Access-Control-Allow-Origin: null

しかし、これはnullの値がどのように脆弱性につながるのか疑問に思います。何らかの形でnullのドメインからウェブサイトにアクセスする場合を除いて、これは有効なOriginのようには見えません（実際には、http://nullまたはhttps://nullプロトコルを含める必要があります）。

私がチェックしたところ、nullは実際には*と同じように許可されている値ではなく、ChromeまたはFirefoxの場合）です。

XMLHttpRequestが読み込めません http：//other.localhost/ajax.php 。 「Access-Control-Allow-Origin」ヘッダーに無効な値「null」が含まれています。したがって、オリジン ' http：// localhost 'はアクセスを許可されません。

（ただし、*の値を使用しても機能します。そのため、nullであるだけでは、任意のページがこれらのリソースにアクセスするには不十分です。

nullを*として読み取るブラウザーにいくつかの機能またはバグはありますか？または、データURIで開かれたページなど、nullとのマッチングを可能にするブラウザの機能この脆弱性はどのように機能しますか？

web-browserfacebooksame-origin-policycorscrossdomain
9
Alexander O'Mara

私はイスラエルと申します。この脆弱性を発見した研究者です。

質問を2つの部分に分けましょう：A.ブラウザのオリジンはどのようにnullになりましたか？ B. null OriginがFacebookサーバーに与える影響

Aから始めましょう。OriginはCORSメカニズムの一部であり、リクエストの送信元をサーバーに伝えることを目的としています。サーバーがリクエストを受け取ると、サーバーはこのオリジンが応答を受信することを許可することを決定できます。この保護を回避する方法の1つは、いずれかのページ内でOpen-Redirectを見つけて、ユーザーをdataURIスキーマに誘導することでした。以前は、dataURIは、他に提供するOriginがなかったため、以前のOriginを受け取りました。セキュリティの改善として、最新のブラウザーはOriginをnullに設定しているため、このdataURIページからのXHRリクエストには適切なOriginがありません。 Chromeではこれがどのような状況でも発生し、Firefoxではメタタグを介してページがdataURIに更新されたときにのみ発生します。

これがOriginがnullになった方法です。

'Originull'攻撃は、Originに基づくセキュリティチェックを回避するためにこの動作を使用します。これは、ほとんどの場合、プログラマーはnullをこのフィールドの値とは考えないためです。

では、パートBに進みましょう。これがFacebookにどのように影響したか。

Facebookは別のサブドメインを使用しているため、メッセンジャーサーバーでAccess-Control-Allow-Originを使用しています。

ほとんどの場合、Messengerサブドメインの入り口にセキュリティフィルターがあり、要求はユーザーに応答する内部サーバーに渡されます。サーバーが応答する必要がある場合、サーバーはリクエストのOriginから値を取得し、Access-Control-Allow-Originヘッダーで返しました。この開発設計により、Facebookは許可されたオリジンを1か所だけに保つことができます。

メッセンジャーサブドメインでは、通常のGETリクエストも許可されます。通常のGETリクエストには、Originヘッダーはまったくありませんでした。多くの開発言語では、存在しないヘッダーは値nullを返します。

そのため、フィルターにはnullの通過を許可する条件があり（GET要求は正しく通過します）、サーバーは要求のOriginヘッダー（null）で受け取った値を受け取り、 Access-Control-Allow-Originヘッダーでクライアントに返します。

シンプルでしょ？ ;）

技術的な詳細とスクリーンショットは、BusSecのWebサイトにある完全な開示ドキュメントにあります。 https://www.bugsec.com/wp-content/uploads/2016/12/Blog-Post-BugSec -Cynet-Facebook-Originull.pdf

11
Ysrael Gurt

データURIやサンドボックス化されたiframeなどにロードされたリソースはnull Originを使用するため、Access-Control-Allow-Origin: nullを悪用する可能性があります。 A PDFエクスプロイトを文書化すると、OriginullがデータURIドキュメントを使用してこのヘッダーを悪用し、オリジン間アクセスを実現したことが確認されます 。

このため、W3Cはヘッダーにこの値を返さないことをお勧めします。

7.4。 Access-Control-Allow-Origin: "null" を返さない

Access-Control-Allow-Origin: "null"を返すのは安全に思えるかもしれませんが、非階層スキーム（data:やfile:など）を使用し、サンドボックス化されたドキュメントを使用するリソースのOriginのシリアル化は、 "ヌル"。多くのユーザーエージェントは、そのようなドキュメントにAccess-Control-Allow-Origin: "null"ヘッダーを含む応答へのアクセスを許可します。Originは、「null」のOriginを使用して敵対的なドキュメントを作成できます。したがって、ACAOヘッダーの「null」値は回避する必要があります。

「null」に適用されるCORSの単純な文字列比較には、議論の余地があります。 「null」は、オリジンの欠如を示すキーワードトークンとして扱われるべきであると信じている人もいます。 （例えば、SQLのnull値の場合と同様です。）この動作は将来変更される可能性があるため、「null」と「null」の比較に依存するシステムを構築することは賢明ではありません。

結局のところ、nullの値は現在、特別な意味はありません。これは*と同じではありません。現在、Originのないリソースと照合できる、それほど特別ではないOriginです。

したがって、（偶然であっても）このヘッダーを返す場合：

Access-Control-Allow-Origin: null

現在、リソースはクロスオリジンにアクセスできます。

3
Alexander O'Mara